什么是读写一致性？如何保证用户写后能读到自己的数据？
简化版
读写一致性是指用户写入成功后，后续读取能看到自己的写入结果。常见方案有写后读主库、按用户路由到主库、延迟切回从库、版本号判断、缓存更新和前端短暂使用写入结果兜底。
详细版
读写一致性问题常出现在主从复制、缓存、异步同步场景。比如用户刚修改昵称，刷新页面却看到旧昵称，通常是读请求打到了尚未同步的从库或旧缓存。
解决方案：
- 写后短时间读主库。
- 对当前用户或当前资源强制读主。
- 根据主从复制位点判断从库是否追上。
- 写入后更新或删除缓存。
- 返回写入后的最新对象，前端短时间直接展示。
- 使用版本号或更新时间，发现旧数据则重读主库。
面试要讲清：不是所有读都要读主库，否则会失去读写分离价值；通常只对刚写入用户、关键资源或短时间窗口做一致性保障。
完整版教学
一、读写一致性为什么常见
很多系统为了提升读性能，会做主从复制：
写请求 -> 主库
读请求 -> 从库问题是主从复制通常有延迟。用户刚把头像改了，主库已经成功，但从库还没同步；如果页面刷新读从库，就会看到旧头像。
这种体验很糟糕，因为用户会怀疑刚才的操作失败了。
二、写后读主库
最直接的办法是写入后的一段时间内读主库。
例如用户修改资料后，5 秒内查询用户资料都走主库：
update profile -> success
set read_primary_until = now + 5s
query profile -> if within window read primary优点是简单可靠；缺点是主库压力会上升。如果所有请求都长时间读主，就失去了读写分离的意义。
所以这个策略通常只对当前用户、当前资源、短时间窗口生效。
三、按复制位点判断从库是否追上
更精细的做法是记录写入时主库的复制位点，例如 binlog position 或 GTID。读从库前判断从库是否已经同步到该位点。
如果从库追上了，就读从库；如果没追上，就读主库或等待短时间。
这种方案更准确，但实现和运维复杂度更高，依赖数据库复制能力和中间件支持。
四、缓存场景下的读写一致
如果读请求先查缓存，即使数据库主从一致，缓存旧数据也会导致用户读到旧值。
常见策略是写入数据库成功后删除缓存，而不是直接更新缓存。下一次读缓存未命中，再从数据库加载新值。
但删除缓存也可能失败，所以关键场景会使用重试删除、延迟双删、消息驱动失效、缓存版本号等方式降低不一致窗口。
五、前端展示也可以兜底
有些体验问题可以通过产品层兜底。比如用户修改昵称成功后，接口直接返回最新昵称，前端立即更新页面状态，而不是马上重新查一次。
这不能替代后端一致性，但能改善用户体验。后端仍要保证后续查询最终一致。
六、哪些场景必须保证写后读
不是所有业务都需要写后立刻全局可见，但“用户刚操作完自己马上看”的场景通常要保证。比如修改资料、提交订单、发布评论、上传头像、保存配置，如果用户刷新后看到旧值，会以为操作失败。
还有一些后台系统更敏感。管理员刚修改开关配置，下一次查看仍显示旧配置，可能导致重复操作；商家刚改库存，页面仍显示旧库存，也容易引发误判。
而排行榜、统计报表、搜索结果这类本来就有延迟预期的功能，可以接受最终一致。设计时要把“交互确认页”和“异步展示页”区分开，别把所有读都做成强读主。
七、常见误区与追问
这道题要紧扣「读己之写」本身回答，不能把它混成泛泛的数据一致性套话。面试官通常会追问“写入怎么确认、失败怎么补、旧数据怎么防、成本在哪里”，所以回答要覆盖一致性目标、写入顺序、消息投递、幂等、补偿、对账和读写体验。
| 回答层次 | 要讲清的内容 | 容易漏掉的边界 |
|---|---|---|
| 核心结论 | 读己之写保证用户完成写操作后，自己随后读取能看到刚写入的结果，即使系统存在主从延迟或缓存延迟 | 不要停在名词解释 |
| 流程机制 | 用户提交写请求 -> 主库或主服务确认成功 -> 记录会话版本或写入时间 -> 后续读请求识别用户 -> 读主库或等待从库追平 -> 缓存更新后恢复普通读 | 要说清触发点、状态变化、确认点和失败兜底 |
| 工程取舍 | 用户刚改头像后立刻刷新页面，如果读到从库 2 秒前旧头像，体验上就是没有读己之写 | 一致性方案本质是在强一致成本、系统可用性、延迟和业务可接受的不一致窗口之间取舍 |
读己之写 面试拆解：
1. 用户提交写请求
2. 主库或主服务确认成功
3. 记录会话版本或写入时间
4. 后续读请求识别用户
5. 读主库或等待从库追平
6. 缓存更新后恢复普通读记忆钩子：先给结论，再拆流程，再讲数字例子和失败边界；回答「读己之写」时要围绕题目问法收束，不要把相邻概念堆成一段没有重点的名词清单。
- 误区：最终一致不需要读己之写。 很多业务可以对别人最终一致，但对写入者要立即可见。
- 误区：读主库就没有代价。 全部读主会增加主库压力，需要只对短窗口或关键用户读主。
- 误区：缓存 TTL 能解决读己之写。 TTL 只能最终过期，不能保证写后立即读到新值。
- 追问：常见实现方式？ 写后短时间读主、会话粘滞、版本号、读屏障或等待复制位点。
- 追问：主从延迟下怎么做？ 记录写入位点，读从前确认从库已追到该位点，否则读主。
- 追问：哪些场景很重要？ 用户资料、订单提交结果、支付状态和配置发布确认。
八、加强记忆
读写一致性关注“我刚写的，我自己要能看到”。常用套路是短时间读主、按用户或资源读主、等从库追位点、清理缓存、返回最新结果；关键是只对需要强体验的读做保障，不要把所有读都压回主库。