6 Matching Annotations
- Jul 2022
-
mit-public-courses-cn-translatio.gitbook.io mit-public-courses-cn-translatio.gitbook.io
-
假设S2和S3之间的差距足够大，先超时的那个节点（也就是S2）能够在另一个节点（也就是S3）超时之前，发起一轮选举，并获得过半的选票，那么那个节点（也就是S2）就可以成为新的Leader。
- 如果S2和S3的时间间隔很小，S2在收到超过半数选票成为Leader之前，S3也发出RequestVote请求并之后也收到超半数选票呢？比如说S2的网络延迟比S3大，或者S2服务器性能比S3性能低非常多等等
- 随机数算法是什么样的呢？如果是简单的随机算法，那么可能会导致两个节点随机出来的election time一样。如果节点数量更多，那么多台机器election time随机值一样的可能性更大
-
一个导致选举失败的更有趣的场景是，所有环节都在正常工作，没有故障，没有丢包，但是候选人们几乎是同时参加竞选，它们分割了选票（Split Vote）。假设我们有一个3节点的多副本系统，3个节点的选举定时器几乎同超时，进而期触发选举。首先，每个节点都会为自己投票。之后，每个节点都会收到其他节点的RequestVote消息，因为该节点已经投票给自己了，所以它会返回反对投票。这意味着，3个节点中的每个节点都只能收到一张投票（来自于自己）。没有一个节点获得了过半投票，所以也就没有人能被选上。接下来它们的选举定时器会重新计时，因为选举定时器只会在收到了AppendEntries消息时重置，但是由于没有Leader，所有也就没有AppendEntries消息。所有的选举定时器重新开始计时，如果我们不够幸运的话，所有的定时器又会在同一时间到期，所有节点又会投票给自己，又没有人获得了过半投票，这个状态可能会一直持续下去。
当election timer timeout后： 1. candidate投票给自己 2. 如果自己是candidate状态时收到其他节点的RequestVote，则投反对票
-
- Apr 2022
-
mrcroxx.github.io mrcroxx.github.io
-
创建检查点时发生错误不会影响日志的正确性，因为恢复代码会检测并跳过不完整的检查点。
如何跳过？
-
master会在操作记录被写入前批量合并一些操作记录来减少写入和备份操作对整个系统吞吐量的影响
？？
-
文件到chunk的映射
即Chunk handle
-
一个潜在的长期解决方案是在让client在这种场景下从其他client读取数据
通过P2P的方式吗？
-