33zookeeper

其实在我们学习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

• 目录结构 节点间具有父子关系
  层次的，目录型结构，便于管理逻辑关系
  节点znode而非文件file
• znode信息
  包含最大1MB的数据信息(主要做协调作用)
  记录了Zxid等元数据信息
• 节点类型

搭建集群（在前面已经搭过了）

[zookeeper-3.4.6]vi + /etc/profile修改配置文件

zookeeper启动集群启动不同之处在于要告知启动哪些机器，在这里修改zoo.cfg

修改配置

分发

分发给node08（此处省略）

追加myid。1,2，3追加在node6，7，8（在上文讲过）
接下来
source /etc/profi*
就可以启动了

zk：主从模式

Znode有两种类型，短暂的（ephemeral）和持久的（persistent）
Znode支持序列SEQUENTIAL：leader

• 短暂znode的客户端会话结束时，zookeeper会将该短暂znode删除，短暂znode不可以有子节点
• 持久znode不依赖于客户端会话，只有当客户端明确要删除该持久znode时才会被删除

Znode的类型在创建时确定并且之后不能再修改
Znode有四种形式的目录节点

• PERSISTENT
• EPHEMERAL
• PERSISTENT_SEQUENTIAL
• EPHEMERAL_SEQUENTIAL

Zookeeper全解析——Paxos作为灵魂