秒杀系统总结

一、问题

• 高并发
  • 缓存雪崩，缓存击穿，缓存穿透
• 超卖
• 重复下单问题

二、解决思路

1. 高并发

1.1 前端（用户层）

重复下单问题

• 用户点击过快，重复提交。
• 网络延时，用户重复提交。
• 网络延时高的情况下某些框架自动重试，导致重复请求。
• 用户恶意行为。

解决方法：

• 网关拦截多开
• 黑名单:
  • 网关层 增加ip黑名单
  • 后端: 加入临时黑名单 ，10分钟后才可继续操作，一小时允许一次跨时段弱校验。使用reids的list结构，过期时间一小时

限流 降级

• 按钮时间变灰
• 控制 参与次数
• 秒杀链接加盐

静态页面或缓存

每隔一段时间更一次新，减少数据库压力

1.2 后端（服务端）

微服务架构 （热点隔离）

• 服务单一职责
  • 业务隔离: 业务逻辑独立
  • 系统隔离: 秒杀、订务、 用户服务独立
  • 数据隔离: 独立的订单库、秒杀库
• Nginx负载均衡、轮询（nginx端的接入能力配置应该不超过集群的事务处理能力）

消息队列

MQ，Redis等消息队列

Redis 高可用 （集群，主从同步、读写分离，哨兵机制，开启持久化）

• Redis缓存
  • 库存预热

Mysql高可用（集群、读写分离）

2. 超卖（并发安全减库存）

• 方案1： 数据库操作乐观锁

• 方案2：利用Redis单线程 强制串行处理

  利用Redis 分布式锁,强制控制同一个商品处理请求串行化，缺点并发不高 ，处理比较慢，不适合抢购，高并发场景。用户体验差，但是减轻了数据库的压力。

• 方案3 ：redis + mq + mysql 保证库存安全，满足高并发处理，但相对复杂。

  利用Redis increment 的原子操作，保证库存安全，利用MQ保证高并发响应时间。但是事需要把库存的信息保存到Redis，并保证Redis 和 Mysql 数据同步。缺点是redis宕机后不能下单

3. 减库存与退库存

提交订单时减库存。用户选择提交订单，说明用户有强烈的购买欲望。生成订单会有一个支付时效，例如半个小时。超过半个小时后，系统自动取消订单，还库存。

超过订单有效时间、退单的解决方案:可

• 设置定时检查
• MQ消息延时队列

记录一些知识点

订单与库存涉及的几个重要知识

• TCC 模型：Try/Confirm/Cancel：不使用强一致性的处理方案，最终一致性即可，下单减库存，成功后生成订单数据，如果此时由于超时导致库存扣成功但是返回失败，则通过定时任务检查进行数据恢复，如果本条数据执行次数超过某个限制，人工回滚。还库存也是这样。
• 幂等性：分布式高并发系统如何保证对外接口的幂等性，记录库存流水是实现库存回滚，支持幂等性的一个解决方案，订单号+skuCode为唯一主键（该表修改频次高，少建索引）
• 乐观锁：where stock + num>0
• 消息队列：实现分布式事务 和 异步处理(提升响应速度)
• redis：限制请求频次，高并发解决方案，提升响应速度
• 分布式锁：防止重复提交，防止高并发，强制串行化
• 分布式事务：最终一致性，同步处理(Dubbo)/异步处理（MQ）修改 + 补偿机制

秒杀业务场景

微信抢红包

预先把红包分配好，用户直接来请求拿数据就行

秒杀架构设计理念

限流： 鉴于只有少部分用户能够秒杀成功，所以要限制大部分流量，只允许少部分流量进入服务后端秒杀程序。

削峰：对于秒杀系统瞬时会有大量用户涌入，所以在抢购一开始会有很高的瞬间峰值。高峰值流量是压垮系统很重要的原因，所以如何把瞬间的高流量变成一段时间平稳的流量也是设计秒杀系统很重要的思路。实现削峰的常用的方法有前端添加一定难度的验证码后端利用缓存和消息中间件等技术。

异步处理：秒杀系统是一个高并发系统，采用异步处理模式可以极大地提高系统并发量，其实异步处理就是削峰的一种实现方式。

内存缓存：秒杀系统最大的瓶颈一般都是数据库读写，由于数据库读写属于磁盘IO，性能很低，如果能够把部分数据或业务逻辑转移到内存缓存，效率会有极大地提升。

可拓展：当然如果我们想支持更多用户，更大的并发，最好就将系统设计成弹性可拓展的，如果流量来了，拓展机器就好了。像淘宝、京东等双十一活动时会增加大量机器应对交易高峰。