MySQL-5.6主从架构下写入后立即读请求路由至主节点方案咨询

这绝对是MySQL主从读写分离架构里最头疼的问题之一——刚写完数据立刻读，结果从库还没同步完，拿到旧数据。我在实际项目里踩过不少坑，下面分享几种靠谱的解决方案，覆盖中间件、应用层、数据库本身的不同思路：

中间件是解决这类问题最常用的方案，它们本身就负责读写分离的路由逻辑，很容易扩展强制读主的规则：

• ShardingSphere：用它的Hint机制精准控制。写操作完成后，在当前线程里调用HintManager.getInstance().setMasterRouteOnly(true);，之后的读请求就会强制路由到主库，用完记得调用close()释放资源。这种方式适合需要精确控制某几次读请求的场景。
• ProxySQL：支持会话级别的路由规则。可以在写操作后执行SET @FORCE_MASTER = 1;，ProxySQL会根据这个自定义变量把后续读请求导向主库；等主从同步完成后，再执行SET @FORCE_MASTER = 0;切回从库。也可以配置基于延迟的自动路由，比如当从库延迟超过2秒时，自动把读请求转发到主库。
• MyCat：支持SQL注释Hint，只需要在写后的读SQL前加上/*master*/注释，MyCat就会自动把这条SQL路由到主库。比如/*master*/ SELECT * FROM table WHERE id = 1;，简单直接，不需要修改太多代码。

如果不想依赖中间件，在应用层自己控制也是可行的：

• 缓存兜底：写操作完成后，立刻把数据写入分布式缓存（比如Redis）或者本地内存缓存。后续的读请求优先读取缓存，等主从同步完成（可以设置一个略大于平均同步延迟的过期时间）后再失效缓存。这种方式能减轻主库压力，但要注意缓存一致性问题。
• 会话级标记：在用户的会话（比如HTTP请求上下文、用户会话）里维护一个“刚执行过写操作”的标记。比如用户提交表单后，在当前请求上下文里标记needReadMaster = true，后续同一会话的读请求都直接使用主库连接；会话结束或者过了3-5秒后自动清除标记。这种适合用户操作有连贯性的场景，比如提交后立刻查看详情。
• 双数据源直接切换：应用层维护两个数据源——主库数据源和从库数据源。写操作后的读请求直接使用主库数据源执行，普通读请求用从库数据源。这种方式最直接，但要注意数据源的连接池管理，避免连接泄漏。

从数据库本身的同步机制入手，减少或者避免延迟带来的问题：

• 半同步复制：把默认的异步复制改成半同步（开启rpl_semi_sync_master_enabled=1和rpl_semi_sync_slave_enabled=1）。主库在收到至少一个从库的binlog确认后，才向应用层返回写成功。这样写操作完成时，至少有一个从库已经拿到了数据，后续读请求即使路由到这个从库，也能读到最新数据。不过半同步还是存在极小概率的延迟，极端场景可能需要配合其他方案。
• 监控延迟动态路由：通过SHOW SLAVE STATUS里的Seconds_Behind_Master字段监控从库延迟。如果延迟超过设定的阈值（比如1秒），就把读请求路由到主库；延迟正常时再切回从库。这种方式比较灵活，能自动适应主从同步的状态。

很多ORM框架或者数据库驱动都支持读写分离的动态切换：

• MyBatis读写分离插件：比如一些第三方插件支持在方法上加注解，比如@Master，标记该方法的读请求强制走主库。只需要在写操作后的读方法上加上这个注解，就能实现精准路由。
• Spring AbstractRoutingDataSource：自己实现动态数据源路由，通过ThreadLocal存储当前线程的路由标记（比如MASTER/SLAVE）。写操作后设置标记为MASTER，读请求完成后再重置为SLAVE，实现线程内的路由切换。

• 不要滥用强制读主的逻辑，否则会把大量读请求压到主库，导致主库过载。只在写后立即读的关键场景使用。
• 主从延迟的监控很重要，无论是中间件还是应用层，最好能实时感知同步状态，再做路由决策。
• 对于数据一致性要求极高的场景，比如金融类业务，建议直接读主库，不要用读写分离，避免任何一致性风险。

内容的提问来源于stack exchange，提问作者Mannar mannan