复制延迟案例(3)-单调读

前面异步复制读异常的第二个案例，出现用户数据向后回滚的怪状。

若用户从不同【从节点】多次读取，就可能这样。如图-4显示用户2345两次进行相同查询：

• 首先查询延迟很小的从节点
• 然后是延迟较大的从节点

若用户刷新网页，而每个请求被路由到一个随机的服务器，这种情况是很有可能的。

第一个查询返回最近由用户1234添加的评论，但第二个查询不返回任何东西，因为滞后的从节点还没有拉取写入的内容。效果上相比第一个查询，第二个查询是在更早的时间点来观察系统。

• 若第一个查询未返回任何内容，则问题不大，因为用户2345可能不知道用户1234最近添加了评论
• 但若用户2345先看见用户1234的评论，然后又看到它消失，则对用户2345，就会感觉头大

单调读保证这种异常不会发生。这是比强一致性（strong consistency）弱，但比最终一致性强的保证。当读取数据时，可能会看到一个旧值；单调读取仅意味着若一个用户顺序多次读取，则不会看到时间后退，即若先前读取到较新的数据，后续读取不会得到更旧数据。

实现单调读取的一种方案：确保每个用户总从同一副本读取（不同用户可读不同副本）。如基于用户ID散列选择副本，而非随机选择副本。但若该副本失败，用户的查询将需重新路由到另一个副本。