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

缺少选举流程 #7

Open
txm119161336 opened this issue Jul 20, 2017 · 5 comments
Open

缺少选举流程 #7

txm119161336 opened this issue Jul 20, 2017 · 5 comments

Comments

@txm119161336
Copy link

Hi,
按目前的流程,客户端只能连接同一个机器(Proposer),如果连接另一个proposer,则instanceId会乱,是否觉得需要添加leader选举流程?

@luohaha
Copy link
Owner

luohaha commented Jul 20, 2017

不会乱啊,每一个instance内只能确认一个提交。不过后续可以加上选举,可以优化性能,避免活锁等情况。

@txm119161336
Copy link
Author

如果说,一个客户端连接是serverA发送命令x,另一个客户端连接serverB发送命令y, 此时serverA作为proposer,是否生成的instanceId =1 的情况下,serverB也会同样生成instanceId=1,这个时候,你以哪一个为准呢?一个必然会覆盖另一个,所以必须要选择主的情况下才可以,避免这个Instance创建

@luohaha
Copy link
Owner

luohaha commented Jul 20, 2017

@txm119161336 其实不会的,建议你仔细看下paxos原理和实现相关的论文。因为在每个instance内,只有一个client的提案能够成功,而另外一个client 的提案在这个instance内只能同意已经被多数派同意的提案。所以另外一个client只能将自己的提案留到下一个instance,去提交。

@txm119161336
Copy link
Author

@luohaha,
非常感谢你的回复,
我看错了,有一个while的条件在外面,我开始没看到,我以为你缺少了propose的重试的部分,不过即便这样,性能也是相当低的,是二阶段的通信,你说优化过了

实现了multi-paxos中连续同一leader提交时,优化协议流程,将prepare和accept流程,优化到只有accept流程,目前还是先需要propose,而后再进行acceptor
好像情况不是这样的,还是需要经过一轮的prepare的

@luohaha
Copy link
Owner

luohaha commented Jul 20, 2017

@txm119161336 对,只有在同一个proposer连续提交的时候,才能做优化,否则就会退化到两阶段。所以leader选举是需要的,不过是为了性能考虑(两阶段优化到一阶段),而不是为了正确性考虑。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants