数据库主从延迟：读到了旧数据的那次排查

场景

用户改完收货地址，刷新页面，地址还是旧的。再刷新一次，新的了。客服反馈了几次，都是“改完立刻看是旧的，等几秒再看就是新的”。

排查

写操作走主库，读操作走从库，主从之间用 binlog 同步。查从库的延迟监控，平时在 100 毫秒以内，活动期间涨到 3 秒。用户改完地址立刻读，读请求落到从库，从库还没同步到那条更新，读到的就是旧数据。

为什么延迟会涨？活动期间写了大量订单，主库的 binlog 产生速度超过了从库的回放速度。从库是单线程回放，主库是多线程写，写得越快，差距越大。

改了三处

第一处，刚写完就读的场景改成读主库。用户改地址、改头像、下单后查订单详情，这些“写后立刻读”的接口，读操作强制走主库，不走从库。

第二处，从库回放改成并行回放。按库分片并行，主库多线程写的 binlog，从库也能多线程回放，延迟从 3 秒降到 200 毫秒以内。

第三处，给读从库的接口加延迟兜底。读到的数据带一个版本号，调用方发现版本号比写操作返回的版本号旧，就重试一次读主库，最多重试两次。

验证

活动期间再压测，主从延迟峰值 180 毫秒。写后立刻读的接口 100 次测试，全部读到新数据，没有再出现旧数据。主库读请求量涨了 15%，在可接受范围内。

教训

读写分离不是“读都走从库”这么简单。写后立刻读的场景必须走主库，否则用户看到的就是旧数据。从库延迟平时看不出来，一到写量大的时候就暴露。监控主从延迟要看峰值，不看平均值，平均值 100 毫秒不代表没有 3 秒的尖峰。