高并发系统架构设计之消息队列篇16：秒杀系统的削峰设计

Freedom3568

已于 2022-10-10 14:36:40 修改

阅读量315

点赞数

CC 4.0 BY-SA版权

分类专栏：百亿级并发系统架构设计文章标签：消息队列架构设计削峰异步处理解耦

于 2022-09-20 22:33:25 首次发布

本文链接：https://blog.youkuaiyun.com/zhanggqianglovec/article/details/126963022

百亿级并发系统架构设计专栏收录该内容

38 篇文章 ¥19.90 ¥99.00

订阅专栏

超级会员免费看

本文探讨了如何利用消息队列在高并发秒杀系统中进行削峰写流量、异步处理秒杀请求以及解耦合系统模块。通过将秒杀请求暂存于消息队列，减轻数据库压力，实现异步处理以简化业务流程，提升性能，并降低系统耦合度，以此应对高并发写请求的挑战。同时，文章指出在使用消息队列时需注意处理消息丢失、重复及延迟等问题。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

文章目录

引言

前面我们了解了高并发系统设计的三个目标：性能、可用性和可扩展性，而在提升系统性能方面，我们一直关注的是系统的查询性能。也用了很多的篇幅去讲解数据库的分布式改造，各类缓存的原理和使用技巧。究其原因在于，我们遇到的大部分场景都是读多写少，尤其是在一个系统的初级阶段。比如说，一个社区的系统初期一定是只有少量的种子用户在生产内容，而大部分的用户都在“围观”别人在说什么。此时，整体的流量比较小，而写流量可能只占整体流量的百分之一，那么即使整体的 QPS 到了 10000 次 / 秒，写请求也只是到了每秒 100 次，如果要对写请求做性能优化，它的性价比确实不太高。

但是，随着业务的发展，你可能会遇到一些存在高并发写请求的场景，其中秒杀抢购就是最典型的场景。假设你的商城策划了一期秒杀活动，活动在第五天的 00:00 开始，仅限前200 名，那么秒杀即将开始时，后台会显示用户正在疯狂地刷新 APP 或者浏览器来保证自己能够尽量早的看到商品。这时，你面对的依旧是读请求过高，那么应对的措施有哪些呢？因为用户查询的是少量的商品数据，属于查询的热点数据，你可以采用缓存策略，将请求尽量挡在上层的缓存中，能被静态化的数据，比如说商城里的图片和视频数据，尽量做到静态化，这样就可以命中 CDN 节点缓存，减少 Web 服务器的查询量和带宽负担。Web 服务器比如 Nginx 可以直接访问分布式缓存节点，这样可以避免请求到达 Tomcat 等业务服务器。当然，你可以加上一些限流的策略，比如，对于短时间之内来自某一个用户、某一个 IP 或者某一台设备的重复请求做丢弃处理。通过这几种方式，你发现自己可以将请求尽量挡在数据库之外了。

稍微缓解了读请求之后，00:00