网购秒杀系统架构设计案例分析
秒杀架构分为以下几个方面
- 前端页面 + 网关 + 服务层 + 缓存层 + 中间件 + db 层
数据的流向就是
- 用户在前端页面下单的时候 请求通过网关打到服务层 服务层通过redis 的一些处理，将能够正确秒杀的用户数据写入nsq，后续进行db层的扣减库存加订单的操作了
2.基于以上的数据流量 每一个模块都有详细要做的事情。
- 前端 页面静态化 + cdn
- 通过点击按钮 然后disable 的方式 进行前端限流
- 网关层 通过Kong网关的形式，对整体流量进行限流，监控，负载均衡到所处的服务层
- 服务层首先需要拒绝掉重复用户请求的流量 这个解决方式通过redis的key的设置 以上的几部能拒绝多大部分非法请求
- 接下来就要进行流量的限流措施，我们可以使用 令牌桶算法来进行流量的把控
- 令牌桶后的流量我们通过redis 的扣减库存后，走mq的方式近一步限流削峰，
- 此时落入db的流量可以限制的很低。我们可以进行数据库的更新操作了。通常数据库需要查库存，然后再update。其实使用版本号的乐观锁 就能防止超卖 并且一个sql 搞定
update goods set stock = stock -1 where googs_id = {goods_id} and version = {version} and stock > 0
我们需要做的还很多
- 故障演练
- 全链路压测
- 限流降级措施以及异常预案
其实到这里 整个秒杀的架构应该是完成了，但是如果给我们更高的要求，我们还可以做到的点是。 架构的延伸以及闭环
- 复用秒杀的模型。能够适用于各个秒杀情况。文档化，标准化各链路以及代码质量。目的是让 后续其他部门使用秒杀的场景的时候能够利用我们的之前研究探讨好的方案，让他们能够更快的开发并且使用
- 我们在复盘整个秒杀活动的时候，我们需要清晰的记录各个机器的负载，流量情况，我们分析 得与失。总结成经验，想想哪里我们可以做的更好。
