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

x33g5p2x  于2022-08-17 转载在 其他  
字(0.5k)|赞(0)|评价(0)|浏览(325)

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

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

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

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

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

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

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

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

相关文章

微信公众号

最新文章

更多