DDIA 第九章 一致性和共识协议 Part1 线性一致性,在北京时间本周日(20221113)上午十一点,欢迎大家一块来讨论。
网站:https://ddia.qtmuniao.com
入会地址:https://meeting.tencent.com/dm/qFA2oGFHnczc
文字稿:https://zircon-penalty-7f7.notion.site/Chapter-9-Consistency-and-Consensus-f80d66bdfb7b4d1281722914239a563a

关于本节想讨论的可以在 https://distsys.cn/d/36-ddia-di-jiu-zhang-yi-zhi-xing-he-gong-shi-xie-yi-part1 跟帖。

有同学问到:线性一致性的保证要从那个层面来理解,是系统提供的,还是客户端看到的?如果仅仅是系统提供的,但客户端还是有可能看到非线性一致,那好像并没有简化应用层的编程模型?
举个例子:
初始 x = 0

  1. 客户端 A 发出写请求 [t = 0 | t = 5, x = 1| t = 6]。含义是 t = 0 时刻发出请求,t = 5 时刻服务端生效,t = 6 请求返回。
  2. 客户端 B 有两个线程
    • 线程 1 发出读请求 [t=1 | t = 6 | t = 7],读到 x = 1;
    • 线程 2 发出读请求 [t= 3 | t =4 | t = 10],读到 x = 0;

这样虽然系统保证线性一致性,但是从客户端的视角来看,由于网络延迟的不确定性,仍然是先发出的请求看到了旧的值。

我想了想,还是简化了编程模型的。
上述例子两个请求是没有依赖关系,而且是并发的,所以确实可能出现先看到了新值又看到了旧值。但这种因果的倒置是因为有我们这个绝对客观的上帝视角。

如果仅是从编程角度,是不能通过时间先后来判断多个渠道拿到的结果的因果。想要维持因果,则:

  1. 只使用一个通道。比如是只使用一个线程来请求并设置 x 的值。
  2. 让多个通道显式同步。比如只有一个线程拿到结果后,才让另外线程发出请求。

如果系统本身就不提供线性一致的话,我们仅用一个通道都会拿到不符合因果的结果。

    qtmuniao
    感谢木鸟大佬的回复,这块大概理解了
    线性一致性只对单客户端或者是保证先后顺序的多客户端请求提供更高级别的一致性保障。对于时间戳不同步的多客户端而言,无法避免并发问题,这个时候线性一致性可能就退化成类似顺序一致性这种更弱的保障了

    3 个月 后
    1 年 后

    只使用一个通道。比如是只使用一个线程来请求并设置 x 的值。
    让多个通道显式同步。比如只有一个线程拿到结果后,才让另外线程发出请求。

    这两种方法我感觉还是会影响性能,感觉本来是asynchronous的结果写的时候还是得排队了……

    我觉着可以在response里传一个server端读到值的timestamp,然后client端比较这个记录的timestamp,而不是response送到client端的timestamp,让client端而不是server端来处理就可以(比如线程2那个虽说client端晚点收到,但比较response里的timestamp,就可以把这个response忽略掉)

    说点什么吧...