JDY一面挂

写了一个Raft的玩具,然后遇到了一个做分布式基架的,直接被问到G了。

问:Follower处于少数的Network Partition中会一直让TermID递增,这样有什么问题,能怎么解决?

我的回答:这样对Raft集群的工作来说是没事的,只是会导致出现很多的空的TermID。后面得知有一种预选举的优化。

问:如果旧Leader处于一个Network Partition中,然后出现了一个新的Leader,此时如果读旧的Leader的话,会导致脑裂吗?

我的回答:不会,因为在我的实现里面Read也是要添加到日志中的,旧的Leader无法做到这一点,所以会一直超时。面试官对这个回答不满意,因为Read走日志的话会导致性能问题。

后面查资料,了解到了Leader的退位机制,但是其实我的那种方案也是存在的(Read as Proposal),估计是面试官看不上这样的实现。

总之就是挂了,但是还是学到了一些关于Raft的东西。

全部评论
太强了佬raft算法我只能勉强知道个大概
1 回复 分享
发布于 03-30 16:48 上海
啥部门 怎么光问分布式
点赞 回复 分享
发布于 03-24 14:39 重庆
已老实
点赞 回复 分享
发布于 03-24 14:46 湖南
只有腾讯认真问过这个项目
点赞 回复 分享
发布于 03-24 15:03 广东
回头就把他聪简历里删了
点赞 回复 分享
发布于 03-24 18:17 上海
第一个问题原论文里讨论过,用preVote预先进行一次投票,如果能达到大多数才正式发起投票
点赞 回复 分享
发布于 03-24 20:58 四川
read as proposal也是可以的,可以用read index lease read这类方案提升性能
点赞 回复 分享
发布于 03-24 21:12 福建
接好运
点赞 回复 分享
发布于 03-25 14:46 山东

相关推荐

评论
3
16
分享

创作者周榜

更多
牛客网
牛客企业服务