Zookeeper特性与节点数据

CAP理论

在一个分布式计算系统中，不可能同时满足以下三点：
C 一致性：每个节点读写数据时，保证各个节点上的数据是一致的。
P分区容错性：当系统中的节点故障时，系统就不再联通，系统会被划分为两个分区，而分区容错性则是保证每个分区都可以对外提供服务。
A可用性：即便是服务中的某个节点挂掉了，服务也是可用的，但是响应的内容可能不是最新的数据。
在分布式架构中，最多保证其中两项：

CP: 不要求可用性，只要求一致性，在客户端修改节点中的数据时，需要暂时阻塞客户端的其他请求，直到将数据同步到其他的节点上为止，如果不阻塞的话，客户端的请求可能会再次修改节点中的数据。在阻塞的过程中，服务是不可用的，这就是为什么不能保证可用性的原因。
AP:不要求一致性，客户端请求修改数据后，立即将响应返回，同步过程则是以异步的方式进行，如果同步失败则没办法保证数据一致性。
CA: 在分布式系统中不常用，如果不满足P分区容错性的话，会导致某一节点挂到，整个系统都挂掉，所以一般在单体系统中常用些。

Base理论

BA:基本可用，在出现故障，允许丢失部分可用性，比如在双十一购物时，为了保证系统的稳定性，可以将部分用户引导至一个降级页面中。
S: 软状态：允许有中间状态，且中间状态不会影响系统的可用性。
E: 最终一致性：允许系统中的节点可以经过一定时间达到一致性。

强一致性：系统中的某一节点发生了修改，其他节点同步完成才能对外提供服务。
弱一致性：数据修改后，可以容忍某些节点访问不到，最终一致性就是弱一致性。
顺序一致性：读取数据时读到的数据是上次修改的数据。

Zookeeper

一致性

zookeeper写是最终强一致性，只要大多数节点写成功就表示成功，但是读是顺序一致性的，在写的过程中有些节点因为网络延迟或系统原因没有写入数据，这时候客户端是读取不到最新数据的，所有只能保证顺序一致性。

数据结构

zookeeper采用层次模型，类似Linux的文件存储结构，从根目录逐渐细分，如下图所示

zookeeper的每层目录可以看作是一个命名空间，比如在注册中心服务下的app1服务中有多个副本p_1、p_2等，就行上图所示。
在zookeeper中的节点被称为znode,每个znode默认可以存储1M大小的数据

123
cZxid = 0xd
ctime = Wed Feb 22 00:37:12 GMT+08:00 2023
mZxid = 0xd
mtime = Wed Feb 22 00:37:12 GMT+08:00 2023
pZxid = 0xd
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 3
numChildren = 0

节点分类

临时节点

client断开连接或在timemout时间内没有发送消息节点则会消失。可以用于分布式锁，客户端断开连接时会将node删除，之后会触发一个事件，其他分布式服务线程监听这个事件，只要监听到了就表示拿到锁了。服务注册中心也可以这样操作。
使用 get -w可以监听一个节点，当客户端退出时可以触发以下这样的一条消息，一旦触发这个事件就立即拿到锁并写入到zookeeper中，这就是分布式锁的应用。

添加-s可以创建有序临时节点有序临时节点会再末尾添加有序后缀，如下图所示

持久节点

持久化保存，即便是宕机重启节点数据还在。
添加-s可以创建有序临时节点有序临时节点会再末尾添加有序后缀，如下图所示

container节点

添加-c参数创建容器节点，容器节点如果没有自节点则会自动被删除，zookeeper默认60秒检查一次，一般用于leader或锁场景中，不过感觉没什么用，它能做到的，临时节点也能做到。

TTL节点

过期时间一到，节点会自动消失，也没什么用，临时节点也能做到。默认未打开，需要再zoo.cfg中添加extendedTypesEnabled=true配置，然后-t 时间秒数创建TTL节点。

查看节点信息

stat 节点路径

节点项

zxid: 节点创建的事务id
ctime:节点创建时间戳
mZxid: 每次修改都会更新mZxid的值，修改前的值一定比修改后的值小，可以mZxid来判断节点是否被修改过。
pZxid：子节点列表修改的最后以此事务id，添加或修改子节点就会更新值。
mtime:节点最新以此更新发送的时间戳。
cversion: 子节点的版本号，当子节点变化时，cversion就会 + 1
dataVersion:数据版本号，每次对节点进行set操作时，dataVersion会 + 1。
ephemeralOwner:如果该节点为临时节点，EphemeralOwner值表示session id，否则为0。

监听机制

当节点发生改变时，会给监听的客户端推送消息，监听是一次性的，监听触发完就得重写再进行监听，多个客户端可以监听同一个节点，
Node: 连接
NodeCreateed：节点创建‘
nodeDeleted：节点删除
nodeDataChanged：节点数据变化
nodeDataChildrenChange:子节点列表变化
dataWatch：节点监听被移除
childWatchRemoved：子节点监听被移除

监听节点数据发生变化
get -w path
stat -w path
监听子节点发生变化
ls -w path

应用场景

分布式id

利用顺序节点的特性，可以创建全局唯一的分布式id。

数据发布与订阅

多个客户端监听同一个节点，当节点发生变化时会自动推送到客户端中。

统一集群管理

可以设置一个客户端用于监听节点变化，当服务端宕机时，节点消失，做出特殊的响应。

负载均衡

服务端注册到zookeeper中，每访问一次客户端接口，然后节点值 + 1，每次让值最小的去访问。

Zookeeper 注册中心

主要流程:

1. 首先服务提供者需要在zookeeper中注册服务的相关信息，节点类型为临时节点，客户端关闭或服务器宕机时，节点信息会被自动删除。
2. 消费者拉取服务的相关信息进行消费并对节点进行监听。
3. 当服务不可用时，服务提供者下线，自动删除zookeeper中存储的节点信息。
4. 消费者因为监听了zookeeper节点，当节点消失时，消费者会接收到，并做特殊业务处理。