李亚林
获得徽章 0
赞了这篇文章
1.在ZAB协议中需要保证leader已经提交的proposal在每一个
flower中都需要提交，以此来保证一致性。所以在leader挂掉后会找到
zxid最大的flower节点选举为准leader节点，在进行数据同步流程，到这里
都能理解，但是存在一种情况，可能会导致数据不一致。
大致对上图流程做个说明。
1.server1是最开始的leader节点
2.server1广播p1并且得到了server2，server3的响应
3.server1广播p2得到了server2的响应（server3）还未收到，但是这个时候加上leader自己p2其实已经满足过半要求了
4.server1发送对p1的commit请求c1（由2得知p1过半所以可以发送c1）
5.server1发送对p2的commit请求c2（由3得知p2过半所以可以发送c2）
但是在发送c2的时机，server宕机了，没发出去，实际上server1已经做了c2的提交了
那么问题来了，这个server2可能选举为leader节点，但是如何恢复对于p2的提交喃？因为这个时候没有任何一个节点收到了c2并且server2也没有收到p2请求。如果不对p2做c2提交的话，是否就不满足ZAB协议了喃，而且是否也不满足一致性了喃，因为如果server1重启了过后c2是做了提交的。
我在哪一步理解错误了喃？麻烦对此有过研究的大神帮忙解答下，感谢感谢！
flower中都需要提交，以此来保证一致性。所以在leader挂掉后会找到
zxid最大的flower节点选举为准leader节点，在进行数据同步流程，到这里
都能理解，但是存在一种情况，可能会导致数据不一致。
大致对上图流程做个说明。
1.server1是最开始的leader节点
2.server1广播p1并且得到了server2，server3的响应
3.server1广播p2得到了server2的响应（server3）还未收到，但是这个时候加上leader自己p2其实已经满足过半要求了
4.server1发送对p1的commit请求c1（由2得知p1过半所以可以发送c1）
5.server1发送对p2的commit请求c2（由3得知p2过半所以可以发送c2）
但是在发送c2的时机，server宕机了，没发出去，实际上server1已经做了c2的提交了
那么问题来了，这个server2可能选举为leader节点，但是如何恢复对于p2的提交喃？因为这个时候没有任何一个节点收到了c2并且server2也没有收到p2请求。如果不对p2做c2提交的话，是否就不满足ZAB协议了喃，而且是否也不满足一致性了喃，因为如果server1重启了过后c2是做了提交的。
我在哪一步理解错误了喃？麻烦对此有过研究的大神帮忙解答下，感谢感谢！
展开
评论
点赞
ZAB协议中选leader过程的疑问。
在ZAB协议中要求，选定的leader必须拥有最大的ZXID,但是在看了FastLeaderElection后发现了一中情况会导致选出的leader并不拥有最大的ZXID
具体流程见图片，在s4,s5服务器消息出现延迟的情况下s3服务器会被选定为leader，但其实s3并不是zxid最大的节点。
麻烦问下各位大神，是我对算法的理解有问题吗。
在ZAB协议中要求，选定的leader必须拥有最大的ZXID,但是在看了FastLeaderElection后发现了一中情况会导致选出的leader并不拥有最大的ZXID
具体流程见图片，在s4,s5服务器消息出现延迟的情况下s3服务器会被选定为leader，但其实s3并不是zxid最大的节点。
麻烦问下各位大神，是我对算法的理解有问题吗。
展开
评论
点赞
basic paxos算法中在在多个proposer提出提议后会最终会决定出一个决议进行状态机的更新，这样的确保证了一致性，但是有个问题是，另外一个决议就被丢失了。这样如何保证在分布式日志系统中每个提议都不被丢失啊。具体算法见下面链接，感谢各位大神解答，也欢迎对分布式一致性的问题做讨论
2
1