一文了解分布式中间ZooKeeper

迈不过友情╰ 2023-02-26 07:22 6阅读 0赞

# 分布式一致性算法Paxos #

## Paxos角色 ##

![8386050692df367635953ea4d4679e93.png][]

*  提供三种角色Proposer 提案者、Acceptors接受者、Learner学习者；
 *  在分布式场景下需要作出一个决策时，需要给Proposer提交一个提案；
 *  Acceptos判断是否接受这个提案，如果超过半数接受提案，需要把确定的结果发送给Learner；
 *  有的Acceptors会拒提案，有可能是已经收到其他服务器发送的请求，所以有新的提案进来时会拒绝；

## Paxos阶段 ##

![21e92f3121b48966769076d7309f855a.png][]

*  第一阶段：Parpare阶段。Proposer向Acceptors发出Prepare请求，Acceptors针对收到的Prepare请求进行Promise承诺；
 *  第二阶段：Accepet阶段。Proposer收到多数Acceptors承诺的Promise后，向Acceptors发出Propose请求，Acceptors针对所收到的Propose请求进行Accept处理；
 *  第三阶段：Learn阶段。Proposer在收到多数Acceptors的Accept之后，标志着本次Accept成功，决议形成，将形成的决议发送给所有的Leanrers；
 *  Proposer生成全局唯一且递增的ProposalID，向所有Acceptors发送Prepare请求，请求无需携带提案内容，只携带ProposalID即可；
 *  Acceptors接收到Prepare和Propose请求后，不在接收ProposalID小于等于当前ID的请求；

# Zab协议 #

![3799b9f1b5b8b71ee8947428ec728713.png][]

*  Zab协议是简化版本的Paxos，成了一个自定义的协议；
 *  一个提案提交到集群时先交给Learer，由eaner决策；
 *  Learner向Follower发出提案Propose，如果Follower接受提案，则会发出一个ACK应答；
 *  如果接收到半数ACK应答，这个提案就是被接受的，然后向所有的Follower发送接受的内容，然后所有程序达成一致；
    
    客户端随便连接一个Follower发送请求，由Follower向Leader发送提案申请，Leaner会向所有Follower包括接收请求的Follower发送提案，如果超过半数有ACK应答，则接受提案，向每个服务器发送记录数据，最后响应给客户端；
    
    # ZooKeeper架构 #

![2f05ada766626614ceec45d74233d557.png][]

*  所有的Server都是一个Follower，只有个Server是Leader；
 *  写数据时，客户端任意连接一个Server，由Server向Leader发送提案做决策；
 *  读数据时不存提案的问题，无论连接哪一个Server都可以直接返回数据，Server状态是一致；

# ZooKeeper API 存储结构 #

![8fcee545ade9687f4aa836e325ef0c17.png][]

*  / 为根目录，所有记录基于根目录操作；
 *  下级目录可通过api创建，一般会根据应用划分不同的目录；
 *  目录下可以创建文件，记录数据；

# ZooKeeper API #

String create(path,data,acl,flags)//创建路径
    void delete(path,expectedVersion)//删除路径
    Stat setData(Path,data,expectedVersion)//设置数据
    (data,Stat) getData(path,watch)//获取数据，并监听数据的变化
    Stat exists(path,watch)//判断数据是否存在
    String [] getChildren(path,watch)//获取子节点
    void sync(path)//异步节点
    List multi(ops)//多数据操作

常见的场景：配置中心、注册中心、分布式锁等都可以基于ZooKeeper实现

# ZooKeeper选master #

![293f8f419c2e53151cf7b8e285408453.png][]

1.  servers下面有多态服务，有一台leader标志，那一台服务器把ip注册在leader位置，就是master
2.  调用接口getData("/servers/leader",true)；
3.  判断getData返回的值，如果不存在，则说明没有leader；
4.  没有leader前提下，调用接口create("/server/leader,hostname,EPHEMERAL)创建一个临时leader，并把自己的主机名写入，创建的时候是一个长链接，当断开之后又会删除leader节点，其它节点又可以抢占；
5.  如果并发场景都在创建不一定成功，如果都不成功，则重复上述步骤；
6.  退出选举逻辑；

# ZooKeeper集群管理 #

![bfd29ac953adc23b2fc0e5c2c8df9ccd.png][]

*  负载均衡器监控nodes节点；
 *  根据接口getChildren获取所有的子节点；
 *  新增服务器是负载均衡器会接收到ZooKeeper的通过，新增ip地址，然后重新调用接口，获取新的机器信息；
 *  如果某一台服务器丢失不可以了，监听也会产生一个事件，然后调用删除接口删除对应的节点信息；负载均衡器就会收到通知不会生效了；
 *  服务器启动的时候都会根据ephemeral创建服务节点；

# Zookeeper性能 #

![cf4f078e3d4c72c603c0e4b7cba01de9.png][]

*  不同颜色分别代表不同服务器，横坐标代表读操作的占比100就是全是读操作，0就是全是写操作；纵坐标代表吞吐能力；
 *  当全部是写操作的时候吞吐能力比较差，全部是读操作的时候吞吐量是比较高的；
 *  读数据的时候不管连接那一台服务器都可以获取到数据，但是写数据需要通过提案才能写入成功；
 *  都是写的情况下，3台服务器比13台服务的吞吐能力高；因为3台只要有两台接受提案就可以操作成功；而13台需要7台接收提案才能写入成功；
 *  服务器越多写操作达成一致性的时间越长，吞吐能力越差；
 *  服务器越多读操作性能越好，吞吐能力越高；

[8386050692df367635953ea4d4679e93.png]: /images/20230209/f326d18a45084f9db53ee0acb199a38f.png
[21e92f3121b48966769076d7309f855a.png]: /images/20230209/bba57f76b42d490ea71f5ca102742d99.png
[3799b9f1b5b8b71ee8947428ec728713.png]: /images/20230209/c0466b6faf7f486bbd32c1bd8760bc34.png
[2f05ada766626614ceec45d74233d557.png]: /images/20230209/2fdda7d5650a41cab85076fcd30911ad.png
[8fcee545ade9687f4aa836e325ef0c17.png]: /images/20230209/6f869b5e5cc047e780956a8a3c39440a.png
[293f8f419c2e53151cf7b8e285408453.png]: /images/20230209/0ff7cfb9a8b945e59116a6e826da5804.png
[bfd29ac953adc23b2fc0e5c2c8df9ccd.png]: /images/20230209/c4a49b5a2ee64252873db6f3cda44079.png
[cf4f078e3d4c72c603c0e4b7cba01de9.png]: /images/20230209/72226b22ef014e51a5dd2e7505730617.png