Youtube视频 Raft lecture (Raft user study)

地址：https://www.youtube.com/watch?v=YbZ3zDzDnrw

Joint Consensus

多边（联合）共识

The solution is to use two phases to change the configuration. Raft switches first to an intermediate phase called joint consensus. During this phase, the cluster consists of all of the servers in both the new and the old configuration(so the union of those configurations). But decisions such as elections and commitment require a separate majority separate agreement from both the old configuration and the new configuration.

解决方案是使用两个阶段来更改配置。Raft首先切换到称为多边共识的中间阶段。在此阶段，群集由新配置和旧配置中的所有服务器组成。但是如选举和提交的决策，需要在新旧两个配置状态下分别达成一致。

Let me show you how this works. So we start off in an existing configuration, i will call C_old on the slide. And the way a configuration change is initiated that a client makes a request of the leader just like it would for any other state machine operation. When the server receives that request then the leader adds an entry to its log describing this joint configuration, which i will call C_old+new, that’s just a log entry like any other log entry. The server puts it in its log and then the leader propagates it out to the other servers in the cluster using AppendEntries RPC just like any other log entry. The only thing different about the configuration changes is that they take effect immediately, so soon as server places a new configuration into its log. It begins living by that configuration entry. It doesn’t wait for the configuration entry but for the log entry to become committed before applying it like it would for normal log entries. So back to our timeline here, leader places the new configuration entry in its log and then as far as that leader is concerned that’s the configuration in effect, so that leader makes all of its decisions according the old plus new configuration that means that for example for any log entry to be committed it must be logged majority of the machines in the old cluster and a majority of machines in the new configuration. Now, for a while until that entry becomes replicated or reached a point of being committed, it’s possible that decisions might be made either with C_old or C_old+new.¹ For example if the leader crashes shortly after logging the new configuration entry, it’s possible that some other machine is still operating under the old, could be elected and take over the cluster but at some point this new configuration entry will become committed C_old+new. Once that happens now it’s not possible for any machine to make a decision based purely on C_old.

我来告诉你这是怎么工作的。所以我们从现有的配置开始，我称之为幻灯片上的C_old。配置更改的方式是客户端向领导者发出请求，就像其他状态机操作一样。当服务器收到该请求时，领导者在其日志中添加一个条目来描述这个联合配置，我将称之为C_old+new，就像任何其他日志条目一样只是一个日志条目。服务器将其放入其日志中，然后领导者使用AppendEntries RPC将其传播到集群中的其他服务器，就像其他日志条目一样。配置更改的唯一不同之处在于，只要服务器将新配置放入其日志中，它们就会立即生效。一旦服务器将新配置记录到日志中，那么它就立刻生效，它不会等待配置条目在应用之前提交（就像普通日志条目一样）。所以回到时间轴²，领导者将新的配置条目放到其日志中，然后就这个领导者而言，C_old+new就是实际上的配置，以便领导者根据旧的加上新的配置做出所有决定，这意味着对于要提交的任何日志条目，要求该条目分别在新旧配置服务器下同时都成为大多数。现在，在该条目被复制或到达提交点之前，可能会使用C_old或C_old+new作出决定。例如，如果领导者在记录新配置记录后就发生崩溃，有可能某些其他旧配置的机器仍然处于工作状态，被选举成领导者管理集群。但在某个时间点，C_old+new会变为已提交的状态³，在此种状态下，任何机器就无法只根据C_old来做出决策。

---

1. 52:28 ↩︎

2. ↩︎

3. ↩︎