1. 小红书MySQL内核秒杀优化方案解析
作为电商平台的技术核心，数据库性能直接决定了用户体验和业务天花板。去年我们团队在自研MySQL内核上实现了排队秒杀方案，将性能提升了10倍。但随着直播带货等新场景爆发，业务对数据库的写入能力提出了更高要求——需要支撑1.5万次/秒的库存扣减。经过三个月的攻坚，我们通过合并秒杀方案再次实现5倍性能突破，以下是完整的技术复盘。
2. 秒杀场景的技术挑战
2.1 典型事务模型分析
电商秒杀的核心事务包含四个关键操作：
sql复制BEGIN;
INSERT INTO inventory_log VALUES(...); -- 流水记录
UPDATE inventory SET quantity=quantity-1
WHERE sku_id=? AND quantity>0; -- 库存扣减
COMMIT;
其中流水表的插入可以并发执行，但库存表的更新由于涉及同一行数据，会触发InnoDB行锁竞争。当并发量超过200TPS时，线程争抢行锁会导致大量上下文切换，最终系统吞吐断崖式下跌。
2.2 性能瓶颈定位
通过perf工具采样高并发时的CPU消耗，发现主要开销在：
- 锁等待（占比38%）
- 线程切换（占比27%）
- Redo日志刷盘（占比19%）
特别是当128个线程并发时，实际有效工作时间不足30%，其余都在等待锁释放。这解释了为何社区版MySQL在秒杀场景下TPS只能维持在200左右。
3. 合并秒杀架构设计
3.1 核心思想
将N个事务的库存扣减合并为1个物理事务执行：
- Leader线程获取行锁后读取当前库存值X
- 在内存中累计N个扣减请求，计算最终值Y=X-N
- 一次性将Y写入存储引擎
- 生成N条逻辑binlog保证下游消费
相比排队方案每次扣减都走完整事务流程，合并方案将N次磁盘IO降为1次，理论上可获得近N倍的吞吐提升。
3.2 关键组件设计
3.2.1 全局缓存管理
c复制struct merge_cache {
dict_table_t* table; // 关联的表对象
ulint sku_id; // 商品ID
int64_t base_value; // 基准库存值
int64_t delta; // 累计扣减值
UT_LIST_NODE_T(merge_cache_t) list;
};
所有工作线程通过table->merge_cache访问同一缓存实例，保证数据可见性。缓存生命周期与表对象绑定，避免内存泄漏。
3.2.2 两阶段执行流程
-
收集阶段：
- Leader线程获取行锁，加载库存数据到缓存
- Follower线程将扣减请求合并到缓存delta值
- 持续10ms收集窗口（可配置）
-
提交阶段：
- Leader执行
UPDATE inventory SET quantity=base_value-delta - 生成包含所有扣减记录的binlog
- 唤醒所有Follower线程返回成功
- Leader执行
3.3 并发控制优化
3.3.1 行锁流水线技术
传统方案必须等前一组提交完成才能开始下一轮收集。我们通过预读机制实现组间流水：
code复制Group1: [Collect] -> [Commit]
Group2: [Collect] -> [Commit]
测试显示该优化可额外提升20%吞吐量。
3.3.2 动态合并阈值
根据负载自动调整合并窗口：
python复制def adjust_window(current_tps):
if current_tps < 5000:
return 20ms # 低负载时增大窗口
else:
return 8ms # 高负载时减少延迟
4. 关键技术实现
4.1 事务系统改造
4.1.1 Binlog生成
c复制void write_merged_binlog(THD *leader, Merge_group *group) {
for (THD *thd : group->followers) {
write_binlog_event(thd); // 写入逻辑日志
}
write_commit_event(leader);
}
保持与单事务相同的binlog格式，确保下游组件无需改造。
4.1.2 Crash Recovery
在redo log中记录合并组元信息：
code复制[REDO HEADER]
group_id=12345
member_count=8
base_value=1000
delta=8
崩溃恢复时以组为单位重放，保证base_value - delta的原子性。
4.2 性能对比测试
使用sysbench模拟128线程秒杀场景：
| 方案 | TPS | 平均延迟 | 99分位延迟 |
|---|---|---|---|
| 社区版MySQL | 217 | 589ms | 2.1s |
| 排队秒杀 | 4,276 | 29ms | 53ms |
| 合并秒杀 | 23,543 | 5ms | 11ms |
合并方案在1024线程极端场景下仍保持4.7倍于排队方案的性能。
5. 生产环境实践
5.1 灰度发布策略
- 先对非核心商品启用合并秒杀
- 监控binlog延迟和内存增长
- 逐步扩大商品范围
5.2 关键监控项
sql复制-- 合并统计
SELECT
table_name,
sum_merged_txns AS total_merged,
sum_merged_txns/executed_groups AS avg_merge
FROM merge_stats;
5.3 已知问题规避
- 大事务风险：单个合并组不超过500个事务
- 锁升级：对热点行禁用表锁转换
- 内存控制：每个表缓存上限1GB
6. 方案演进方向
当前方案在128线程下表现最优，但直播场景需要支持更高并发。我们正在研发的"无锁合并"方案通过原子指令替代行锁，目标实现10万级TPS。另一个重要方向是支持分布式合并，突破单机性能瓶颈。
这次优化让我深刻体会到，数据库内核开发需要平衡性能、可靠性和可维护性。每个优化点都要经过百万级压力测试验证，这也是为什么我们花了三个月才让合并方案稳定上线。对于想深入数据库研发的同学，建议从InnoDB事务系统入手，这是理解现代数据库最好的切入点。