raft学习（16）

raft学习（16）

5.5 follower 和 candidate crashed了

直到现在我们都专注于leader的failures。follower和candidate crashed简单多了，他们可以用相同的方法进行处理。如果follower或者candidate crashes了，那么未来requestvote和appendentries rpcs发给他将会fail。raft通过无限重试来解决这些failures；如果crashed的server重启，那么rpc将会完全地成功。如果一个server再收到rpc但还没respond之前crashed，那么它就会重启之后再次收到相同的rpc。raft rpcs是幂等的，所以这没有任何的危险。例如，如果follower收到一个appendentries request，其中的log entreis已经包含在它的log中，那么它就会ignore掉这个新request上的entries。

5.6 timing 和 availability

我们对raft安全性的一个要求是不依赖于计时：系统不可以因为某些事件发生比较快或慢而产生不正确的结果。然而，可用性（系统回应clients的事件）必须依赖timing。例如，如果在server crashes后消息交换的时间比一般的时间更长了，candidate可能不能足够快去赢得一次election，那么就没有一个稳定的leader，raft就进行不起来了。

leader election在raft中计时是很重要的。raft需要满足以下关系才可以正常进行：
广播时间 《 选举timeout 《 server fail 的平均时间
在这里，广播时间是指server发送并接受某个rpc的时间。因此，heartbeat信息可以使得follower在timeout前发到；由于election timout是随机的，这也使得split votes不大可能。当选举timeout小于server fail时，这可以使得系统有个稳定的过程。当leader crashes之后，系统会在timeout后得到新的可用。

raft的rpc要求接收者在稳定的storage中保留inforrmation，所以广播时间大概在 0.5ms到20ms，取决于storage的技术。因此，election timeout主要可以设置在10ms到500ms。而server fails的时间通常是几个月或者更多。

6.集群成员变更

直到现在我们都假设集群的配置是fixed的。但在实际中，偶尔去改一下configuration是很必要的，例如去替代fail的server或者去改变replication的degree。虽然这个可以通过使得集群下线来完成，来更新配置文件，然后重启集群，但这就会使得在更换的时候集群不可用。此外，如果有人工的步骤，这就有可能会有 *** 作失误。为了解决这些问题，我们决定进行自动的配置更换，然后将他们囊括进raft共识算法中。

为了使得configuration更改的机制变得安全，必须保证在同一个term中没有两个leader。不幸的是，任何将servers从旧的configuration到新的configration是不安全的。不可能一次性把全部server改变完，所以cluster可能在转换过程中变成两个独立的大多数（见图10）

图10：因为不同server会在不同时间变换，所以configuration的转换是不安全的。例如，cluster从3个server变成5个，不幸的是，会有这样一个时间，同一个term中有两个不同的leader，一个是cold的一个是cnew的。

为了保证安全性，configuration的更改必须使用two-phase 方法。例如，某些系统使用first phase去使得old configuration不可用所以它就不可以处理client的请求；然后second phase启动新的configuration。在raft中集群首先转换成一个transitional configuration我们称为joint consensus；一旦joint consensus被committed，系统就会转换成new configuration。joint consenesus 由old 和 new configuration组合而成：

1.两个configuration的log entries都会被replicated给所有的servers
2.每个configuration的server都可能成为leader
3.共识（election和entry commiment）分别需要old 和 new configuration的大多数同意

join consensus允许每个servers在不同时间且不保证safety的情况下进行configuration的转换。进一步，joint consensus允许在configuration change的过程中集群继续进行client requests的服务。

cluster configurations在replicated log中利用特殊的entries来进行sotred和communicated；图11解释了这种configuration change的过程。

configuration change的时间线如上。虚线表示了被创造但未committed的entries。leader首先在它的log中创建Cold，new configuration entry然后把它提交给Cold，new（需要cold和cnew的大多数）。然后它再产生cnew entry然后把它提交给大多数的cnew。里面并没有cold和cnew可以独立做决定的时间点。

当leader收到一个需要将cold改成cnew的请求后，它将会为joint consensus（图中的cold，new）存储configuration作为一个log entry然后利用之前的机制复制entry。一旦某个server将新的configuraion entry添加到它的log中，它将在后面的所有decisions中用这个configuration（server总是使用最新的configuration，不管这个entry是否committed）。这意味着，leader需要用cold,new的规则来决定什么时候Cold,new是committed的。如果leader crashes了，新的leader可能在cold或者cold,new中选取，这取决于获胜的candidate是否收到了cold,new。在任何情况下，cnew不可能在这个时期进行单方面的决定。

一旦Cold，new被committed，cold和cnew都不能在另一方不支持的情况下做decisions，而leader completeness性质保证只有包含cold,new log entry的server可以被选取为leader。现在leader就可以安全的创造一个描述Cnew的entry然后将它分发给集群。Again，只要server看到了这个configuration它就会生效。当新的configruation在Cnew的rules上被committed，old configuration旧不相关了，然后不在new configuration的server就会shut down。正如图11所示，cold和cnew都不可以单独的做决定，这保证了安全性。

这里有三种问题去强调重配置。第一种方法是新的server可能最初没有存任何log entries。如果他们以这个状态被加到state中，他们需要一段时间来追赶上，在此期间他们可能无法进行commit新的log entry。为了避免可用性障碍，raft引进了一个额外的phase在configuration change之前，在这期间new servers会作为non-voting members（leader将log entreis复制给他们，他们不认为是大多数中的人）。一旦new server追上了cluster中的其他成员，reconfiguration可以按上述进行。

第二个问题是cluster的leader可能不在new configuration的部分。这种情况下，leader降级（变成follower）一旦它提交了cnew log entry。这意味着，会存在一段时间（正在committing cnew）当leader在管理集群但不包括它自己；它复制log entries但是不把自己当成大多数。leader 的变更发生，当cnew被commited因为这是new configuration可以独立运行的第一时间点（总是可以从cnew中旋leader）。在此之前，可能只有cold中的server能被选成leader。

第三个问题是移除（隔离）的server（不在cnew中）可以干扰集群。这些server收不到心跳，所以他们timeout然后开启新的election。他们然后send requestvote rpc用新的term，这就会使得目前的leader退化成follower。最终一个新的leader会被选取，但隔离的server会再次time out，然后这个过程会重复，导致了很差的性能。

为了避免这种情况，server在相信目前leader存在的时候他们会忽视一个requestvote rpc。**具体来说，如果一个server在听到目前leader的最短election timeout中收到一个requestvote rpc，他不会更新它的term或者投票。这并不会影响正常的election，其中每个server等待至少最短的election timout再开启新的election。然而，它将会帮助解决removed servers构成的干扰：如果一个leader可以发心跳给集群，那么它就不会被更大的term number取代！！