Java高并发秒杀高并发优化

个人博客网：https://wushaopei.github.io/    (你想要这里多有)

1、秒杀优化原因：

（1）无法使用CDN缓存，其只针对核心数据做缓存

（2）在后端库存操作中，不能在缓存中减库存，极短时间内不同用户的缓存数据不同，变化大，容易造成超量

（3）某一个热点商品被同一时间由多人竞争时会产生大量的update操作，DB效率及错误率需要优化 

2、使用redis/NoSQL的数据验真，将逻辑操作解析等校验后调用MQ进行解耦，发送消息队列，或调用MQ的异步操作提高效率异步处理事务；最后根据队列执行结果对MySQL进行操作，这一步需要根据消费消息的结果来操作，即落地实现

3、压力测试下，一条update 可以 达到 4W 的 QPS ，等同于一件商品能在一秒内被销售掉 4W 件，这应该是理想值吧！

那么，对于实际执行中的低效是什么原因？这才是并发中要优化的重点吧！

4、第一个用户执行一次商品购买时，对DB的update减库存操作不是执行完就结束，后续还涉及到GC内存满了，等待自动回收过程中的网络响应的延迟问题；除此之外，用户的每一次购买操作都是一个具体的事务，其中还涉及到了用户个人的购买明细，可理解为淘宝的已购买这一项，而这又是一个insert 的操作，执行完后又或许可能再一次出现GC进行内存的清理而导致延迟，直到反应过来后，继续执行后续的事务提交commit或者失败后的回滚rollback

而这时另一个用户的update 操作已经开始很久了超过了 4W分之一秒的理想时间，所以，实际秒杀项目中，需要对每一个用户的update时间，即行级锁的时间进行优化，因为，下一个用户还在等待，他后面或许还有一个它也在等待....哈士奇瞪着眼等着呢

5、优化：

前端： 动静态数据做分离，减少请求与响应时间；按钮防重复，防止用户发送无效的重复请求，因为秒杀活动一般都会有购买数量的限制，敲的次数再多，最后还是要查看是否已购。影响了效率，可有前端代为处理并优化

后端：使用CDN换存重要的静态资源等；在后端对活动结束时间、商品选购时间、业务的相关逻辑要求都放在后端代码中，并调用缓存来进行暂存，已减少对DB的直接操作，提高效率

6、业务逻辑层面的优化，将用户的每次购买记录到 insert  到数据库的操作提前到减库存之前；

并获得返回值 insertCount ，其代表当前用户执行了一次秒杀操作；

当用户在前端页面重复点击多次购买时，该 insertCount> 0时则说明当前用户已购买，不再进入到下一步的减库存操作；

从而避免了行级锁频繁无功用访问执行时带来的效率问题；

最后，如果insertCount <=0时，允许进入到减库存的操作。

7、数据库层面的优化：

2：用到 mysql 的 DELIMITER ，使用 $$ 作为换行符，类似于；
7: 定义存储过程的名字： 创建存储过程 名字.名字
8、9： 存储过程中输入、输出的参数
10： BEGIN  表示 开始编写存储过程的具体内容
11：判断一个变量，该变量名为 insert_count ，后面是具体类型及默认值
12：开启事务  transaction 
13：插入购买记录 到 用户记录表 
14、15：表示具体要插入哪些数据到哪些表参数上
16：查询 上一次 insert_count 返回的有效值
17、18、19 ： 当上一次执行的有效值 = 0，说明插入操作失败，回滚，并 设置     R_RESULT 代表重复秒杀

20、21、22： insert_count 小于0 ，这只能是出错，故以 R_RESULT = -2 代表出错，作为返回值返回；
23~25：以上已排除 insert_count 及插入返回结果 小于、等于0的，剩下的只能是大于零，由于每次只有一条数据进来，故只能返回 1 ；执行update 减库存操作，对number-1 
26~ 29 ：并根据活动或秒杀商品的id对活动的开始、结束时间与活动时间周期校验是否处在同一区域内，并验证活动商品量是否仍 大于零 
30：使用 select row-count() into insert_count 来获取减库存操作的有效返回值
31~40 : 根据 减库存的返回值判断是否执行减库存成功，若 insert_count <=0；则说明失败或出错，并返回 0 或 -2 ；余下的结果只能是成功，设置返回值为 1 ；

8、优化说明：使用存储过程，对 mysql事务行级锁的效率进行优化，一次编译，多次使用，减少编译时间