主从复制延迟带来的业务问题及三种应对方案

[[读写分离原理及”主从集群”与”主备集群”的本质区别]]虽然原理简单，但真正落地会引入复制延迟这个设计复杂度。以MySQL为例，主从复制延迟一般在1秒左右，如果同步的数据量大，延迟到1分钟也是可能的——这个延迟带来的典型业务问题是：如果业务服务器刚把数据写入主机，紧接着（延迟窗口内）就发起读操作，这个读请求会被分流到从机，而从机此时还没收到主机同步过来的最新数据，读到的就是旧数据，业务上就会出现类似”用户刚注册完立刻登录，系统却提示他还没有注册”这种明显的体验问题。应对这个问题有三种常见思路，各自的适用边界不同。第一种是”写操作后的读操作指定发给主机”：比如注册完成后紧跟着的登录读取也强制走主机，这种做法和具体业务逻辑强绑定，需要开发人员对哪些场景要这样处理有明确认知，一旦有新同事不了解这条约定，就可能不小心引入bug。第二种是”二次读取”，也叫读从机失败后再读一次主机：这种方式和业务逻辑无关，只需要在底层数据库访问层做一次封装即可，实现成本较低，但代价是一旦从机读取”失败”（读不到预期数据）的情况变多，会显著增加主机的读操作压力——例如遭遇账号暴力破解攻击时，大量本该失败的登录尝试会持续触发二次读取，可能把主机的读压力直接打垮。第三种是”关键业务读写全部走主机，非关键业务才用读写分离”：例如用户管理系统里，注册和登录这类关键业务全部直接访问主机，而用户自我介绍、爱好、等级这类非关键业务允许走读写分离——即使用户刚改完自我介绍、查询时看到的还是旧版本，这种体验影响和”登录不了”比起来轻微得多，可以接受。三种方案没有绝对优劣，本质上是在”业务侵入程度”和”主机压力”之间做权衡，需要结合具体业务的关键程度选择。