MySQL中高并发热点更新性能优化演示.pptVIP

MySQL中高并发热点更新性能优化 希羽 大纲 典型的业务场景及问题 MySQL层的现象 问题的本质原因 曾经的尝试方法 问题的难点 瞬间热点更新检测模型 瞬间热点更新线程调度 优化效果 典型的业务场景及问题 MySQL的性能瞬间急剧下降，TPS 1W -- 200 MySQL层的现象 绝大部分线程在更新商品库存量 update t set 库存量 -1 where ... 正常的查询和更新的RT也剧增 祈求业务降级以让DB抗过去 问题的本质原因 InnoDB层行锁机制 每行更新请求都会创建一个记录锁对象 成功加锁则执行，失败则被挂起 相同的记录锁被HASH到同一桶中 InnoDB层并发控制 被挂起的线程释放并发槽位，唤醒外层FIFO中对头线程 FIFO队头被调度进入InnoDB层，但相同因锁等待而被挂起，同上 瞬间线程都在InnoDB内部被挂起，而外层的FIFIO队列为空 并发控制并不严格 问题 加锁、解锁中众多O(n),O(n^2)的逻辑 n为相同桶中行锁对象的个数 曾经的尝试方法 2011年 禁掉死锁检测 死锁检测开销巨大，占~80% CPU 资源 facebook任然保留这样的做法 2011年开启挺过双11 2012年 严格并发控制 严格控制InnoDB层并发数 挺过双12 双12晚高峰的小插曲 2013年 600亿？ 问题的难点 热点记录的识别与控制 业务