zhangyixin1222 commented on issue #2056: URL: https://github.com/apache/rocketmq/issues/2056#issuecomment-636595635
> > 已提交是多数认可的充分非必要条件，多数认可是已提交的必要非充分条件。比如结点1发送的完appendentry指令给123456时候挂了，而且123456都记录了该appenentry时候就属于多数认可但未提交例子。 > > 看起来这里就是我们的分歧所在了，我理解的是在raft里，123456 如果都记录了该term = 6 appendEntry（都存有该log entry的replica），那么此时该log entry 就已经提交了。这是和paxos/zab 不一样的地方。 > > _准确来说，raft的leader选举过程相当于 paxos的phase1， raft的appendEntrys相当于paxos的phase 2。 [Paxos vs Raft](https://arxiv.org/pdf/2004.05074.pdf)_ > > > 对于因为选举中存在多数同意但少数不同意（但不是反对，反对是loggedterm延滞引发） 则是脑裂引起的没争取到该部分结点认同的leader资格。 > > 可以详细定义一下什么是同意，什么是不同意，什么是反对吗？（就是具体的判断条件），因为这是raft原论文里没有出现过的概念，为避免歧义，我们还是争取尽量准确地定义术语吧 raft只有同意跟不同意两种情况，即票数1跟票数0。为了加速感知到日志纪录的滞后性并进入follower，引入反对票。可以理解为每个结点在收到选举请求后，根据收到的loggedterm，loggedindex，termwanted进行对比，如果前两者自身更大，则反馈结果中填入票数-10000，如果前两者自身更小或相等而自身所知termwanted更大，则反馈结果中填入票数0，否则反馈结果中填入票数1。选举发起人收到多数结点反馈或超时后计算总得票数据此获得leader权 ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
