秒杀系统的设计原则

秒杀系统的设计原则

1 . 热点识别

通过营销活动等方式，提前收集信息。

2 . 隔离原则

在前端页面、应用层、数据层做好隔离。

3 . 将请求尽量拦截在系统上游。

传统秒杀系统之所以挂，请求都压到了后端数据层，数据读写锁冲突严重，并发高响应慢，几乎所有请求都超时，流量虽大，下单成功的有效流量甚小，比如某种商品只有1000的库存，100w个人来买，实际上绝大部分的请求有效率为0。

4 . 读多写少的场景使用缓存

秒杀是一个典型的读多写少的应用场景，比如某种商品只有1000的库存，100w个人来买，最多1000个人下单成功，其他人都是查询库存，写比例只有0.1%，读比例占99.9%，非常适合使用缓存。

秒杀场景架构设计

1、库存缓存

Redis作为大促期间库存扣减的主要承担方。商品ID作为Redis的KEY，将可用库存=(总库存-暂扣库存)值作为Value。利用LUA脚本的事务特性实现在Redis中“读剩余库存后扣减”的逻辑

2、容量规划

使用阿里云性能测试工具PTS，模拟真实用户请求，验证全国用户真实业务操作对服务端性能、容量和系统稳定性的影响，确保重大活动平稳支撑。

3、性能调优

利用ARMS提供的立体式监控能力，在压测过程中实时监控应用及物理机各项指标，快速帮助开发人员定位排查问题，提升系统性能。

4、限流防刷

使用阿里云应用高可用服务(AHAS) 实现限流降级，确保系统不被预期外的突发流量打挂。同时可配置热点规则，超过一定量的阈值后，系统会让购买热点商品的流量排队等待。例如购买同一商品，1s内调用超过100次请求后，则其余请求进行等待

5、异步解耦，削峰填谷

消息队列 RocketMQ 版是阿里云基于 Apache RocketMQ 构建的低延迟、高并发、高可用、高可靠的分布式消息中间件。消息队列 RocketMQ 版既可为分布式应用系统提供异步解耦和削峰填谷的能力，同时也具备互联网应用所需的海量消息堆积、高吞吐、可靠重试等特性

6、弹性能力

对于有周期性促销活动的用户，可以使用Serverless 应用引擎（SAE）快速部署应用，利用定时弹性能力，在活动开始前自动扩容，在活动结束后自动缩容回收资源，实现资源利用最大化，且整个过程无需人工干预。

内容转载自 大促场景系统稳定性保障实践经验分享