角色、人气及角色转变

角色、人气及角色转变
Leader选举我要选举当follower没有接收到leader的心跳则认为leader挂了。此时先使其本地term加1.然后完成下面步骤此时若接收到其他candidate 的投票请求就投票给这个candidate由follower转变为candidate若之前未投票就投自己一票向其他节点发出投票请求然后等待响应。我要投票follower 在接收到投票请求后根据以下情况判断是否投票发来投票请求的candidate的term不能小于我的term在我当前term内我的选票还没有投出去若接收到多个candidate的请求采取first-come-first-served方式投票等待响应当一个candidate 发出投票后会等待其他节点的响应结果这个结果有三种情况收到过半选票成为新的leader,然后通知其他节点。接收到别的candidate 发来的新leader通知比较新leader的term 不比自己的term小将自己变未follower经过一段时间后没有收到过半选票也没有收到新leader通知则重新开始选举。选举时机很多时候当Leader真的挂了Follower几乎同时感知到然后几乎同时变为candidate发起选举。此时会出现较多candidate 票数相同情况就无法选举出Leader。为了防止这种情况Raft算法采用randomized election timeouts 策略解决这个问题。其会为这些Follower随机分配一个选举发起时间 election timeout,这个timeout 在150-300ms范围内。只有到达election timeout 时间的Follower 才能转变为candidate否则等待。那么 election timeout 较小的Follower 则会转变为candidate 然后发起选举一般情况下先获取到过半选票的节点成为新的leader。数据同步在Leader 选举出来的情况下通过日志复制实现集群中各节点数据的同步。状态机Raft算法一致性是基于日志复制状态机来实现的。状态机最大的特征是不同Server中的状态机若当前状态相同然后接收了相同的输入那么输出必然相同。处理流程当leader接收到client的写请求后会经历以下流程leader会将数据与term封装为一个box并随着下一次心跳发送给所有followers征求大家对该box的意见。同时将本地数据封装为日志。follower 接收到来自leader的box后 先比较该box的term比自己的小就接受该box并向leader回复同意。同时将该box中的数据封装为日志。当leader接收到过半同意响应后将日志commit到本地的状态机状态机输出一个结果同时日志状态变为了committed同时leader会通知所有follower 将日志commit到本地的状态机日志状态变为了committed在commit 通知发出同时leader 也会向client发出成功处理的响应。AP支持为保证可用性。各个节点中的日志可以不完全相同但leader会不断给follower发送box以使各个节点的log达到最终相同。即Raft算法不是强一致性而是最终一致性。脑裂在多机房部署中由于网络问题很容易形成多个分区而多分区很容易产生脑裂从而导致数据不一致。以三机房部署为例可以分为五种情况不确定B感知不到Leader所以会发起选举但是C能感知到Leader但是由于其接收到了更大term的投票请求所以C也放弃了A中的Leader参与了新的选举。若leader出现在B机房A是感知不到新Leader的诞生其不会自动下课就会形成脑裂。由于A中的Leader处理的写操作无法获取到过半响应所以无法完成写操作。但B中的Leader的写操作处理可以获取到过半响应所以能完成写操作故A与B、C中出现脑裂且形成了数据不一致。若新Leader出现在C机房A中的Leader会自动下课所以不会形成脑裂。形成脑裂这种情况一定会形成脑裂无脑裂A、C正常服务B无法选举出新的Leader。没有形成脑裂。无脑裂ABC均对外服务无脑裂。无脑裂A无法处理写请求但可以对外服务。BC失去了Leader都会发起选举但是都无法获取过半支持都无法选出新Leader。Leader宕机处理请求到达前Leader挂了client发送写请求到Leader之前Leader挂了因为请求没到达集群所以对集群数据的一致性没影响。Leader挂了之后会选举产生新的Leader。由于Stale Leader 未向client发送响应所以client会重新发送写请求。未开始同步数据前Leader挂了client发送写请求给Leader请求到达Leader后Leader还没开始向Followers发送数据就挂了这时选举产生新Leader。Stale Leader重启作为Follower重新加入集群并同步新Leader 中的数据以保证数据一致性。由于stale Leader 未发送响应所以client会重新发送写请求。同步完部分后Leader挂了