zookeeper 学习，详细了解

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。

顺序一致性：客户端的更新将按顺序应用（主节点负责写）

原子性：更新要么成功要么失败

单个系统映像：无论客户端连接到哪个服务器，客户端都将看到相同的服务视图。也就是说，即使客户端故障转移到具有相同会话的其他服务器，客户端也永远不会看到系统的较旧视图

可靠性：应用更新后，此更新将一直持续到客户端覆盖更新为止。

及时性：确保系统的客户视图在特定时间范围内是最新的。

 

zookeeper 使用的是最终一致性。作为协议协议的一部分，来自客户端的所有写请求都转发到称为领导者的单个服务器。

zk的数据存在内存，用磁盘来保存日志。

角色：

leader：主节点，负责数据的写入

follower：从节点，负责数据的读取

observer：功能一就如同他的名字，只是一个观察者，对leader和follower的工作进行观察监听。
　　功能二就是动态扩展zookeeper集群，而又不影响集群的性能，接收客户端连接，执行leader更新系统状态的命令，不影响集群的性能是因为观察者节点不参与投票，即使是观察者节点宕机了，对集群的运行状态没有影响。
 

只有follower 才能选举。follower越少选举速度越快。其余的为observer即可，放大查询能力。

 

zookeeper 需要启动前在配置文件中配置好有那些节点，以及端口。例如 server.1=zoo1:2888:3888  3888 是用来节点间传递消息的。过半选举推荐机制。 server.后面的值越大越容易选举为主节点。

zookeeper目录节点分类：

临时节点 和 永久节点

临时节点：zookeeper有一个session的概念，当session断开，创建的临时节点对应消失。

永久节点：一直存在，相当于持久化。

        Persistent是临时节点、

　　 Persistent_sequential是临时有序节点。如00000、000001.....

　　 Ephemeral是永久节点、

　　 Ephemeral_sequential是永久有序节点

CreateMode.PERSISTENT_SEQUENTIAL   对应命令  create -s -e /path
CreateMode.PERSISTENT 对应命令 create -e /path
CreateMode.Ephemeral 对应命令 create /path
CreateMode.Ephemeral_sequential 对应命令 create -s /path

-s 即代表序列的意思。临时节点不能有子节点

 

简单的API

ZooKeeper的设计目标之一是提供一个非常简单的编程界面。因此，它仅支持以下操作：

• create：在树中的某个位置创建一个节点

• delete：删除节点

• 存在：测试某个位置是否存在节点

• 获取数据：从节点读取数据

• 设置数据：将数据写入节点

• 获取子节点：获取节点子节点的列表

• sync：等待数据传播

使用命令：get /目录信息

cZxid=0x200000002   创建事务ID

mZxid=0x200000004  修改事务ID

pZxid=0x200000002   当前节点最后创建事务的ID（属于自己的事务ID）

ephemeralOwner=64325234  当前节点归属的session ID

cZxid  是一个64位的数字，高32位代表leader节点id，当新的leader产生则会发生变化，低32位用来递增。

 

当A连上1，产生一个sessionId，当1挂掉了，A去连接 2 。此时，2也会认A的这个sessionId。因为zookeeper每个节点间的数据长得都是一样的，会进行同步。包括A在1上面产生的数据。

当第一个客户端创建一个目录数据得到  cZxid = 0x800000a22

第二个客户端连接并创建目录数据得到 cZxid = 0x800000a24

新客户端进行连接的时候会消耗掉一个 cZxid ，即 0x800000a23 被消耗掉了。

无论客户端连入还是删除节点等都会消耗一个事务ID

 

zookeeper选举

每个节点有自己的mid，不同的zxid。

当leader挂掉后，zxid（事务ID）最新的可以获得投票，当投票数过半可以获得选举。如果很多个zxid都相同，则mid最大的被选为leader。

当选出leader后， czxid 、mxid、pzxid 的 高32位都会在上一个leader 事务ID 的基础上+1，后续节点的操作ID会从当前leader 对应的 czxid 高32位 重新开始递增。在这个leader之前的节点信息的事务ID保持不变，除非发生更改。

ZAB协议

一、消息广播：过半通过

leader将客户端的请求记录为一个 Proposal 提议，并为每个follower 准备了一个fifo队列，队列里面放的就是  Proposal ，所以多个 Proposal 都是顺序性的。然后每个fifo 队列里的消息会广播到对应的 follower去，并对  Proposal 做出 ack 反馈。当leader 收到半数（包括自己）的 ack 后，这个  Proposal 则通过了，及时其余的follwer没有反馈。leader 开始对所有的follower 进行通知 commit 写入。

二、崩溃恢复：数据最全的做主

当leader进行通知的时候，如果leader挂了怎么办呢？

当leader挂了，follower 开始进行选举。A 、B、C 开始拿出自己的 ZXID 选举，ZID最大的那一个选举成功。如果最后发现都一样，就拿出各自的 id 选举，最大的那一台当选。

为什么ZXID最大的选举可以成功？

ZXID 和 Proposal 挂钩，最大的说明数据最全。ZXID是过半通过之后才代表成功写入的，即大家都赞同的，就是说最大的ZXID是半数以上的 follower 都有的。

 

https://baijiahao.baidu.com/s?id=1666465070459184658&wfr=spider&for=pc

 

zookeeper多节点配置

修改zoo.cnf

server.1=127.0.0.1:2888:3888

server.2=127.0.0.2:2888:3888

server.3=127.0.0.3:2888:3888

server.4=127.0.0.4:2888:3888

1. 2888  -- leader与follower 之间的通信
2. 3888 -- leader挂掉时节点间的通信。
3. 2181： 对外提供服务的端口

本机多台的话配置：

server.1=127.0.0.1:2888:3888
server.2=127.0.0.1:2889:3889
server.3=127.0.0.1:2890:3890

 

 

mq 对比

https://blog.csdn.net/liuzhixiong_521/article/details/84849184

rabbitmq 支持exchange（交换器）功能

https://www.cnblogs.com/sgh1023/p/11217017.html