大厂实践

原文地址：https://mp.weixin.qq.com/s/Q-tap7xI3Y5diTMEt5hMyw 这个方案和我之前讲过的hint方案差不多，原文贴这里，供大家参考： “秒杀”是电商平台最典型的高并发促销场景，双十一等大促活动也常以秒杀能力作为数据库技术实力的标志。随着小红书电商业务快速增长，直播带货等爆品场景对极致下单速度的需求更加突出，希望将下单吞吐提升至 1W+/s。 基于 MySQL 内核实现的合并秒杀优化，相对排队秒杀方案，将秒杀写入能力再提升 5 倍，相对MySQL 社区版本更有百倍的性能提升。在设计上保持了和排队秒杀一致的能力，该能力对业务完全透明：仅需升级 MySQL 内核，无需改动 SQL，即可获得 5 倍以上性能提升。 该方案不仅显著提升库存、优惠券、红包等高抢购场景的用户体验，也能在热门笔记点赞等高频写入场景实现数量级性能增强。 24年小红书数据库团队首次通过对热点线程排队，将自研版本秒杀性能提升了10倍，但依然跟不上业务的快速发展。尤其是在直播带货、热门笔记点赞、爆品抢购等场景下，业务迫切需要更快的秒杀速度，本次数据库团队在自研内核上迭代实现了合并秒杀方案，将热点行更新速度提升5倍至1.5W/s+，极大提升了用户的使用体验。 合并秒杀版本在方案设计时考虑了和排队版本的兼容性，内核会根据SQL自动选择最优的秒杀方案。对于热点SQL，内核会依据SQL自动选择合并秒杀、排队秒杀和普通更新的最优解，只需升级MySQL内核版本，无需业务侧修改SQL即可享受到5倍以上的性能提升。 从下面性能分析图可以看到，在128线程秒杀时，TPS从4276提升至23543，提升约5.5倍。在1024线程极端场景下，仍然有4.7倍性能提升。随着线程数的升高，线程切换的开销越来越大，TPS也逐步下降，因此建议线程数保持在128-256之间以获得最佳性能。 测试数据均为sysbench模拟标准库存扣减模型进行的压测数据。 首先对秒杀场景进行分析，抽象出了它的事务模型。下面所示为最经典的库存扣减模型： begin; insert into inventory_log value (…); – 插入库存修改的流水表 ...

阿里有很多业务，几十上百个业务线，各自都有一些需要做抢购、秒杀、热点扣减的场景。他们都用哪些方案呢？ 我看了很多资料，也找了很多人做交流，最终得到的结论是啥都有，主要总结几个主流的，在用的一些方案（主要是整体方案的介绍，具体细节就不展开说了，有的是太敏感不方便讲，有的是太复杂了先把主要的说了，后续需要的再展开）： 你比如说，一些并发量没那么高，比如只有几千的，基本上是用mysql在抗的。但是你要是以为这个mysql和你用的mysql是一样的，那你会发现热点行更新在几百QPS的时候CPU就直接被拉满了。 那我们的mysql呢，是加了个自研了一个补丁（就是下面这篇文章中的技术方案），这个补丁可以识别出热点行及热点SQL，再给这些SQL分组，然后一个组内的多个SQL就可以减少加锁次数、减少B+树的遍历、以及通过组提交减少事务提交次数。就能扛更高的并发。（这个方案在我的项目课中用了） ✅阿里的数据库能抗秒杀的原理 但是如果有些场景的QPS达到数万级别了，只靠数据库肯定是不行了。于是有一些营销平台或者额度系统，就会采用分桶的策略。就是将单个1000的库存拆分成10个100的库存，这样就可以把并发提升10倍。当然，这里还需要考虑如何均匀分配，如何解决碎片，如何做分桶间调度以及如何做动态扩容等问题。然后有些团队就专门研发了库存调度系统来解决这些问题。 另外，在一些本地生活类的电商场景，比较常用的方案就是缓存+数据库的策略，也就是在缓存做预扣减，然后异步通知到数据库再做扣减。这种方案就是需要考虑数据的一致性、缓存的不可用等问题。（这个方案在我的项目课中用了） 那对于那种需要抗几百万QPS的电商大促场景，基本上就是各种方案的结合了。热点库、SQL合并执行、缓存、以及分桶基本都是结合着来的。而且这里的缓存，又有分布式缓存、本地缓存，以及把分布式缓存和服务器部署在一起搞一个近端缓存。总之就是各种方案每一个抗一点并发，加到一起抗的就多了。 我还了解到还有一些物流的仓库管理场景，设计了自己的分布式事务+应用层排队框架，来减少在数据库层面的热点更新，方案听上去也挺牛逼的。 看了这么多之后，到底哪种方案最好？又经过77四十九天的研究，我终于悟了，适合的才是最好的。 根据具体的业务形态、并发量、团队成员的技术能力、基础建设的情况等等选择相对合适的就行了。但是不管咋说，复杂度和并发量一定是成正比的。

典型回答 其实，在阿里电商的秒杀等（据我了解，淘宝、天猫、猫超、大麦等都是这么干的）场景中，主要还是基于MySQL数据库在做扣减的，主要是因为这样做最可靠了（避免了redis扣减方案中的数据不一致、少卖等问题）。 但是我们都知道，数据库是抗不了热点行的并发更新的，于是阿里内部就对MySQL做了patch。 这个方案其实云上数据库RDS也支持了，所以我就可以讲了。（没开放的技术确实不敢讲，怕被请喝茶。。。） 这个技术叫做Inventory Hint，其实就是一个补丁。（官方介绍：https://help.aliyun.com/zh/rds/apsaradb-rds-for-mysql/inventory-hint ） PS：这里主要是介绍通过Inventory Hint来提升热点更新的并发，但是并不意味着内容只用这个方案来抗热点并发，但是这个是基础，先把这个讲清楚。后续其他的方案，我也会挑一些能讲的介绍。 使用方法 他的用法很简单，只需要在正常的update语句中增加上特殊的hint语句就行了，如： 1 2 3 UPDATE /*+ COMMIT_ON_SUCCESS ROLLBACK_ON_FAIL TARGET_AFFECT_ROW(1)*/ T SET c = c - 1 WHERE id = 1; 这里面的COMMIT_ON_SUCCESS、ROLLBACK_ON_FAIL和TARGET_AFFECT_ROW都是一些Hint语法： COMMIT_ON_SUCCESS：当前语句执行成功就提交事务上下文。 ROLLBACK_ON_FAIL：当前语句执行失败就回滚事务上下文。 TARGET_AFFECT_ROW(NUMBER)：如果当前语句影响行数是指定的就成功，否则语句失败。 hint：MySQL 中的 “Hint” 是一种特殊的语法，允许开发者向数据库引擎提供如何执行特定查询的额外信息或建议。这些提示不改变查询的结果，但可以影响查询的执行路径，比如如何选择索引、是否使用缓存等。使用 Hint 的目的是为了优化查询性能。 ...