复制滞后

在主从复制架构中，如果一个应用从一个异步的从节点读取数据，而该副本落后于主节点，则应用可能会读到过期的信息，这会导致数据库中出现明显的不一致。

读写一致性需要考虑不同设备登录、多数据中心等问题。

复制滞后的解决思路主要包括读自己的写、单调读、前缀一致读等几种。

读自己的写

如果用户访问可能会被修改的内容，从主节点读取，否则从从节点读取。可以通过是否查询自己的数据、判断数据更新时间等方案，来判断是否去主节点读取数据。

单调读一致性是一个比强一致性弱，但比最终一致性强的保证。当读取数据时，单调读保证，如果某个用户依次进行多次读取，则他绝不会看到回滚现象，即在读取较新值之后又发生读旧值的情况。

实现单调读的一种方式是，确保每个用户总是从固定的同一副本执行读取（不同用户可以从不同的副本读取）。例于，基于用户 ID 的哈希选择副本。

前缀一致读保证，对于一系列按照某个顺序发生的写请求，读取这些内容时也会按照当时写入的顺序（注意与单调读的区别，单调读是一个key，前缀一致读是多个key）。

这是分区数据库中出现的一个特殊问题，不同分区独立运行，因此不存在全局的写入顺序。

一个解决方案是确保任何具有因果顺序关系的写入都交给一个分区来完成，但这会造成效率大幅度降低；另一种方式是使用算法显式追踪事件因果关系。