33zookeeper

2020-01-06 本文已影响0人文茶君

其实在我们学习hadoop时候就已经学习了zookeeper，但是对于zk至少在我的印象中就是ha和管理节点，节点通信之类，继续深入学习一下。
zookeeper主要做协调性工作。
所有大数据集群存储（在我的认知中或者说基本上）：横向做沙丁(SHARDS)切片,纵向做高可用（ha）。
zookeeper主从架构模型。其他架构模型还有无主架构模型（cap原则：CAP原则又称CAP定理，指的是在一个分布式系统中，Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性)，三者不可兼得）。
在无主架构模型的发展中，主从架构模型产生。

为什么只要一个主？多主又会演变为无主模式。所以一般是单主多从结构。
一般从节点只读，而主节点可以读和写。
serverid（在集群中是myid），可以理解为编号。选举的其中一个要素，一旦发现主宕机，编号最大的当主（前面提过）。刚开始启动时（同时启动），也会服务器编号最大当选主。挨个启动，不一定最大当主
主机选择也要受zxid（事务编号id）影响，其优先级大于serverid。

1角色模型

集群状态（可用/不可用）
主从分工

2攘其外：
统一视图：

会话session
数据模型Znode
目录结构
节点类型

事件监听Watcher

3原理：
原子消息广播协议ZAB

paxos
journalnode
sentinel
zookeeper --> ZAB
zxid ,myid：
ZXID:epoch+ID

广播模式原理
恢复模式原理：无主模型：zab： zxid ,myid

4应用场景

统一命名
配置管理
集群管理

角色模型
1集群状态

选举模式安其内
广播模式壤其外

2.Server状态

LOOKING：当前Server不知道leader是谁，正在搜寻
LEADING：当前Server即为选举出来的leader
FOLLOWING：leader已经选举出来，当前Server与之同步

3.主从分工

领导者（leader）
负责进行投票的发起和决议，更新系统状态
学习者（learner）
包括跟随者（follower）和观察者（observer），follower用于接受客户端请求并向客户端返回结果，在选主过程中参与投票
Observer
可以接受客户端连接，将写请求转发给 leader，但observer不参加投票过程，只同步leader 的状态，observer的目的是为了扩展系统，提高读取速度
客户端（client）
请求发起方

数据模型Znode