zookeeper源码解析
2021-09-12 16:00:01 2 举报AI智能生成
zookeeper进阶篇,源码，原理
作者其他创作
大纲/内容
Dubbo：ZooKeeper作为注册中心
Kafka：分布式集群的集中式元数据存储，分布式协调和通知
元数据存储
HDFS：Master选举实现HA架构
Canal、condis：分布式集群的集中式元数据存储，Master选举实现HA架构
Master选举
Dubbo、Spring Cloud把系统拆分成很多的服务或者是子系统
ZooKeeper分布式锁
分布式协调
作用
集群中只有一台机器可以写，所有机器都可以读
所有写请求都会分配一个zk集群全局的唯一递增编号，zxid，保证各种客户端发起的写请求都是有顺序的
顺序写
任何一台zk机器收到了写请求之后都会同步给其他机器，保证数据的强一致
你连接到任何一台zk机器看到的数据都是一致的
ZAB协议，原子广播协议
1，发起一个事务proposal之前，leader会分配一个全局唯一递增的事务id，zxid，通过这个可以严格保证顺序
2，leader会为每个follower创建一个队列，里面放入要发送给follower的事务proposal，这是保证了一个同步的顺序性
3，每个follower收到一个事务proposal之后，就需要立即写入本地磁盘日志中，写入成功之后就可以保证数据不会丢失了
4，然后返回一个ack给leader，然后过半follower都返回了ack，leader推送commit消息给全部follower
5，leader自己也会进行commit操作
2PC （两阶段提交）+ 过半写机制
Leader收到事务请求，转换为事务Proposal（提议）同步给所有的Follower，超过半数的Follower都说收到事务proposal了，Leader再给所有的Follower发一个Commit消息，让所有Follower提交一个事务
主从同步机制
如果Leader崩溃了，要重新选举Leader保证继续运行
选举一个leader出来，然后leader等待集群中过半的follower跟他进行数据同步，只要过半follower完成数据同步，接着就退出恢复模式，可以对外提供服务了
如果一个follower跟leader完全同步了，就会加入leader的同步follower列表中去，然后过半follower都同步完毕了，就可以对外继续提供服务了
剩余机器超过一半，集群宕机不超过一半的机器，就可以选举新的leader，数据同步
只要有超过一半的机器，认可你是leader，你就可以被选举为leader
过半机器选举机制
崩溃恢复机制
不是强一致性，zk官方给自己的定义：顺序一致性，他比最终一致性更好一点
1，有的follower已经commit了，但是有的follower还没有commit
2，不是说leader必须保证一条数据被全部follower都commit了才会让你读取到数据，而是过程中可能你会在不同的follower上读取到不一致的数据，但是最终一定会全部commit后一致，让你读到一致的数据的
最终一致性
就会选举一个拥有事务id最大的机器作为leader，他得检查事务日志，如果发现自己磁盘日志里有一个proposal，但是还没提交，说明肯定是之前的leader没来得及发送commit就挂了
01，Leader收到了过半的follower的ack，接着leader自己commit了，还没来得及发送commit给所有follower自己就挂了
老leader自己磁盘日志里有一个事务proposal，他启动之后跟新leader进行同步，发现这个事务proposal其实是不应该存在的，就直接丢弃掉就可以了
02，leader可能会自己收到了一个请求，结果没来得及发送proposal给所有follower之前就宕机了
数据一致性问题
ZAB的核心思想
64位的，高32位是leader的epoch，是leader的版本；低32位才是自增长的zxid
新leader选举出来，epoch会自增长一位
老leader恢复了连接到集群是follower了，此时发现自己比新leader多出来一条proposal，但是自己的epoch比新leader的epoch低了，所以就会丢弃掉这条数据
zxid
数据同步是用什么协议做的
数据一致性
每台zk机器都在内存维护数据，所以zk集群绝对是高并发高性能的
如果你让zk部署在高配置物理机上，一个3台机器的zk集群抗下每秒几万请求没有问题
高性能
集群中挂掉不超过一半的机器，都能保证可用，数据不会丢失
高可用
基于纯内存数据结构来处理，并发能力是很高的、
只有一台机器进行写，但是高配置的物理机，比如16核32G，写入几万QPS
所有机器都可以读，3台机器的话，起码可以支撑十几万QPS
高并发
特性
只有Leader是可以写的
客户端可以随便连接leader或者follower，如果客户端连接到follower，follower会把写请求转发给leader
Leader
Follower是只能同步数据和提供数据的读取
Leader挂了，Follower可以继续选举出来Leader
Follower
Observer也只能读但是Observer不参与选举
大量的服务的上线、注册、心跳的压力，达到了每秒几万，甚至上十万，zk的单个leader写入是扛不住那么大的压力的
zk是适合写少的场景
读可以有每秒几万QPS
提供读服务，可以无限的扩展机器
所有机器的配置文件，都要加入一个server.4=zk04:2888:3888:observer
配置：peerType=observer
Observer
三种角色的机器
客户端就会跟zk建立连接，是TCP长连接
建立了一个会话，就是session，可以通过心跳感知到会话是否存在
sessionTimeout，意思就是如果连接断开了，只要客户端在指定时间内重新连接zk一台机器，就能继续保持session，否则session就超时了
客户端与ZooKeeper之间的长连接
树形结构的znode，里面可以写入值，就这数据模型，都在zk内存里存放
哪怕客户端断开连接，也一直存在
span style=\"mso-spacerun:'yes';font-family:等线;mso-bidi-font-family:'Times New Roman';font-size:10.5000pt;mso-font-kerning:1.0000pt;\"持久节点
客户端断开连接，节点就没了
临时节点
创建节点的时候自增加全局递增的序号
顺序节点
分布式锁
span style=\"mso-spacerun:'yes';font-family:等线;mso-bidi-font-family:'Times New Roman';font-size:10.5000pt;mso-font-kerning:1.0000pt;\"加锁的时候，是创建一个临时顺序节点
zk会自动给你的临时节点加上一个后缀，全局递增的，编号
如果你客户端断开连接了，就自动销毁这个你加的锁，此时人家会感知到，就会尝试去加锁
临时顺序节
持久节点
分布式协调和通知(微服务)
案例应用
数据模型
客户端可以对znode进行Watcher监听
在分布式系统的协调中应用
znode改变的时候回调通知你的这个客户端
分布式架构中的系统A监听一个数据的变化，如果分布式架构中的系统B更新了那个数据/节点，zk反过来通知系统A这个数据的变化
分布式系统的协调需求
Watch监听
核心机制
8核16G，16核32G，高配置虚拟机最好了，SSD固态硬盘
3台机器，1个leader，2个follower，leader主要是写，每秒抗几万并发写入是可以的；leader+follower，读，每秒抗个5万~10万的读是没有问题的
机器如果有16G的内存，堆内存可以分配个10G，栈内存可以分配每个线程的栈是1MB，Metaspace区域可以分配个512MB都可以
新生代+老年代，ParNew+CMS，如果是大内存机器，不建议这个组合了，就用G1回收所有的垃圾对象，还得设置一些G1的参数，region的大小，预期的每次GC的停顿时间是多少毫秒，比如100ms
设置垃圾回收器
环境配置
其他的一些参数就会以这个tickTime为基准来进行设置，比如有的参数就是tickTime * 2
tickTime：zk里的最小时间单位，2000毫秒，2s
内存里有一份快照，在磁盘里其实也会有一份数据的快照，zk停机了，重启，才能恢复之前的数据
dataDir：主要是放zk里的数据快照，剖析zk的源码的时候
dataLogDir：写数据，2PC，proposal（事务），每台机器都会写入一个本地磁盘的事务日志，主要是放一些日志数据
SSD固态硬盘，读写速度非常快，dataLogDir，事务日志磁盘写，是对zk的写性能和写并发的影响是很大的
zk集群启动的时候，默认值10，10 * tickTime，20s
leader在启动之后会等待follower跟自己建立连接以及同步数据，最长等待时间是20s
zk里存储的数据量比较大了，follower同步数据需要的时间比较长，此时可以调大这个参数
initLimit
默认值5，5 * tickTime，10s
leader跟follower之间会进行心跳，如果超过10s没有心跳，leader就把这个follower给踢出去了，认为他已经死掉了
syncLimit
一份是在磁盘上的事务日志，一份是在内存里的数据结构，理论上两份数据是一致的，即使是有follower宕机，也是内存里的数据丢失了，但是磁盘上的事务日志都是存在的
有的follower没收到事务日志就宕机了，也可以在启动之后找leader去同步数据
每次执行一定的事务之后，就会把内存里的数据快照存储到dataDir这个目录中去，作为zk当前的一个数据快照
1000个事务对应的内存数据写入到dataDir里作为一个数据快照，继续此时事务日志里有1032个事务，此时zk重启，他可以直接把包含1000个事务的快照直接加载到内存里来
然后把1000之后的32个事务，1001~1032的事务，在内存里回放一遍，就可以在内存里恢复出来重启之前的数据了
snapCount：100000，默认是10万个事务，存储一次快照
10万个事务以内，不需要快照，因为直接读取事务日志，回放到内存就重建内存数据了
数据快照
一台机器上最多能启动多少个ZooKeeper客户端
zk servers最多只能允许你的一台机器跟他建立60个连接
有限制的，默认来说60
每次请求都创建一个zk客户端，跟他建立连接，进行通信，再销毁zk客户端，如果并发有很多个请求一起连接zk，此时会导致一台机器上有很多zk客户端，会被zk servers拒绝的
maxClientCnxns
一个znode最多可以存储多少数据呢？1mb，1048575
jute.maxbuffer
3888端口，是用来在集群恢复模式的时候进行leader选举投票的
2888的端口，是用来进行leader和follower之间进行数据同步和运行时通信
server.1=zk01:2888:3888
autopurge.purgeInterval=1autopurge.snapRetainCount=3
后台自动清理掉多余的事务日志文件和数据快照文件
事务日志和数据快照是如何进行定时清理的
第一个阶段里，各个机器把事务日志写入磁盘，此时一般进入os cache的，没有直接进入物理磁盘上去
commit提交的时候一般默认会强制把写的事务fsync到磁盘上去
commit的时候，需要fsync到磁盘上去
但是，有可能会丢失部分os cache里没刷入磁盘的数据，如果是leader宕机
forceSync：yes
磁盘的事务日志有没有丢失的风险
leader是否接受客户端的连接，写请求由follower转发给leader，leader主要接受follower的转发写请求进行处理
leaderServers：yes
在进行leader选举的时候，各个机器会基于3888那个端口建立TCP连接，在这个过程中建立TCP连接的超时时间
cnxTimeout：5000
参数
echo conf | nc localhost 2181
conf（查看配置）、cons（查看连接）、crst（重置客户端统计）、dump（输出会话）、envi（查看环境）、ruok（检查是否在运行）、stat（查看运行时状态）、srst（重置服务器统计）、wchs（查看watcher信息）、wchc（输出watche详细信息）、wchp（输出watcher，以znode为单位分组）、mntr（输出比stat更详细的）
-Dcom.sun.management.jmxremote.port=21811-Dcom.sun.management.jmxremote.ssl=false-Dcom.sun.management.jmxremote.authenticate=false
开启ZooKeeper的JMX端口观察内存
命令
CuratorFramework client = CuratorFrameworkFactory.newClient( \"localhost:2181\
curator的crud的操作，底层都是调用的原生zk的API
client.create() .creatingParentsIfNeeded() .withMode(CreateMode.PERSISTENT) .forPath(\"/my/path\
client.setData().forPath(\"/my/path\
client.delete().forPath(\"/my/path\");
byte[] dataBytes = client.getData().forPath(\"/my/path\");
配置中心
注意：用原生的zk去注册监听器的话，监听子节点或者节点自己，如果发生了对应的事件，会通知你一次，但是下一次再有事件就不会通知了，zk原生的API里，需要你每次收到事件通知之后，都需要自己重新注册watcher，但是curator就不会有这个问题
font color=\"#ff00ff\
pathChildrenCache.getListenable().font color=\"#f15a23\
cache就是把zk里的数据缓存到了你的客户端里来
针对这个缓存的数据加监听器，去观察zk里的数据的变化
Path监听节点下一级子节点的增、删、改操作
final font color=\"#ff00ff\
nodeCache.getListenable().addListener(new NodeCacheListener() { public void nodeChanged() throws Exception { Stat stat = client.checkExists().forPath(“/yh/config”); if(stat == null) { } else { nodeCache.getCurrentData(); } } });
Node监听节点对应增、删、改操作
增加监听：treeCache.getListenable().font color=\"#f15a23\
Tree其所有的子节点操作进行监听，呈现树形目录的监听
监听和通知
指定的目录下创建一个子节点，创建一个临时顺序节点
如果你发现自己不是leader，对自己上一个节点施加一个监听器
如果发现上一个节点不存在了，此时会重新再次尝试去创建一个znode，相当于是竞争成为leader
获取到的子节点做一个排序，然后看看自己是不是第一个子节点
第一种Leader选举机制
分布式锁来竞争成为leader的，如果说你获取到了锁，就说明你是leader，获取锁也是跟第一种一样，创建临时顺序节点
第二种Leader选举机制
Leader选举
zookeeperFactory
注册watcher监听器
CuratorZooKeeperClient
CuratorFramework
注册Watcher监听器
启动一个线程，网络连接监听
创建原生ZooKeeper的客户端
session过期时间
watcher，监听zk里的事件的变更，回传给curator的framework
底层的源码，就会去跟zk的一台机器建立真正的TCP长连接
之后就会进行心跳，维护一个session，发送各种请求过去给zk server
注册watcher，zk有事件变更，会通过TCP长连接，反向通知你的ZooKeeper客户端，他会回调你提供给他的watcher
建立连接
判断你加写锁是否成功，看一下你在/locks/lock下面的位置，如果你的写锁临时顺序节点是在/locks/lock下面的第一个
对前一个节点加监听器
如果没有获取到锁对哪个节点进行监听
/locks/lock/__WRITE__{很多临时顺序节点}，排队等待加写锁
去找到排在最前面的写锁，如果发现排在位置=0有一个写锁，此时获取读锁就一定失败
读锁的位置排在第一个写锁的前面，就可以获取读锁
如果没有获取到读锁，监听第一个写锁
/locks/lock/__READ__{很多临时顺序节点}，加读锁
写锁只关注自己前面的写锁
解决写锁羊群效用
所有的读锁只关注监听离自己最近的前一个写锁
解决读锁羊群效用
羊群效用
Curator实现的ZK读写锁
源码
curator客户端框架
集群中加入一台机器，自动在zk中写入一个znode，临时节点，一旦节点关闭或者宕机，临时节点自动消失。由集群Master控制节点监听zk目录子节点变化，自动感知集群中节点的上线和下线
集群里的元数据存储，无非就是对znode进行crud
监听与回调，对你需要感知的znode加监听器，回调通知你
master选举，无非也都是说创建一些临时顺序节点，排在第一位的就是leade
集群扩容与宕机 自动感知机制
http://ant.apache.org/bindownload.cgi
下载apache-ant-1.10.5-bin.tar.gz
ANT_HOME D:\\apache-ant-1.10.5path D:\\apache-ant-1.10.5\\binclasspath D:\\apache-ant-1.10.5\\lib
配置环境变量
ant安装
下载https://archive.apache.org/dist/zookeeper/zookeeper-3.4.5/
https://zookeeper.apache.org/releases.html#download
zk
环境
每台机器都可以成为leader，可以干leader的事儿，每台机器也都可以成为follower
里面任何一个节点都可以认为是一个peer
zk的进程，就是QuorumPeerMain进程，java命令，通过java命令启动一个jvm进程
zk是Peer-to-Peer的集群架构，里面有leader-follower的角色区分，在多个peers节点之间要选举一个Leader出来的话
peer架构
quorum集群，多台机器组成了一个集群，peer，集群各个机器的角色都是一样的，能干的事儿都是一样的，他不是master-slave的架构
zk集群
QuorumPeerMain启动
如果配置了servers，就以集群模式启动
启动ZooKeeperServerMain类
单机版启动
zk启动
三台机器，myid分别是0，1，2
达到了quorum的数量，此时就可以发起leader选举了
quorum=(3/2 + 1)=2
优先是zxid最大的机器成为leader
第一轮投票
票数已经达到了集群的quorum大多数了
myid=0的机器，followermyid=1的机器，leader
第二轮投票
myid=2的机器，刚刚才启动，此时发现集群里已经选举出来leader了，此时自己让自己变成follower就可以了
一般来说如果你自己部署在windows上搞3台虚拟机，部署zk集群，一台一台接着启动，第二台机器往往是leader，第一台和第三台是follower，第二台是leader
Leader选举流程
类似于im系统里用的protobuf
序列化，你得把类转化为字节数组/字节流，通过网络传输类对象的字节流
反序列化，到了对方收到自己流之后，就把字节转换为一个类的对象
zk里的序列化的协议是jute
leanrner里面的jute序列化（serialize方法）和字节流输出的一个过程
封装一个learnerInfo对象放入QuorumPacket进行序列化为字节流发送给leader
Follower在完成连接建立之后是如何向Leader进行注册的
type，zxid
从jute输入流读取数据
反序列化成对象，保存一些数据
如果follower刚跟leader连接后，会跟leader进行数据同步
数据同步完后，会接收follower的ack
后期leader会开一个线程不停的发送数据给follower
Leader是如何处理Follower的注册请求
建立连接主要说的是TCP物理连接，他其实还需要进行一些通信，建立一个Session会话
服务端会收到一个ConnectRequest请求
服务端拿到ConnectRequest请求后，jute反序列化成对象
1，当前时间戳，左移24位，又右移8位
2，与myid的二进制左移56位进行或运算
3，sessionId++
最后一定是唯一的
二进制位运算
1，生成唯一的sessionId（64位）
2，在几个内存数据结构中放入这个session
3，对session计算它的过期时间以及特殊处理
createSession（）
session是由服务端构造开启的，客户端仅仅是发送ConnectRequest请求
expireTime就是session下一次的过期时间
zoo.cfg可以配置
分成一个个的桶，每个桶的长度就是2S，后面计算2S内有哪些session需要检测是否过期
expirationInterval=2S间隔
（7/expirationInterval+1）*expirationInterval相等
（6/expirationInterval+1）*expirationInterval
提高管理的效率，每次处理多个session
达到效果：不同的expireTime得到相同的tickTime
expireTime（12:05）：sessionSet（多个session）
expireTime（12:10）：sessionSet（多个session）
session tracker而言就是不停的过期一个一个分桶
session分桶机制分桶（tickTime）过期时间管理
客户端clientCnxn在run的时候会计算ping的时间
假如120S
sessionTime一般会自己设置
客户端把ping请求放到“等待发送队列”
同时唤醒底层的网络通信组件socket
底层selector监听writeable事件
sendPing（）客户端每隔一段时间发送ping到服务端
客户端是如何定期发送Ping心跳到服务端
读出请求数据
底层selector监听readable事件
1，任何的请求都会submitRequest（）
2，都会touch一下session，更新他的expireTime，重新分桶
3，会交给RequestProcessor线程来进行处理
服务端是如何接收和处理Ping心跳请求
ping心跳
Session会话
1，返回ack给leader，会尽快的用while循环，把积压在内存队列里排队的proposal的请求全部都尽快的写入到磁盘上的事务日志里去
一旦将队列里积压的proposal都写入事务日志了，此时就可以执行flush了
follower要写入1000条事务日志之后，才能进行flush以及后续的处理
2，如果你连续写入1000条数到事务日志里去，此时也会强制性执行flush以及后续的操作
follower写多少条数据到事务日志文件之后，会执行flush
同时写一份数据快照，包含了1~10000条事务
1~10000条数据，在这个事务日志文件01里
同时写一份数据快照，包含了1~20000条事务
这个快照就可以恢复数据
10001~20000条数据，在这个事务日志文件02里
删除包含了1~10000条事务的数据快照
删除包含了1~10000条事务的日志
删除包含了10001~20000条事务的日志
定期清理磁盘上不需要使用的文件
同步数据
对于zk来说，核心的数据结构，并不是文件目录树的结构
而是map接口，他所有操作都是针对一个path
所有watcher都是监听dataTree
DataTree.java
create [-s] [-e] path data acl s表示临时 e表示序号递增
client.create().creatingParentsIfNeeded().withMode(CreateMode.PERSISTENT).forPath(\"/demo01/world\");
创建节点
ls path [watch] 后面可以跟watch监听某个节点
byte[] bytes = client.getData().forPath(\"/demo01/world\");
childWatcher可以对这个znode的子节点变化进行监听
获取路径数据的同时，可以对这个路径加一个监听器
查询节点
set path data [version]
client.setData().forPath(\"/demo01/world\
修改节点
delete path [version]
client.delete().forPath(\"/hello5\");
删除节点
rmr path
递归删除
判断当前节点是否存在
exists
watch机制
crud操作
首先由nioServerCnxnFactory收到请求
写请求以字节流发送到leader
进入FollowerRequestProcessor
如果请求发到follower，如何转发给leader
后面会拼上一串递增的10位的数字
/kafka/brokers/brokers-0000000001
/kafka/brokers/brokers-0000000002
顺序节点是如何来处理的
ephemeral，会全部删除掉
并且一定会触发相对应的watch监听器
临时节点，如果你的客户端宕机了，临时节点会自动被删除掉
先检查当前session是否过期
每次创建节点，都会更新父节点的cversion值
只有leader才可以生成zxid
全局性的生成唯一的zxid，内部加了synchronized锁，，会不断的++
proposal的zxid是如何创建
zookeeper最最核心的一块机制，监听和回调机制
对znode文件目录树的数据结构进行增删改查的操作，临时节点，顺序节点，最多只能实现让一些其他的分布式系统、大数据系统可以基于zk进行集群元数据的存储和管理
提供监听和回调的机制，只有把这个功能给实现了，此时zookeeper才是工业级的
也需要其他的很多功能，协调、选举、高可用自动切换
gateData时传一个watcher
getChildren时传一个watcher，对子节点加一个监听器
监听是否存在
exists可以加一个watcher
三种监听器
watcher会放入请求中
在客户端也要保存一份；在zk服务端也要保存一份
对每一个路径，都会有一系列的监听器
ZKWatchManager.java
只有保证从服务端成功请求之后，服务端表示已经注册监听器了，然后客户端再进行注册。
调用zookeeper.java的register注册方法
知道这些请求成功完成了，返回响应，此时调用了finishPacket方法，才会进行监听器的注册
什么时候在客户端完成注册
watcher会放入请求中发送给服务端
NIOServerCnxn实现了watcher接口
对于服务端而言，跟每个客户端的连接，都是一个nioServercnxn
watcher==客户端的连接
gateData（）的时候
path->对应多个wathcer
wathcer（客户端连接）->对应多个path
如果说一旦客户端的session断开，zk服务端要进行一些清理，1，删除临时节点，2，以及删除客户端注册的一些监听器
zk服务端处理查询请求中的watch标识
内存里znode树出现变化，执行commit之后，会触发一些watcher监听器
先增删改，然后触发回调
dataWatches.triggerWatch()
触发当前节点监听器
childWatches.triggerWatch()
假如对目录增加了一个childWatcher
触发子节点监听器
所以原生api里，监听器是一次性的，数据变化触发了监听器，自动会删除这个监听器
所以才用curator去连续监听，此时Curator他会在底层自动进行重新注册
触发监听器后，直接把zk服务端注册的监听器给删除掉
比如对一个节点加了监听器，增删改的时候
增删改事件发生的时候触发监听器
childWatches.triggerWatch()以后会调用process方法
里面包括，类型，状态，path
会拿到一个watcherEvent事件
sendResponse（）序列化以后，直接响应客户端
服务端触发监听器的时候，回调客户端连接
clientCnxn读取请求
收到watchedEvent事件
zk客户端收到watch监听通知的请求之后，如何处理
监听器
创建监听器
2PC的模式去进行删除
会删除掉你所有的这个客户端创建的临时节点
删除了之后到commit的时候，删除了内存里的节点，一定会触发对应的监听器的
客户端加在服务端上的这些监听器都给干掉
zk服务端
客户端挂掉
客户端必须去找其他的机器，leader，follower，去建立长连接
建立会话，重新把自己内存里注册的那些监听器，在新建立连接的机器上去进行一个重新的注册
客户端
1，follower挂掉
2，leader挂掉
3，版本升级
三种宕机
客户端发送请求或ping
会执行socket.write()方法，这时候会感知到服务端挂掉了，抛异常出去
doTransport()抛异常
doIO抛异常
客户端主动断开网络连接，关闭socket
然后再关闭，socketChannel
对多有pendingqueue（已发送等待响应的请求）标记失败完成
对还没发送出去的请求（sendqueue）标记器失败
清空自己的监听器（watcher）
cleanup
发布一个断开事件
catch会捕获到异常
startconnect()
连接集群内其他的zkserver。连接下一台
连接成功后，重新进行监听器的注册
一旦默认监听器感知到说建立了新的连接，此时要重新去施加所有的监听器
clientCnxn通信组件的run方法，进行重新连接
客户端如何感知服务器宕机
follower是主动跟leader建立网络连接的
proposalRequestProcessor同步数据时(LearnerHandler线程)，是可以感知到的
抛异常后捕获，socket关闭
majority（超过集群节点个数的一半以上）
集群本身没有影响，还能用，读请求没有影响
但是新的增删改有影响，因为返回不了过半的ack，不会进行第二阶段的commit
所以要尽快的恢复follower，然后同步数据，返回ack
挂掉一个follower，对leader的2PC过半写机制有影响吗
会跟leader进行数据同步，syncWithLeader（）
LearnerHandler会发很多的数据，同步给follower
follower会收到一些proposal，然后返回ack
重启挂掉的follower
follower宕机，leader是如何感知
连接在这台机器的客户端短时间内肯定会不停的重新连接
zk短时间内是灾难性的
follower从leader读取数据异常，直接关掉连接
follower感知到leader崩溃后，释放掉网络资源，执行Leaner的shutdown（），并把状态设置成looking
follower他会把所有客户端的连接全部断开，对于客户端而言的话，他会短时间内频繁报错
哪个follower接收到的zxid更大，或者zxid一样大，myid，两个人一定会投票给某一个人，两轮投票，结果出来
大约需要几百毫秒或者最多几秒钟就会选出来
此时集群就需要重新进行一个leader选举
follower会跟新的leader建立连接，LearnerHandler（发送请求和接受响应ack）跟他进行通信，进行数据恢复
另外，对外提供服务，所有的客户端会自动进行重连的，找到一台机器进行连接，读写请求继续执行，另外监听器重新施加
宕机的那台leader再次重启，他此时就会发现已经有leader了，此时他就是一个follower，跟leader建立长连接，然后进行数据的恢复，接着的话呢，整个集群就瞬间就可以恢复运作了
选举出新的leader之后
Leader宕机，各个follower会如何感知
正常情况下，会把磁盘上事务日志快照重新加载到内存中
调用loadDataBase()
他把最近的磁盘快照反序列化到内存，对快照进行回放
然后基于内存的数据与leader进行数据同步
zkDataBase.java
zk重启的时候，是如何加载磁盘上的数据进行恢复的
服务端
zk服务端挂掉
zk的核心源码
zookeeper
0 条评论
回复 删除
下一页
