zookeeper 碎片知识点

 

zookeeper有2中运行状态：

1，可用状态

2，不可用状态

 

集群面临问题：

1，leader肯定会挂
2，服务不可用
3，不可靠的集群
4，事实，zk集群及其高可用
5，快速的恢复出一个leader(官网给出数据是200ms)

 

特征/保障：

顺序一致性 - 客户端的更新将按发送顺序应用。

原子性 - 更新成功或失败。没有部分结果。

统一视图 - 无论服务器连接到哪个服务器，客户端都将看到相同的服务视图。

可靠性 - 一旦应用了更新，它将从那时起持续到客户端覆盖更新。

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

 

扩展性：

框架架构 --- 角色有三个： Leader ，  Follower ，  Observer

读写分离 --- observer放大查询能力

只有Follower --- 才能参与 Leader 选举

zoo.cfg （配置文件）
server.1=node01:2888:3888
server.2=node02:2888:3888
server.3=node03:2888:3888
server.4=node04:2888:3888:observer


3888: 选主投票用的端口
2888: Leader接受 write 请求的端口

 

 

可靠性：

快速恢复Leader (官网给出数据是200ms)

数据 可靠 可用 一致性：选举过程中，节点不对外提供服务！！！

ZK选举过程：

1, 通过3888端口造成两两通信！

2，只要任何人投票，都会触发那个准 Leader 发起自己的投票

3，推选制：先比较zxid，如果zxid相同，再比较myid

 

当启动初始化集群的时候，server1的myid为1，zxid为0 server2的myid为2，zxid同样是0，以此类推。此种情况下zxid都是为0。

先比较zxid，再比较myid


重新投票选举leader怎么保证数据不会丢失？

zk是cp的，不一定保证可用性，在选举的过程中，不能对外提供服务。但在选举的过程中，

首先选zxid（zk的事务ID ---发生过多少次操作）最大的为leader,zxid最大，表示数据是最新的，然后广播给follower，这样避免数据丢失。


致使ZooKeeper节点状态改变的每一个操作都将使节点接收到一个Zxid格式的时间戳，并且这个时间戳全局有序。也就是说，

每个对节点的改变都将产生一个唯一的Zxid。如果Zxid1的值小于Zxid2的值，那么Zxid1所对应的事件发生在Zxid2所对应的事件之前。

实际上，ZooKeeper的每个节点维护者两个Zxid值，为别为：cZxid、mZxid。

（1）cZxid： 是节点的创建时间所对应的Zxid格式时间戳。

（2）mZxid：是节点的修改时间所对应的Zxid格式时间戳。

实现中Zxid是一个64为的数字，它高32位是epoch（纪元）用来标识Leader关系是否改变，每次一个Leader被选出来，

它都会有一个新的epoch。低32位是个递增计数。（表示重新选举过Leader）

 

 

原子性：成功、失败。没有中间状态（队列+2PC）

广播：分布式多节点的。全部知道！(过半)

队列：FIFO，顺序性

zk的数据状态在内存，用磁盘保存日志