这方法真管用，MySQL同步延迟终于不再是问题了，效果超出预期

（来源：某电商平台资深运维工程师王工的实践分享）

“这方法真管用，MySQL同步延迟终于不再是问题了，效果超出预期。”这话是我上个星期在团队内部复盘会上说的，当时心情特别舒畅，感觉压在心里一年多的一块大石头总算落了地，我们平台平时访问量还行，但一到像“618”、“双十一”这种大促节点，订单量瞬间暴涨，最让人头疼的就是数据库的读写分离架构里，那个从库的同步延迟问题。

简单说,就是主库（负责写入数据，比如用户下单）的数据，要同步到从库（负责读取数据，比如用户查订单）上，这个同步过程因为各种原因会变慢，平时延迟几秒钟我们还能接受，但大促时，眼睁睁看着延迟从几秒变成几分钟，甚至十几分钟，这就出大问题了，经常有用户投诉，说刚下的订单在App里查不到，或者看到的库存数量不对，其实就是因为查询请求走到了那个数据还没同步完的从库上，我们技术客服那边接到这类工单，压力也特别大。

为了解决这个问题,我们之前试过不少办法，按照网上一些常见的优化建议，调整过MySQL的一些参数，像是什么sync_binlog、innodb_flush_log_at_trx_commit之类的，希望能让主库写日志更快一点，也尝试过给从库换更好的硬件，CPU更强，硬盘换成SSD，这些措施不能说完全没用，平时确实有点改善，延迟能控制在秒级以内，但一到流量洪峰，老问题照样出现，感觉就像是给一个体质偏弱的人吃了点补品，平时精神点，但一干重活还是累趴下，我们甚至考虑过要不要上更新的数据库技术，但那种改造动静太大了，风险和成本都太高，短期内根本不现实。

（来源：王工在技术社区看到的关于“预写日志并行复制”的深度解析帖）

后来,我花了几个周末的时间，在各种技术社区里翻找有没有更根本的解决方案，直到我看到一篇帖子，详细讲了一种叫做“基于逻辑时钟的并行复制”的方法（MySQL 5.7版本以后支持的一种更高级的模式），帖子里没有用一大堆难懂的专业术语，而是打了个很形象的比方，它说旧式的同步，就像一个只有一个传送带的工厂，主库生产出来的包裹（数据变更）必须严格按照顺序一个个放到传送带上，从库那边也只能有一个人按顺序接收和拆包，如果前面有个大包裹（比如一次更新了十万条记录的大事务）卡住了，后面所有小包裹都得等着，整个流水线就堵死了。

而新的并行复制模式,就像是升级成了一个智能分拣系统，系统会给每个包裹贴上精准的时间戳标签（逻辑时钟），并且识别出那些彼此之间没有关联的包裹（比如修改不同表或者同一表不同行的事务），这样，从库那边就可以开启多个窗口（多个工作线程），同时处理这些互不干扰的包裹，大大提高了吞吐量，只要保证有依赖关系的包裹按顺序处理就行，其他的完全可以并行，这个比方一下子就让我明白了问题的关键：核心不是主库写的不够快，也不是从库硬件差，而是从库那个“拆包”的方式太落后了，是单线程的，能力有瓶颈。

（来源：王工团队在测试环境的验证和线上环境的灰度部署过程）

看到这个思路后,我特别兴奋，感觉找到了方向，我们用的是MySQL 8.0，本身就支持这个功能，我们没有贸然直接在线上所有从库操作，而是先搭建了一个和线上环境一模一样的测试库，用脚本模拟大促时的高并发写入压力，我们小心翼翼地调整从库的复制模式参数，从老的模式改成了这种并行的模式。

在测试环境的结果让我们团队所有人都眼前一亮,在同样巨大的写入压力下，从库的同步延迟曲线变得非常平稳，几乎成了一条贴近零延迟的直线，再也没有出现分钟级的延迟高峰，CPU利用率也比之前更均衡了，经过了好几轮压测，确认了稳定性和数据一致性都没问题后，我们才选了一个业务低峰期，对线上一个非核心业务的从库进行了灰度切换，观察了一周，效果和测试环境一样好。

在上次大促前,我们信心十足地把所有核心业务的从库都切换到了并行复制模式，大促当天，我们整个运维团队都严阵以待，死死地盯着数据库监控大盘，结果，以往那个刺眼的、代表同步延迟的红色柱状图，这次一直保持着健康的绿色，延迟始终在几百毫秒级别徘徊，完全不影响业务查询，业务部门反馈，这次几乎没有再收到“下单后看不到订单”的用户投诉，那种感觉，就像是给数据库引擎换上了一颗更强劲的心脏，吞吐能力得到了质的提升。

我现在逢人就说,对于高并发场景下MySQL的同步延迟问题，如果你们已经用尽了常规优化手段效果不佳，并且数据库版本在5.7以上，真的应该好好研究一下并开启并行复制这个功能，它没有我们想象中那么复杂和危险，但带来的效果是实实在在的，可以说是花费最小、收益最大的优化手段之一了，效果绝对是超出了最初的预期，终于让读写分离架构真正发挥了它应有的作用，解决了业务痛点。