Closed Begro closed 5 years ago
看了您关于master选举与续约的内容，发现master的有效期是依靠机器本地时间来实现的，在分布式系统里使用机器时间应该不是一个很好地选择。如果出现时钟的回退或者跳跃，会导致master的状态不确定。比如slave节点时间跳跃，会导致slave认为master过期，slave会在master任期内发起beMaster请求。 我对这个master续约与选举有一个新的想法，如果我们不利用时间判断过期，改成利用instanceId判断过期。原来master任期为timeout时间，改为n个instanceId内有效。因为paxos算法保证了所有节点的instanceId的有序和一致，所以不会出现错乱的问题。并且，如果某个节点落后，节点处于learing状态时，本身不适合成为新的master。在这种机制下，他的instanceId会小于其他节点，至少小于master节点，则他不会认为master过期，也就不会尝试beMaster。 并且依旧可以利用instanceId作为master的续约的间隔，保证在master任期内，master节点会再次发起beMaster，对master进行续约。 并且为了防止paxos集群空跑，导致instanceId永远不增长的情况。可以启动一个定时propose任务，保证paxos集群的最小propose速率，保证在可接受时间范围内，master进行续约或重新选主。 例如，原master任期时间为10S，续约周期为2.5~3秒之间随机。我们可以启动定时propose任务，50MS一次，则可转换为master有效期200个定时任务的instanceId增长，续约周期可以为50到60个定时任务的instanceId增长。
看了您关于master选举与续约的内容，发现master的有效期是依靠机器本地时间来实现的，在分布式系统里使用机器时间应该不是一个很好地选择。如果出现时钟的回退或者跳跃，会导致master的状态不确定。比如slave节点时间跳跃，会导致slave认为master过期，slave会在master任期内发起beMaster请求。 我对这个master续约与选举有一个新的想法，如果我们不利用时间判断过期，改成利用instanceId判断过期。原来master任期为timeout时间，改为n个instanceId内有效。因为paxos算法保证了所有节点的instanceId的有序和一致，所以不会出现错乱的问题。并且，如果某个节点落后，节点处于learing状态时，本身不适合成为新的master。在这种机制下，他的instanceId会小于其他节点，至少小于master节点，则他不会认为master过期，也就不会尝试beMaster。 并且依旧可以利用instanceId作为master的续约的间隔，保证在master任期内，master节点会再次发起beMaster，对master进行续约。 并且为了防止paxos集群空跑，导致instanceId永远不增长的情况。可以启动一个定时propose任务，保证paxos集群的最小propose速率，保证在可接受时间范围内，master进行续约或重新选主。 例如，原master任期时间为10S，续约周期为2.5~3秒之间随机。我们可以启动定时propose任务，50MS一次，则可转换为master有效期200个定时任务的instanceId增长，续约周期可以为50到60个定时任务的instanceId增长。