读一致性 (Read Consistency) 关注的是：当一个读操作发生时，客户端能否读到“最新”的数据。
在分布式系统或缓存场景下，读一致性问题通常表现为：数据库已经更新了，但缓存里还是旧值，或者不同用户在同一时间读到了不同的版本。
读一致性级别
按一致性程度从强到弱排序，具体实现细节请参考子文档：
- 强一致性 (Strong Consistency)：写操作完成后，任何后续读都能读到最新值。
- 会话一致性 (Session Consistency)：保证“读己之所写 (Read-Your-Writes)”。
- 单调读一致性 (Monotonic Read Consistency)：保证读到的数据版本不会“倒退”。
- 最终一致性 (Eventual Consistency)：保证数据最终会一致，但不保证立即读取最新值。
场景与对策
在分布式系统中，解决读一致性问题通常需要在 延迟 (Latency)、可用性 (Availability) 和 一致性 (Consistency) 之间进行权衡：
| 场景分类 | 典型问题 | 核心对策 |
|---|---|---|
| 架构延迟 | 主从同步滞后、CDN 缓存过期 | 强制读主、等待 GTID 同步、延迟双删 |
| 并发冲突 | 缓存回填旧值、失效操作失败 | 分布式锁 (SETNX)、Binlog 订阅失效、版本号比对 |
| 路由漂移 | 节点切换导致数据“回滚” | 会话粘性 (Session Stickiness)、一致性哈希 |
| 分布式复杂性 | 时钟漂移、异步写回滞后 | Quorum NWR 模型、合理的 TTL 保底 |
总结
无论采用何种方案，合理的 TTL (Time To Live) 始终是数据自动纠错的最终保底手段。在设计系统时，应根据业务对一致性的敏感程度选择合适的权衡方案。