复制延迟催生的三种一致性异常读己之写单调读一致前缀读

在异步复制下从从库读取数据可能读到过时信息，这种不一致只是暂时状态、停止写入等 足够久从库最终会追上主库，因此被称为最终一致性——”最终”一词故意含糊，因为复制 延迟没有上限保证，正常情况下可能只有几分之一秒，但系统接近极限或网络出问题时可能 达到几分钟。复制延迟在实践中会催生三类具体的一致性异常。读己之写（也称读写一致性）： 用户写入数据后立刻查看，如果查看请求落到还没同步到这条写入的从库上，用户会觉得 “我刚提交的东西怎么不见了”；解决办法包括读取用户自己可能修改过的内容时强制走主库、 基于最近更新时间窗口判断是否该走主库、客户端记住最近写入的时间戳并确保从库追上该 时间戳才提供服务。单调读：如果同一用户先后两次读取分别落到延迟不同的从库上，可能 先看到某条新评论、刷新后这条评论又”消失”了（第二次读到了更旧状态），像是”时光倒流”； 解决办法通常是保证同一用户始终从同一个副本读取（比如按用户ID哈希选副本）。一致 前缀读：如果一系列有因果关系的写入（比如一问一答）分别经过延迟不同的复制路径， 观察者可能先看到”答案”、后看到”问题”，违反了因果顺序；这在分区数据库里尤其突出， 因为不同分区独立复制、不存在全局写入顺序，解决办法之一是确保有因果关系的写入落在 同一个分区。这三种保证从弱到强、各自针对不同的用户体验问题，共同点是应用如果假装 复制是同步的（”写完立刻处处可见”），复制延迟就会变成实实在在的麻烦。

结构图：

flowchart TD
    A[复制延迟导致最终一致性] --> B[读己之写: 自己的写入立刻可见]
    A --> C[单调读: 不会看到比之前更旧的数据]
    A --> D[一致前缀读: 有因果关系的写入按正确顺序可见]
    B -.解法: 判断可能修改过则强制走主库或按时间戳追新.-> B
    C -.解法: 同一用户固定路由到同一副本.-> C
    D -.解法: 有因果关系的写入落在同一分区.-> D