简单秒杀功能实现思路

秒杀步骤 

秒杀步骤
* 1、发送获取验证码请求，后台生成验证码并写入redis
* 2、用户填写验证码，发送检验验证码请求，后台校验成功后创建并返回秒杀专属路径
* 3、发送秒杀请求，发送商品id和path，后台验证path，验证是否已经秒杀成功（防止重复下单），并预减库存（内存操作）
* 4、发送mq消息
* 5、监听mq秒杀消息，校验库存，判断是否已经秒杀成功
* 6、减库存，创建订单，将秒杀成功信息写入redis
* 7、如果减库存失败，将秒杀失败信息写入redis
* 8、发送秒杀结果查询请求

如何防止流量过大导致的性能问题
* 1、拦截器中判断流量大小，如果超过预定流量，则直接返回失败
* 2、在活动开始前，将商品库存信息和无库存标志位缓存起来
* 3、活动开始前将商品详情等页面html缓存起来。
* 4、活动开始时先让用户输入验证码
* 5、让事务在mysql端执行，使用存储过程而不是spring声明式事务。屏蔽网络延迟和GC的影响。

减库存的方式

如下，如果返回的受影响行数>0则扣减库存成功：

  * 1、设置数据库的字段为无符号整数，这样小于0是数据库报错。

* 2、update miaosha_goods set stock_count = stock_count - 1 where goods_id = #{goodsId} and stock_count > 0

防止重复下单：

1、前端按钮灰化

2、创建订单入库时，服务端创建id，使用insert ignore语句，如果受影响行数为0则说明已经下过单

INSERT ignore INTO success_killed (seckill_id, user_phone, state)
VALUES (#{seckillId}, #{userPhone}, 0)

电商中的CAP理论：

 一个电商网站核心模块有会员，订单，商品，支付，促销管理等。
对于会员模块，包括登录，个人设置，个人订单，购物车，收藏夹等，这些模块保证AP，数据短时间不一致不影响使用。
订单模块的下单付款扣减库存操作是整个系统的核心，我觉得CA都需要保证，在极端情况下牺牲P是可以的。
商品模块的商品上下架和库存管理保证CP,搜索功能因为本身就不是实时性非常高的模块，所以保证AP就可以了。
促销是短时间的数据不一致，结果就是优惠信息看不到，但是已有的优惠要保证可用，而且优惠可以提前预计算，所以可以保证AP
现在大部分的电商网站对于支付这一块是独立的系统，或者使用第三方的支付宝，微信。其实CAP是由第三方来保证的，支付系统是一个对CAP要求极高的系统，C是必须要保证的，AP中A相对更重要，不能因为分区，导致所有人都不能支付