刚改完数据刷新就不见了？聊聊主从延迟下的“读后写” (Read Your Writes) 陷阱

场景还原：
你开发了一个用户中心。为了扛住高并发，你配置了MySQL 读写分离：写操作走主库 (Master)，读操作走从库 (Slave)。
用户操作：

1. 用户点击“保存”，修改昵称为“极客张三” (写入 Master，成功)。
2. 页面自动跳转回“个人主页” (读取 Slave)。
3. 灵异事件发生：页面上显示的昵称依然是旧的“小白李四”。
4. 用户一脸懵逼，以为系统 Bug 了，又点了一次保存……

原因：
就在用户跳转的那几百毫秒里，Master 的 Binlog 还没来得及同步给 Slave。用户读到了**“过期的幻影数据”**。

1. 核心定义：什么是“读后写” (Read Your Writes)？

在分布式系统中，我们很难做到所有节点数据的强一致性（Strong Consistency）。通常我们接受“最终一致性”。

但在用户体验层面，有一个底线必须守住，那就是Read Your Writes Consistency：
“虽然全世界都可以晚一点看到我的更新，但我自己必须立刻看到我的更新。”

如果连我自己都看不到，我就会产生恐慌（是不是没保存成功？）。

2. 三大实战场景：延迟的痛

主从延迟通常在几十毫秒到几秒之间。以下场景对此极度敏感：

场景一：订单支付成功后的跳转

• 流程：用户支付成功 -> 写主库状态为PAID-> 跳转到“订单详情页”。
• 痛点：详情页查了从库，状态还是UNPAID。
• 后果：用户以为钱没扣成功，或者订单丢了，引发客诉甚至重复支付。

场景二：发布评论/帖子

• 流程：用户发帖 -> 写入主库 -> 刷新 Feed 流。
• 痛点：列表里找不到自己刚才发的帖子。
• 后果：用户会以为网络卡了，连续点发帖，导致系统中出现 N 条重复垃圾内容。

场景三：编辑个人资料

• 流程：修改头像/简介 -> 保存 -> 刷新。
• 痛点：头像还是旧的。
• 后果：用户体验极差，感觉系统不稳定。

3. 解决方案：如何填补那几毫秒的时间差？

我们不需要为了这几毫秒，就把整个系统回退到单机模式。以下是三种从简到繁的策略。

策略一：强制关键业务走主库 (Force Master)

这是最简单、最粗暴，也是最常用的方法。

逻辑：
将查询分为两类：

1. 对一致性不敏感的：如首页热榜、商品搜索、查看别人的主页。 ->走从库。
2. 对一致性极敏感的：如订单详情、我的个人主页、支付结果查询。 ->强制走主库。

代码实现 (伪代码):

// 查看别人的主页 (允许延迟)Useruser=slaveDao.getUser(otherUserId);// 查看自己的主页 (必须最新)UsermyProfile=masterDao.getUser(myUserId);

评价：成本最低，但如果“关键业务”的读流量本身就很大（比如用户疯狂刷自己的订单），会削弱读写分离的效果。

策略二：缓存标记法 (Cache Marking)

利用 Redis 做一个“短期记忆”。

逻辑：

1. 写入时：更新主库后，顺便在 Redis 里设置一个 Key，比如user_update_1001，设置过期时间（例如 2 秒，覆盖预估的延迟时间）。
2. 读取时：先判断 Redis 里有没有这个 Key。

• 有：说明该用户刚刚有写操作，可能存在延迟 ->走主库。
• 无：说明该用户很久没更新了，数据是稳的 ->走从库。

评价：这是一个非常聪明的动态路由方案。它只让那些“刚修改过数据”的用户走主库，其他人依然走从库，完美平衡了性能与一致性。

策略三：GTID 透传 (Global Transaction ID)

这是数据库中间件（如 ShardingSphere, MyCat）层面的高端玩法。

逻辑：

1. 写入时：Master 返回当前事务的 ID (GTID)，比如100。
2. 读取时：客户端带着这个GTID=100去请求中间件。
3. 中间件判断：检查从库当前的执行进度。如果从库只同步到了99，中间件就等待（或去主库查）；如果从库到了100，就直接查从库。

评价：对业务代码零侵入，数据最准确。但实现难度大，依赖成熟的数据库中间件架构。

4. 总结

“读写分离”不是万能药，引入架构复杂度的同时，必然引入数据一致性问题。

解决Read Your Writes的核心心法是：区分对象。

• 别人看我，可以晚一点。（最终一致性）
• 我看我自己，必须是现在。（即时一致性）

对于 90% 的业务，“关键业务强制读主”或“Redis 缓存标记”足以解决问题。