秒杀系统设计浅析

秒杀系统设计浅析

一.引言

先假设一个业务场景，某商品秒杀活动，100件库存，大概预估10w人参加活动

二.系统面临的问题

1.高并发

• 秒杀这种业务场景的特点就是时间极短，瞬间用户量极大

2.超卖问题

• 卖出高于库存数量的商品

3.链接暴露,恶意请求问题

• 类似黄牛，专门抢这种低价秒杀商品，然后又转手高价卖出去

4.数据库压力问题

• 十几万的QPS基本都要把数据库打挂，如果秒杀业务还设计其他业务，没有降级，限流，熔断等策略，基本要把其他业务也搞挂

三.如何解决这些问题？

1.服务单一职责

• 给秒杀系统单独开一个服务，与其他业务服务隔离开来，单独给它建一个数据库。
• 这样设计的好处就是即使秒杀系统没有抗住，崩了，也不会影响其他业务服务。

2.秒杀链接加盐

• URL链接动态化，通过md5之类的加密算法加密随机的字符串去做url

3.redis集群架构

• 单机redis是肯定扛不住秒杀系统压力的，并且秒杀完全就是读多写少的场景，直接采用redis cluster集群

4.负载均衡

• 多租点流量机

5.网关拦截恶意请求

• 在网关层面，就把不像人为的请求拦截掉。
• 避免打到后台，占用网络带宽或把服务器打崩或缓存击穿等等。

6.资源静态化

• 一般都是前后端分离的系统，前端也要有自己发服务器
• 把一些前端资源能放入cdn服务器的东西都放进去，进一步减轻真正秒杀时的压力。

7.按钮控制

• 没到秒杀时间的时候，秒杀按钮置成灰色，不可按状态。
• 避免用户在快到秒杀时间的时候在最后几秒疯狂请求，导致还没到秒杀时间系统就挂了

8.前后端限流

• 前端限流：秒杀按钮不能一直点，一般是点一下或者两下等几秒之后才可以继续点击
• 后端限流：产品全卖完了，前端秒杀结束，后端也跟着结束关闭

9.库存预热

• 秒杀系统设计的业务数据都加载到redis中，让整个流程都在redis里面去做.
• 等秒杀结束了，再异步去数据库修改库存

10.redis+lua脚本，解决超卖问题

lua脚本是redis在2.6版本提供的，通过内嵌对lua环境的支持，redis解决了长久以来不能高效处理CAS(check and set)命令的缺点，并且可以通过组合使用多个命令，轻松实现以前很难实现或者不能实现的事务模式

lua脚本类似redis事务，有一定的原子性，不会被其他命令插队，可以完成一些redis事务性的操作

• 解决超卖问题：把判断库存和减库存的操作都交给lua脚本

11.采用MQ削峰填谷

• 采用rabbit mq，对于突然来到的大量请求，可以配置流控规则，以稳定的速度逐步处理这些请求，起到削峰填谷的作用，从而避免流量突刺造成的系统崩溃。

四.总结

• 先用cnd将页面静态化
• 然后采用nginx做负载均衡，将流量均分到多个秒杀服务上。
• 然后通过redis集群提供业务数据服务。
• 通过lua脚本进行判断库存和减库存操作。
• 然后生成订单，通过rabbit mq队列进行下单，异步修改库存操作mysql。

五.参考

• https://juejin.cn/post/6844903999083151374