zookeeper-1

爱被打了一巴掌 2021-12-15 06:27 167阅读 0赞

zookeeper=文件系统+监听通知机制， 分布式协调，分布式数据一致性解决方案  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2tvYmV4emY_size_16_color_FFFFFF_t_70]

目录项如NameService称为znode(目录节点)，znode和普通目录不同的是可以存储数据，且存储在内存中  
znode分可持久化/临时（客户端会话失效被删除），是否带顺序编号（父节点会给此节点名后追加一自增数字）分为四类  
客户端和某Server建立tcp长连接，在连接上客户端发起心跳，请求响应和接收订阅的通知  
这个连接是不是会话呢？不完全是，若连接断了，客户端能在sessionTimeout连上其他Server，那么原会话仍然有效，这里不同连接在同一会话上，那么会话就需要一个全局唯一的sessionID  
常用场景：客户端订阅(监听)某个目录，目录改变，Server通知客户端

现在放到集群中考虑：  
集群各Server的数据（目录）应该一致，如果每个Server都可写（其他服务器不知道和谁同步状态，若采用写完广播的模式那么各台Server都在广播，数据各种覆盖），显然只有一台Server可写（Leader），其他服务器接收到写请求装发到Leader，写请求需要全局编号（Leader收到多服务器的写请求就知道执行的先后顺序）  
其他服务器分Observer和Follower，Follower能选举Leader，并参与“过半写成功”（多数Server写成功，认为数据写成功）

适用于多读少写  
顺序一致性（同一客户端的事务请求严格按顺序应用到 ZooKeeper 中去）  
原子性（事务请求的处理结果在各台服务器的应用情况都一致）  
单一系统映像（无论连哪个服务器，看到数据都是一致的）  
可靠性（更改请求被应用，，更改的结果就会被持久化）

（zk）集群间通过 Zab （专用）协议（Zookeeper Atomic Broadcast）来保持数据的一致性，而不是完全采用Paxos（通用）  
Zab：崩溃恢复，原子广播  
崩溃恢复：刚开始无Leader，或者Leader挂了，选新Leader，过半follower与Leader完成数据同步后（所有的机器follower和observer都会去和Leader同步，但只要follower挂的不多，就有资格进入下个模式），退出恢复模式，进入消息广播模式  
广播：这时候Leader上发生改变广播出去就好，但有新机器加入，还是得先和Leader同步

集群为什么奇数？多数（超过一半），3和4都只允许一台挂掉，不如选3（少点），zk的半数是不考虑Observer，只要半数以上节点存活，ZooKeeper 就能正常服务

tickTime（心跳间隔，作为时间的基础单位），initLimit（崩溃恢复时过半follower需在此时限内完成同步）  
syncLimit（通信的超时时间，比如L向F发心跳包，这个时间内得不到响应就超时）

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2tvYmV4emY_size_16_color_FFFFFF_t_70]: /images/20211214/34e7550f4bbd481b91dde8a5c52b93c0.png