zookeeper 的顺序一致性，当 client 连接到不同 server 的时候如何保证？
cheesea · 2020-09-11 01:20:17 +08:00 · 1803 次点击这是一个创建于 1325 天前的主题，其中的信息可能已经有所发展或是发生改变。
假如有两台 zk server 。
client 先设置一个结点的值为 1，再更新为 2.
client 先从 server1 读取到最新的值 2，然后断开和 server1 的连接，再重新连接到 server2 。这时候 server2 有可能还没更新到最新值 2(比如因为网络的原因，server1 已经接收到 leader 的 commit 消息，但是 server2 还没有收到)，那不就不满足一致性了吗？
 |
1
yeqizhang 2020-09-11 08:28:11 +08:00 via Android
不存在的，你更新 Server1 为 2 时，其它也要更新为 2，所有节点 ack 后才算更新成功。不然你读到的 Server1 还是 1
|
|
2
yeqizhang 2020-09-11 09:08:07 +08:00 via Android
不好意思，我查了下，上面我是按我的记忆说的，事实不是如此。zk 不保证强一致性
|
 |
3
xx6412223 2020-09-11 09:42:49 +08:00
保证不了
|
 |
4
aliwalker 2020-09-11 10:49:39 +08:00
zk 只能保证 client 的 FIFO order，一个 client 发的所有请求会按照顺序执行，但并不是强一致性的，而是保证最终一致性。你说的这个情况是 zk 的读操作会读到 stale 值，需要通过 sync(path)一下才能保证最新值。
|
 |
5
cheesea OP @aliwalker 你好，我翻了一下官方文档，发现里面有这么一句话，
Single System Image : A client will see the same view of the service regardless of the server that it connects to. 没理解错的话，似乎无论连接到哪台服务器，获取的值都是相同的 。但是按照 zk 的同步机制，确实又不是强一致性的。很奇怪。 还有个问题请教下，假如有多个客户端并发写，zk 只能保证对每个客户端而言是有序的。比如 client1 写操作 A,B，client2 写 C,D，那最终写顺序可能是 A,C,B,D ？ |
 |
6
mitiskysean 2020-09-11 14:37:55 +08:00
ZK 确保达成一致后，不论你怎么读都是唯一且确定的，协议就是干这个事情的啊。至于你说的顺序，那不是 ZK 处理的范畴啊。对于 Value 设置成 A，然后改成 B，ZK 保证大家看到都是 B 。其它人又改成 C，那 ZK 只需确保都看到 C 仅此而已。这里的顺序是事件发生的顺序，zk 通过 FIFO 做到和事情发生顺序一致即可。
|
Select Language