学习笔记-zookeeper

Zookeeper是一个分布式协调服务。

https://km.sankuai.com/page/28437097

去中心化:我们都是相等的
中心化:Zookeeper 都是中心化的,围绕 leader

Zookeeper 如何解决分布式一致性问题
ZAB协议,底层两阶段提交协议

选举算法:
Paxos 算法应该可以说是 ZooKeeper 的灵魂了。但是,ZooKeeper 并没有完全采用 Paxos算法 ,而是使用 ZAB 协议作为其保证数据一致性的核心算法。另外,在ZooKeeper的官方文档中也指出,ZAB协议并不像 Paxos 算法那样,是一种通用的分布式一致性算法,它是一种特别为Zookeeper设计的崩溃可恢复的原子消息广播算法。
Zookeeper 的核心是原子广播,这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式,它们分别是恢复模式(选主)和广播模式(同步)。当服务启动或者在领导者崩溃后,Zab就进入了恢复模式,当领导者被选举出来,且大多数Server完成了和 leader的状态同步以后,恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。
为了保证事务的顺序一致性,zookeeper采用了递增的事务id号(zxid)来标识事务。所有的提议(proposal)都在被提出的时候加上了zxid。实现中zxid是一个64位的数字,它高32位是epoch用来标识leader关系是否改变,每次一个leader被选出来,它都会有一个新的epoch,标识当前属于那个leader的统治时期。低32位用于递增计数。

恢复模式:选举出新的 Leader
广播模式:解决每个节点数据同步问题

当我们 zk 中发出一个事务请求的时候,产生一个全局 zxid
2pc两阶段提交协议
预提交 =》等待回复 =》过半的回复 =》提交

ZK 选举底层实现原理:

发起投票的时候每个 Server 端都会产生(myid, zxid)选举,zxid 取决于每个节点最后一次做事务写的请求保存的 id;默认的情况下 zxid 为 0.

接受自己投票实现 pk:

  1. 先检查 zxid,谁最大,谁就是 leader;
  2. 如果 zxid 都是一样的情况下的时候,myid 谁最大就选谁。
  3. 如果过半机制已经选举出了 leader,之后启动的节点就不会加入选举

(1, 100), (2,100), (3,100) 为什么会选出了 2 为 leader
zxid 相等,取决于优先启动顺序比较 myid

(1,103), (2,102), (3,101) 为什么会选出了 1 为 leader
优先比较 zxid, 1 > 2

myid 一个配置,一个节点的标识

三种节点:

1.Leader 类型 领导类型,负责写的请求和各个节点同步
2.Follwer 类型 跟随者,负责读的请求和投票决议
3.ObServer 类型 观察者,和 Follower 大部分时候一样,唯一不同就是不能参与选举和投票。目的是提高客户端读的请求效率。

脑裂

在集群的情况下,一般只会选举一个 master 节点,其他都是为从节点,那么如果发生了网络抖动或者部分节点互相无法通讯,那么就会导致部分节点重新选举,这样就会存在多个 master 节点。

有了过半机制,对于一个Zookeeper集群,要么没有Leader,要没只有1个Leader,这样就避免了脑裂问题。

CAP概念

1.C: Consistency 在分布式系统中的所有数据备份,在同一时刻是否同样的值。等同于所有节点访问同一份最新的数据副本
2.A: Availability,在集群中一部分节点故障后,集群整体是否还能响应客户端的读写请求
3.P: Partition tolerance 在分布式系统中网络分区存在脑裂问题后,部分 server 与集群其他节点失去联系,无法组成一个群体
当你一个数据项只在一个节点中保存,那么分区出现后,和这个节点不连通的部分就访问不到这个数据了。这时分区就是无法容忍的。

  • CA without P
    如果不要求P(不允许分区),则C(强一致性)和A(可用性)是可以保证的。但其实分区不是你想不想的问题,而是始终会存在,因此CA的系统更多的是允许分区后各子系统依然保持CA。
  • CP without A
    如果不要求A(可用),相当于每个请求都需要在Server之间强一致,而P(分区)会导致同步时间无限延长,如此CP也是可以保证的。很多传统的数据库分布式事务都属于这种模式。
  • AP wihtout C
    要高可用并允许分区,则需放弃一致性。一旦分区发生,节点之间可能会失去联系,为了高可用,每个节点只能用本地数据提供服务,而这样会导致全局数据的不一致性。现在众多的NoSQL都属于此类。

ZooKeeper与其他组件的关系

ZooKeeper和Storm Nimbus HA的配合关系:

Storm Nimbus利用ZooKeeper来选举主备。
ZooKeeper提供了以下两种能力:
分布式锁服务:
多个Nimbus进程都会尝试去Zookeeper创建对应的节点,该节点只能被一个Nimbus进程创建成功,创建成功的Nimbus进程成为主Nimbus。
时间侦听机制–watcher:
备Nimbus侦听对应的ZooKeeper节点。主Nimbus进程宕掉之后,该节点会被删除,那么备Nimbus就可以接受到相应的消息。

ZooKeeper和HDFS的配合关系:

ZKFC(ZooKeeper Failover Controller)作为一个ZooKeeper集群的客户端,用来监控NameNode的状态信息。ZKFC进程仅在部署了NameNode的节点中存在。HDFS NameNode的Active和Standby节点均部署有ZKFC进程:

HDFS NameNode的ZKFC连接到Zookeeper,把主机名等信息保存到ZooKeeper中,即“/hadoop-ha”下的znode目录里。先创建znode目录的NmaeNode节点为主节点,另一个为备节点。HDFS NameNode Standby通过ZooKeeper定时读取NmaeNode信息。
当主节点进程异常结束时,HDFS NameNode Standby通过ZooKeeper感知“/hadoop-ha”目录下发生了变化,NmaeNode会进行主备切换。

ZooKeeper和YARN的配合关系:

在系统启动时,ResourceManager会尝试把选举信息写入Zookeeper,第一个成功写入Zookeeper的ResourceManager被选举为Active ResourceManager,另一个为Standby ResourceManager。Standby ResourceManager定时去ZooKeeper监控Active ResourceManager选举信息。

Active ResourceManager还会在ZooKeeper中创建Statestore目录,存储Application相关信息。当Active ResourceManager产生故障时,Standby ResourceManager会从Statestore目录获取Application相关信息,恢复数据并升为Active。

ZooKeeper和HBase的配合关系:

HRegionServer把自己以Ephemeral方式注册到Zookeeper中。其中ZooKeeper存储HBase的如下信息:HBase元数据、HMaster地址。

HMaster通过ZooKeeper随时感知各个HRegionServer的健康状况,以便进行控制管理。

HBase也可以部署多对HMaster,类似HDFS NameNode,当HMaster主节点出现故障时,HMaster备用节点会通过ZooKeeper获取主HMaster存储的整个HBase集群状态信息。即通过ZooKeeper实现避免HBase单点故障问题。

展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 技术黑板 设计师: CSDN官方博客
应支付0元
点击重新获取
扫码支付

支付成功即可阅读