SIGMOD论文精读丨TDSQL锁管理优化如何破解高并发性能困局？

两阶段锁（2PL）作为数据库并发控制的基础协议，通过“增长阶段获取锁、收缩阶段释放锁”的严格规则保障事务隔离性。但在腾讯微信红包、直播电商等高并发业务场景中，其局限性被无限放大：

一、锁竞争导致吞吐量断崖式下跌

严格2PL要求事务必须等待冲突事务提交释放锁，当热点数据（如商品库存、红包金额）被高频访问时，大量事务陷入阻塞。测试数据显示，MySQL在1024线程并发更新单热点行时，TPS甚至低于单线程串行执行，并发优势完全失效。

二、死锁检测成本随并发度飙升

传统2PL通过遍历锁队列检测死锁，队列长度随并发度线性增长，单次检测耗时从微秒级暴增至毫秒级，成为新的性能瓶颈。

三、锁持有时间与并发需求的矛盾

长事务或主从同步延迟会延长锁持有时间，进一步加剧阻塞。例如，同步复制场景中，锁等待时间占事务总耗时的比例高达40%，严重拖累系统响应速度。

TDSQL的锁管理优化并非单点改进，而是一套循序渐进的系统性方案，从基础层降低开销，再到核心层突破热点瓶颈。

1. 通用锁优化：轻量级机制提升基础性能

轻量级锁管理：

传统 InnoDB 中，100 个事务更新 10 行数据会产生 1000 条锁记录，高并发时锁系统成为瓶颈4。TDSQL 引入trx_lock_wait变量，通过无锁哈希表记录等待事务 ID，仅在必要时创建锁对象，锁开销降低超 50%。

无拷贝活跃事务列表：

MVCC 场景下，传统方案需拷贝活跃事务列表以避免读锁竞争，高并发时拷贝开销占比达 30%6。TDSQL 通过del_ts（事务删除时间戳）属性，结合快照直接判断数据可见性，消除列表拷贝开销。

2. 热点数据优化：队列锁到组锁的演进

队列锁机制（初步优化）：

当热点行等待事务数超过 32 个时，将锁等待队列迁移至热点哈希表hot_row_hash，事务按顺序排队，避免全局锁竞争。但该方案在主从同步等高延迟场景中，仍因排队等待导致性能瓶颈。

组锁机制（核心创新）：

• 热点分组与角色划分：将更新同一热点行的事务分为 “领导者（Leader）” 和 “跟随者（Follower）”，Leader 负责锁获取与释放，Follower 免锁串行执行更新，消除锁竞争。

• 依赖列表与顺序保证：通过全局递增 IDhot_update_order维护事务依赖链，确保提交顺序与更新顺序一致，回滚时按逆序执行，避免事务一致性被破坏。

• 组提交优化：在 2PC 中批量提交同组事务，减少日志刷盘次数。同步复制场景下，性能较传统 2PL 提升 22.3 倍。

图：组锁核心设计

3. 正确性保障与工程优化

死锁处理：放弃传统死锁检测，改用超时机制，当检测到热点与非热点数据交叉访问时主动回滚冲突事务，避免级联阻塞。

动态批大小调整：无等待事务时，Leader 直接释放锁，新事务自动成为新 Leader，避免空队列导致的延迟飙升。

TDSQL的锁管理优化方案在实践中展现出惊人的性能提升与业务价值：

基准测试碾压级领先：在高竞争工作负载下，性能相比最先进的优化方法提升6.5倍，相比传统系统提升22倍；TPC-DS测试中实现72.6M QphDs，成为吞吐量领导者，并发查询速度提升2倍，成本降低至1/3。

图：线上业务测试效果，绿色时间段为应用组锁后，性能不会往下抖动

真实业务价值凸显：腾讯金融支付系统升级后，日常交易性能提升30%，双11等热点场景TPS提升近10倍，延迟抖动降低80%；动态组锁机制使系统在流量突增时保持稳定，相同负载下减少50%服务器资源占用。

截至2024年，TDSQL已在腾讯内部超2万金融数据库实例中部署，覆盖微信支付、腾讯云数据库等核心业务，并通过腾讯云向外部客户开放，其组锁机制成为处理高并发交易的行业参考方案。