高并发下秒杀系统的设计

文章目录

- 1 业界通用做法
- - 1.1 压力分摊
  - 1.2 Redis+MySQL
  - 1.3 Inventory Hint
  - 1.4 压力分摊+Redis+MQ
- 2 Redis + MQ 解决高并发下的秒杀场景
- - 2.1 Redis库存预扣减
  - - 2.1.1 lua脚本执行流程：
    - 2.1.2 Lua脚本主要做了几件事：
  - 2.2 MySQL库存扣减
  - 2.3 记录操作流水的原因
- 3 Inventory Hint 数据库扣减
- - 3.1 使用
  - 3.2 原理介绍
  - - 3.2.1 关键优化点：
- 4 总结

在电商这片红海，秒杀活动无疑是屡试不爽的流量密码、销量利器。然而，在应对其并发请求时，其中的设计门道暗藏玄机。并发量小，数据库单表便能一夫当关，稳保活动无虞；一旦碰上爆款引爆流量，并发呈井喷式增长，单表瞬间独木难支，此时，一套高并发 “抗压” 组合拳必不可少。接下来，咱们就一起深挖业界那些屡建奇功的妙招，直击高并发痛点，重点解析其中两大 “硬核” 方案，助你轻松拿捏秒杀场景的技术难点。

1 业界通用做法

1.1 压力分摊

在应对并发的挑战时，利用分桶策略压力分摊，往往受到很多人的青睐。具体而言，面对单品库存，巧妙地拆分为多组，大大缓解抢购高峰的压力。但这背后藏着诸多棘手难题，如何精准地将库存均匀分配至各桶，杜绝分配不均；怎样有效处理拆分产生的库存碎片，避免少卖；分桶间的调度规则如何制定，确保协同高效；还有，业务量起伏不定，又该如何实现分桶动态扩容以灵活适配。这些问题也需要我们进行考虑设计。

1.2 Redis+MySQL

在秒杀系统的架构设计蓝图中，Redis 与 MQ 的组合堪称一对 “黄金搭档”。Redis 凭借其卓越的高性能读写特性以及原子操作能力可以直面秒杀活动带来的汹涌并发流量，筑起防止超卖的坚固防线。而 MQ 通过流量削峰策略，将瞬间爆发的海量数据请求进行缓冲与分流，有效减缓后端数据存储环节的压力，确保整个系统节奏平稳。

不过，不少人心中会泛起疑惑：既然 Redis 如此强大，为何不索性全程在 Redis 中完成操作，待秒杀尘埃落定，再一次性将数据同步至数据库呢？理论上看似可行，但若置于真实复杂的业务场景之中，便会破绽百出。要知道，用户成功抢购后，绝非万事大吉，后续一系列连贯操作随即而来，诸如急切地查看抢购结果，或是迅速进入支付流程等，这些都需要实时、精准的数据交互与支持。

当然，采用 Redis + MQ 这套方案并非一劳永逸，其中数据一致性问题犹如潜藏暗处的礁石，不容小觑。不过别担心，接下来我们就将针对这一方案进行详细的介绍。

1.3 Inventory Hint

大家普遍知晓高并发场景下需精心构建复杂架构应对挑战。然而，有一些公司却看似 “剑走偏锋”，即便面临着不容小觑的并发压力，依旧选择直接对数据库进行操作，并未引入那些令人眼花缭乱的高并发设计体系，这难免让人满腹狐疑。

实则不然，这些公司背后有着强大的技术支撑 —— 他们选用的是阿里的 RDS 云数据库。这款数据库绝非等闲之辈，它依托阿里的强大技术底蕴，内置了先进的 Inventory Hint 技术。凭借该技术对数据库的精准优化，使得这些公司即便在高并发的枪林弹雨中，也能让数据库稳健运行，轻松应对海量数据的读写请求。下面，咱们也会深入其中，着重揭开这项神奇技术的神秘面纱，探寻它究竟是如何赋能数据库、化解高并发难题的。

1.4 压力分摊+Redis+MQ

面对数百万 QPS 的高压冲击，多种技术方案强强联手，才能站稳脚跟。SQL 合并执行批量处理请求，削减数据库负荷。缓存阵营更是齐发力，分布式缓存广纳热点，本地缓存就近响应，近端缓存将分布式缓存与服务器 “联姻”，实现超高速读取。分桶策略巧妙分流，开辟流量 “绿色通道”。各方案各司其职，分担并发压力，聚合为强大力量，确保大促活动平稳运行。

2 Redis + MQ 解决高并发下的秒杀场景

2.1 Redis库存预扣减

上面我们方案二已经介绍过该方案的整体技术架构，接下来我们进行详细的剖析。该方案我们主要是通过Redis的Lua脚本进行库存的扣减，这样可以保证扣减过程中的原子性和高效性。示例代码如下：

 /** KEYS[1] --商品id* KEYS[2] --用户id uid* ARGV[1] --扣减数量* ARGV[2] --用户提交的  token*/
String luaScript = "redis.replicate_commands()\n" +//防止用户是否重复提交，利用 token实现的，每次提交前会生成一个token，token更新前才可继续提交"if redis.call('hexists', KEYS[2], ARGV[2]) == 1 then\n" +//抛出用户重复提交的异常"return redis.error_reply('repeat submit')\n" +"end \n" +//商品id"local product_id = KEYS[1] \n" +//获取商品id对应的库存"local stock = redis.call('get', KEYS[1]) \n" +//判断库存是否充足"if tonumber(stock) < tonumber(ARGV[1]) then \n" +//购买的数量"return redis.error_reply('stock is not enough') \n" +"end \n" +"local remaining_stock = tonumber(stock) - tonumber(ARGV[1]) \n" +//更新库存"redis.call('set', KEYS[1], tostring(remaining_stock)) \n" +//获取但当前系统的时间 返回一个数组，包含2个元素 第一个元素是当前的秒数，第2个是当前这一秒已经流逝过的微秒数"local time = redis.call('time') \n" +//当前时间戳 ms"local currentTimeMillis = (time[1] * 1000) + math.floor(time[2] / 1000) \n" +//存如一条流水 {"change":"1","action":"扣减库存","from":"100","token":"token","timestamp":1735293810009,"to":99,"product":"product_id_01"}"redis.call('hset', KEYS[2], ARGV[2], \n" +"cjson.encode({action = '扣减库存', product=product_id  ,from = stock, to = remaining_stock, change = ARGV[1], token = ARGV[2], timestamp = currentTimeMillis})\n" +") \n" +"return remaining_stock";