MySQL中高并发热点更新 性能优化 希羽
大纲 典型的业务场景及问题 MySQL层的现象 问题的本质原因 曾经的尝试方法 问题的难点 瞬间热点更新检测模型 瞬间热点更新线程调度 优化效果
MySQL的性能瞬间急剧下降，TPS 1W --> 200 典型的业务场景及问题 MySQL的性能瞬间急剧下降，TPS 1W --> 200
MySQL层的现象 绝大部分线程在更新商品库存量 正常的查询和更新的RT也剧增 祈求业务降级以让DB抗过去 update t set 库存量 -1 where ... 正常的查询和更新的RT也剧增 祈求业务降级以让DB抗过去
问题的本质原因 InnoDB层行锁机制 InnoDB层并发控制 问题 每行更新请求都会创建一个记录锁对象 成功加锁则执行，失败则被挂起 相同的记录锁被HASH到同一桶中 InnoDB层并发控制 被挂起的线程释放并发槽位，唤醒外层FIFO中对头线程 FIFO队头被调度进入InnoDB层，但相同因锁等待而被挂起，同上 瞬间线程都在InnoDB内部被挂起，而外层的FIFIO队列为空 并发控制并不严格 问题 加锁、解锁中众多O(n),O(n^2)的逻辑 n为相同桶中行锁对象的个数
曾经的尝试方法 2011年 禁掉死锁检测 2012年 严格并发控制 2013年 600亿？ 死锁检测开销巨大，占~80% CPU 资源 facebook任然保留这样的做法 2011年开启挺过双11 2012年 严格并发控制 严格控制InnoDB层并发数 挺过双12 双12晚高峰的小插曲 2013年 600亿？
问题的难点 热点记录的识别与控制 业务层 存储层实现则较通用，但有难度 识别宝贝id进行排队和流控 集群环境下，多app可能全部到一台DB上 类似KV的存储容易，key或row_id MySQL的SQL中识别非常困难
瞬间热点更新检测模型 瞬间热点 思路：转变为对锁争用！ 热点可能只是某一瞬间，不可持续 对记录访问进行监控？ 如果同一行记录的加锁有较多线程等待，则此条记录为瞬间热点记录
瞬间热点更新线程调度 减少锁对象 线程调度出InnoDB层 如果线程访问的行锁已经有t个线程在等待，则当前线程不创建任何锁对象 根据请求锁的space/page_no/heap_no被影射到外层的HASH中 同一桶中线程串行，不同桶中线程则并行 同一桶中轮询重试加锁 重试超时强制进入，避免调度上的死锁
加锁逻辑图
优化效果 Default: 50 Deadlock Disabled: 250 Hot Rows Control: 10500 测试
QA