ui设计网站模板,wordpress怎么做好看的图片页面,微商城app下载,php网站开发费用本文转发自技术世界#xff0c;原文链接 http://www.jasongj.com/zookeeper/fastleaderelection/ 一、Zookeeper是什么
Zookeeper是一个分布式协调服务#xff0c;可用于服务发现#xff0c;分布式锁#xff0c;分布式领导选举#xff0c;配置管理等。
这一切的基础原文链接 http://www.jasongj.com/zookeeper/fastleaderelection/ 一、Zookeeper是什么
Zookeeper是一个分布式协调服务可用于服务发现分布式锁分布式领导选举配置管理等。
这一切的基础都是Zookeeper提供了一个类似于Linux文件系统的树形结构可认为是轻量级的内存文件系统但只适合存少量信息完全不适合存储大量文件或者大文件同时提供了对于每个节点的监控与通知机制。
既然是一个文件系统就不得不提Zookeeper是如何保证数据的一致性的。本文将介绍Zookeeper如何保证数据一致性如何进行领导选举以及数据监控/通知机制的语义保证。
二、Zookeeper架构
2.1 角色 Zookeeper集群是一个基于主从复制的高可用集群每个服务器承担如下三种角色中的一种
Leader 一个Zookeeper集群同一时间只会有一个实际工作的Leader它会发起并维护与各Follwer及Observer间的心跳。所有的写操作必须要通过Leader完成再由Leader将写操作广播给其它服务器。Follower 一个Zookeeper集群可能同时存在多个Follower它会响应Leader的心跳。Follower可直接处理并返回客户端的读请求同时会将写请求转发给Leader处理并且负责在Leader处理写请求时对请求进行投票。Observer 角色与Follower类似但是无投票权。 2.2 原子广播ZAB 为了保证写操作的一致性与可用性Zookeeper专门设计了一种名为原子广播ZAB的支持崩溃恢复的一致性协议。基于该协议Zookeeper实现了一种主从模式的系统架构来保持集群中各个副本之间的数据一致性。
根据ZAB协议所有的写操作都必须通过Leader完成Leader写入本地日志后再复制到所有的Follower节点。
一旦Leader节点无法工作ZAB协议能够自动从Follower节点中重新选出一个合适的替代者即新的Leader该过程即为领导选举。该领导选举过程是ZAB协议中最为重要和复杂的过程。
2.3 写操作
2.3.1 写Leader 通过Leader进行写操作流程如下图所示 由上图可见通过Leader进行写操作主要分为五步
客户端向Leader发起写请求Leader将写请求以Proposal的形式发给所有Follower并等待ACKFollower收到Leader的Proposal后返回ACKLeader得到过半数的ACKLeader对自己默认有一个ACK后向所有的Follower和Observer发送CommmitLeader将处理结果返回给客户端
这里要注意
Leader并不需要得到Observer的ACK即Observer无投票权Leader不需要得到所有Follower的ACK只要收到过半的ACK即可同时Leader本身对自己有一个ACK。上图中有4个Follower只需其中两个返回ACK即可因为(21) / (41) 1/2Observer虽然无投票权但仍须同步Leader的数据从而在处理读请求时可以返回尽可能新的数据
2.3.2 写Follower/Observer 通过Follower/Observer进行写操作流程如下图所示
从上图可见
Follower/Observer均可接受写请求但不能直接处理而需要将写请求转发给Leader处理除了多了一步请求转发其它流程与直接写Leader无任何区别
2.4 读操作
Leader/Follower/Observer都可直接处理读请求从本地内存中读取数据并返回给客户端即可。 由于处理读请求不需要服务器之间的交互Follower/Observer越多整体可处理的读请求量越大也即读性能越好。
三、FastLeaderElection原理
3.1 术语介绍
myid
每个Zookeeper服务器都需要在数据文件夹下创建一个名为myid的文件该文件包含整个Zookeeper集群唯一的ID整数。例如某Zookeeper集群包含三台服务器hostname分别为zoo1、zoo2和zoo3其myid分别为1、2和3则在配置文件中其ID与hostname必须一一对应如下所示。在该配置文件中server.后面的数据即为myid
server.1zoo1:2888:3888
server.2zoo2:2888:3888
server.3zoo3:2888:3888zxid
类似于RDBMS中的事务ID用于标识一次更新操作的Proposal ID。为了保证顺序性该zkid必须单调递增。因此Zookeeper使用一个64位的数来表示高32位是Leader的epoch从1开始每次选出新的Leaderepoch加一。低32位为该epoch内的序号每次epoch变化都将低32位的序号重置。这样保证了zkid的全局递增性。
3.2 支持的领导选举算法 可通过electionAlg配置项设置Zookeeper用于领导选举的算法。
到3.4.10版本为止可选项有
0 基于UDP的LeaderElection1 基于UDP的FastLeaderElection2 基于UDP和认证的FastLeaderElection3 基于TCP的FastLeaderElection
在3.4.10版本中默认值为3也即基于TCP的FastLeaderElection。另外三种算法已经被弃用并且有计划在之后的版本中将它们彻底删除而不再支持。
3.3 FastLeaderElection FastLeaderElection选举算法是标准的Fast Paxos算法实现可解决LeaderElection选举算法收敛速度慢的问题。
3.3.1 服务器状态
LOOKING 不确定Leader状态。该状态下的服务器认为当前集群中没有Leader会发起Leader选举FOLLOWING 跟随者状态。表明当前服务器角色是Follower并且它知道Leader是谁LEADING 领导者状态。表明当前服务器角色是Leader它会维护与Follower间的心跳OBSERVING 观察者状态。表明当前服务器角色是Observer与Folower唯一的不同在于不参与选举也不参与集群写操作时的投票
3.3.2 选票数据结构 每个服务器在进行领导选举时会发送如下关键信息
logicClock 每个服务器会维护一个自增的整数名为logicClock它表示这是该服务器发起的第多少轮投票state 当前服务器的状态self_id 当前服务器的myidself_zxid 当前服务器上所保存的数据的最大zxidvote_id 被推举的服务器的myidvote_zxid 被推举的服务器上所保存的数据的最大zxid
3.3.3 投票流程
自增选举轮次 Zookeeper规定所有有效的投票都必须在同一轮次中。每个服务器在开始新一轮投票时会先对自己维护的logicClock进行自增操作。
初始化选票 每个服务器在广播自己的选票前会将自己的投票箱清空。该投票箱记录了所收到的选票。例服务器2投票给服务器3服务器3投票给服务器1则服务器1的投票箱为(2, 3), (3, 1), (1, 1)。票箱中只会记录每一投票者的最后一票如投票者更新自己的选票则其它服务器收到该新选票后会在自己票箱中更新该服务器的选票。
发送初始化选票 每个服务器最开始都是通过广播把票投给自己。
接收外部投票 服务器会尝试从其它服务器获取投票并记入自己的投票箱内。如果无法获取任何外部投票则会确认自己是否与集群中其它服务器保持着有效连接。如果是则再次发送自己的投票如果否则马上与之建立连接。
判断选举轮次 收到外部投票后首先会根据投票信息中所包含的logicClock来进行不同处理
外部投票的logicClock大于自己的logicClock。说明该服务器的选举轮次落后于其它服务器的选举轮次立即清空自己的投票箱并将自己的logicClock更新为收到的logicClock然后再对比自己之前的投票与收到的投票以确定是否需要变更自己的投票最终再次将自己的投票广播出去。外部投票的logicClock小于自己的logicClock。当前服务器直接忽略该投票继续处理下一个投票。外部投票的logickClock与自己的相等。当时进行选票PK。
选票PK 选票PK是基于(self_id, self_zxid)与(vote_id, vote_zxid)的对比 外部投票的logicClock大于自己的logicClock则将自己的logicClock及自己的选票的logicClock变更为收到的logicClock 若logicClock一致则对比二者的vote_zxid若外部投票的vote_zxid比较大则将自己的票中的vote_zxid与vote_myid更新为收到的票中的vote_zxid与vote_myid并广播出去另外将收到的票及自己更新后的票放入自己的票箱。如果票箱内已存在(self_myid, self_zxid)相同的选票则直接覆盖 若二者vote_zxid一致则比较二者的vote_myid若外部投票的vote_myid比较大则将自己的票中的vote_myid更新为收到的票中的vote_myid并广播出去另外将收到的票及自己更新后的票放入自己的票箱
统计选票 如果已经确定有过半服务器认可了自己的投票可能是更新后的投票则终止投票。否则继续接收其它服务器的投票。
更新服务器状态 投票终止后服务器开始更新自身状态。若过半的票投给了自己则将自己的服务器状态更新为LEADING否则将自己的状态更新为FOLLOWING
3.4 几种领导选举场景
3.4.1 集群启动领导选举
初始投票给自己 集群刚启动时所有服务器的logicClock都为1zxid都为0。
各服务器初始化后都投票给自己并将自己的一票存入自己的票箱如下图所示。
在上图中(1, 1, 0)第一位数代表投出该选票的服务器的logicClock第二位数代表被推荐的服务器的myid第三位代表被推荐的服务器的最大的zxid。由于该步骤中所有选票都投给自己所以第二位的myid即是自己的myid第三位的zxid即是自己的zxid。
此时各自的票箱中只有自己投给自己的一票。
更新选票 服务器收到外部投票后进行选票PK相应更新自己的选票并广播出去并将合适的选票存入自己的票箱如下图所示。 服务器1收到服务器2的选票1, 2, 0和服务器3的选票1, 3, 0后由于所有的logicClock都相等所有的zxid都相等因此根据myid判断应该将自己的选票按照服务器3的选票更新为1, 3, 0并将自己的票箱全部清空再将服务器3的选票与自己的选票存入自己的票箱接着将自己更新后的选票广播出去。此时服务器1票箱内的选票为(1, 3)(3, 3)。
同理服务器2收到服务器3的选票后也将自己的选票更新为1, 3, 0并存入票箱然后广播。此时服务器2票箱内的选票为(2, 3)(3, ,3)。
服务器3根据上述规则无须更新选票自身的票箱内选票仍为3, 3。
服务器1与服务器2更新后的选票广播出去后由于三个服务器最新选票都相同最后三者的票箱内都包含三张投给服务器3的选票。
根据选票确定角色 根据上述选票三个服务器一致认为此时服务器3应该是Leader。因此服务器1和2都进入FOLLOWING状态而服务器3进入LEADING状态。之后Leader发起并维护与Follower间的心跳。 3.4.2 Follower重启
Follower重启投票给自己 Follower重启或者发生网络分区后找不到Leader会进入LOOKING状态并发起新的一轮投票。 发现已有Leader后成为Follower 服务器3收到服务器1的投票后将自己的状态LEADING以及选票返回给服务器1。服务器2收到服务器1的投票后将自己的状态FOLLOWING及选票返回给服务器1。此时服务器1知道服务器3是Leader并且通过服务器2与服务器3的选票可以确定服务器3确实得到了超过半数的选票。因此服务器1进入FOLLOWING状态。 3.4.3 Leader重启
Follower发起新投票 Leader服务器3宕机后Follower服务器1和2发现Leader不工作了因此进入LOOKING状态并发起新的一轮投票并且都将票投给自己。 广播更新选票 服务器1和2根据外部投票确定是否要更新自身的选票。这里有两种情况
服务器1和2的zxid相同。例如在服务器3宕机前服务器1与2完全与之同步。此时选票的更新主要取决于myid的大小服务器1和2的zxid不同。在旧Leader宕机之前其所主导的写操作只需过半服务器确认即可而不需所有服务器确认。换句话说服务器1和2可能一个与旧Leader同步即zxid与之相同另一个不同步即zxid比之小。此时选票的更新主要取决于谁的zxid较大
在上图中服务器1的zxid为11而服务器2的zxid为10因此服务器2将自身选票更新为3, 1, 11如下图所示。
选出新Leader 经过上一步选票更新后服务器1与服务器2均将选票投给服务器1因此服务器2成为Follower而服务器1成为新的Leader并维护与服务器2的心跳。 旧Leader恢复后发起选举 旧的Leader恢复后进入LOOKING状态并发起新一轮领导选举并将选票投给自己。此时服务器1会将自己的LEADING状态及选票3, 1, 11返回给服务器3而服务器2将自己的FOLLOWING状态及选票3, 1, 11返回给服务器3。如下图所示。 旧Leader成为Follower 服务器3了解到Leader为服务器1且根据选票了解到服务器1确实得到过半服务器的选票因此自己进入FOLLOWING状态。 四、一致性保证
ZAB协议保证了在Leader选举的过程中已经被Commit的数据不会丢失未被Commit的数据对客户端不可见。
4.1 Commit过的数据不丢失
Failover前状态 为更好演示Leader Failover过程本例中共使用5个Zookeeper服务器。A作为Leader共收到P1、P2、P3三条消息并且Commit了1和2且总体顺序为P1、P2、C1、P3、C2。根据顺序性原则其它Follower收到的消息的顺序肯定与之相同。其中B与A完全同步C收到P1、P2、C1D收到P1、P2E收到P1如下图所示。 这里要注意
由于A没有C3意味着收到P3的服务器的总个数不会超过一半也即包含A在内最多只有两台服务器收到P3。在这里A和B收到P3其它服务器均未收到P3由于A已写入C1、C2说明它已经Commit了P1、P2因此整个集群有超过一半的服务器即最少三个服务器收到P1、P2。在这里所有服务器都收到了P1除E外其它服务器也都收到了P2
选出新Leader 旧Leader也即A宕机后其它服务器根据上述FastLeaderElection算法选出B作为新的Leader。C、D和E成为Follower且以B为Leader后会主动将自己最大的zxid发送给BB会将Follower的zxid与自身zxid间的所有被Commit过的消息同步给Follower如下图所示。 在上图中
P1和P2都被A Commit因此B会通过同步保证P1、P2、C1与C2都存在于C、D和E中P3由于未被A Commit同时幸存的所有服务器中P3未存在于大多数据服务器中因此它不会被同步到其它Follower
通知Follower可对外服务 同步完数据后B会向D、C和E发送NEWLEADER命令并等待大多数服务器的ACK下图中D和E已返回ACK加上B自身已经占集群的大多数然后向所有服务器广播UPTODATE命令。收到该命令后的服务器即可对外提供服务。 4.2 未Commit过的消息对客户端不可见
在上例中P3未被A Commit过同时因为没有过半的服务器收到P3因此B也未Commit P3如果有过半服务器收到P3即使A未Commit P3B会主动Commit P3即C3所以它不会将P3广播出去。
具体做法是B在成为Leader后先判断自身未Commit的消息本例中即P3是否存在于大多数服务器中从而决定是否要将其Commit。然后B可得出自身所包含的被Commit过的消息中的最小zxid记为min_zxid与最大zxid记为max_zxid。C、D和E向B发送自身Commit过的最大消息zxid记为max_zxid以及未被Commit过的所有消息记为zxid_set。B根据这些信息作出如下操作
如果Follower的max_zxid与Leader的max_zxid相等说明该Follower与Leader完全同步无须同步任何数据如果Follower的max_zxid在Leader的(min_zxidmax_zxid)范围内Leader会通过TRUNC命令通知Follower将其zxid_set中大于Follower的max_zxid如果有的所有消息全部删除
上述操作保证了未被Commit过的消息不会被Commit从而对外不可见。
上述例子中Follower上并不存在未被Commit的消息。但可考虑这种情况如果将上述例子中的服务器数量从五增加到七服务器F包含P1、P2、C1、P3服务器G包含P1、P2。此时服务器F、A和B都包含P3但是因为票数未过半因此B作为Leader不会Commit P3而会通过TRUNC命令通知F删除P3。如下图所示。 五、总结
由于使用主从复制模式所有的写操作都要由Leader主导完成而读操作可通过任意节点完成因此Zookeeper读性能远好于写性能更适合读多写少的场景虽然使用主从复制模式同一时间只有一个Leader但是Failover机制保证了集群不存在单点失败SPOF的问题ZAB协议保证了Failover过程中的数据一致性服务器收到数据后先写本地文件再进行处理保证了数据的持久性
