因为之前做的项目 电商的居多，这里有一些小的心得记录一下，都是一些业务逻辑处理
**
·商城抽奖：
**
量小的活动可以采取PHP+MySQL来实现
数量大并发高依旧可以选择redis
必要条件：活动奖品类型（有多少），每种奖品的中奖概率，用户
活动是否处于抽奖活动
活动的开始结束时间
用户是否已经抽奖
奖品列表信息
查询当前抽中的奖品 是否有余量，如果没有则替换其他奖品，其他也没有，显示奖品或者活动结束
有奖品时，更改数据库，给用户发送短信
抽奖算法的思路呢，这个比较简单
将概率放在一个数组里
计算概率的总和
循环这个数组，从总概率中取一个整数
比较这个数，小于等于概率，直接返回
否则给这个数重新定义
再次比较
商城秒杀
要解决两个问题
1、高并发对数据库产生的压力
2、超卖问题
第一个就是用缓存来解决，第二个问题 与上面问题处理相似，采用redis队列，采用多个队列共同完成，排队队列，抢购结果队列，库存队列，高并发的情况下，把用户放入排队队列，循环处理排队队列，判断用户是否在抢购结果队列，在的话就是已抢购，否则未抢购，库存-1，把用户放入抢购结果队列
还有一种方式：
1、先做一个静态页面
2、先到的用户存在一个数组里也可以是缓存，后面剩下的都去访问静态页面，这么做压力更小，不推荐
商品超卖问题
第一种方案：下订单前判断促销商品的数量够不够，不够不允许下订单，更改库存量时加上一个条件，只更改商品库存大于0的商品的库存，压测还是会出现超卖的情况，否决。
第二种方案：mysql的事务加排他锁来解决，存储引擎为innoDB，使用的是排他锁实现的，刚开始的时候我们测试了下共享锁，发现还是会出现超卖的现象。高并发测试，对数据库的性能影响很大，导致数据库的压力很大
第三种方案：使用文件锁实现。当用户抢到一件促销商品后先触发文件锁，防止其他用户进入，该用户抢到促销品后再解开文件锁，放其他用户进行操作。这样可以解决超卖的问题，但是会导致文件得I/O开销很大
第四种方案：redis的队列,将要促销的商品数量以队列的方式存入redis中，每当用户抢到一件促销商品则从队列中删除一个数据，确保商品不会超卖。这个操作起来很方便，而且效率高。