Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

raft.cpp 函数appendEntries第629行if(m_logs.size() == 0) #2

Open
wz991007 opened this issue May 19, 2023 · 4 comments
Open

raft.cpp 函数appendEntries第629行if(m_logs.size() == 0) #2

wz991007 opened this issue May 19, 2023 · 4 comments
Labels
question Further information is requested

Comments

@wz991007
Copy link

这样直接判断为零就填充,是否有问题, 想象一种情况,一个server从集群启动开始就挂了,然后再经历几个term之后恢复,其中还没有日志记录,但当前任期leader给他发的log默认是按照自身的log最大值发送的,而server接收到之后却直接写入了(因为没有log记录),这里应该会出现不一致吧,感觉逻辑不应该这样。这里我觉得可以直接吧m_logs为空的情况归类到preindex = m_logs.size()的情况中,即删除这段代码即可

@tjumcw
Copy link
Owner

tjumcw commented May 19, 2023

不好意思上班比较忙,晚上回去我详细看一下

@tjumcw
Copy link
Owner

tjumcw commented May 26, 2023

不好意思上周忘记了,是没问题的兄弟,你看下第525行,leader为每个server维护的nextindex是不一样的,发出的rpc请求中的log是不一样长的,对于你说的宕机server会从0开始。

@wtmlon
Copy link

wtmlon commented May 30, 2023

不好意思上周忘记了,是没问题的兄弟,你看下第525行,leader为每个server维护的nextindex是不一样的,发出的rpc请求中的log是不一样长的,对于你说的宕机server会从0开始。

但是你在337行,每个新leader出现后,会把所有nextIndex设置为最新idx,这样在下一个appendEntry就会出现贴主说的问题。
按照原论文的实现,appendEntry应该是每次单步的情形从后向前试错的,只有在找到第一个idx和term都相同的节点才会进行append操作,所以这种一开始log.size()==0的情况我觉得好像得特化处理。

@tjumcw
Copy link
Owner

tjumcw commented May 30, 2023

是这样的,后续论文里我记得给出了优化的方案,是快速回滚的一种方法,MIT的资料里应该也有这部分。所以我是按照那个逻辑来,具体的记不太清楚了,周末我再看一下

@tjumcw tjumcw added the question Further information is requested label Jun 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants