zookeeper简介

zookeeper概念

1. zookeeper是一个分布式的 开源的，分布式应用程序的协调服务，zookeeper翻译过来就是动物管理员，它用来管理Hadoop(大象)，Hive(蜜蜂)，pig(小猪)的管理员 简称zk

　　zookeeper提供的功能主要包括：

　　　　配置管理

　　　　分布式锁

　　　　集群管理

2. zookeeper是一个树形目录服务(文件系统)，每一个节点都会保存自己的数据和节点信息

　　节点可以分为四大类

　　　　持久化节点

　　　　临时节点 -e

　　　　持久化顺序节点 -s

　　　　临时顺序节点 -es　　

常用命令

　　1.连接到zookeeper服务器

　　　　进入到bin目录 执行  ./zkCli.sh ip:port

　　2.查看节点和子节点

　　　　ls /xxx

　　3. 创建节点并存放数据

　　　　3.1 create /app1 hello 此时创建的是持久化节点

　　　　3.2 create -e /app1  此时创建的是临时节点 当前会话断开，节点就消失了

　　4.获取数据

　　　　get /app1  输出:hello

　　5. 设置数据

　　　　set /app1 nihao (此时 nihao会把上面的hello覆盖)

　　6. 删除节点 delete /app1

ZK分布式锁

核心：当客户端想要获取锁，就创建节点，释放锁就删除。

　　1. 客户端获取锁时，在lock(随便取的名字)节点下创建临时顺序(如果是持久化节点，获取锁的节点如果宕机了，锁就不会被释放/删除了)节点。

　　2. 然后获取lock下面所有的子节点(节点是树形结构嘛)，客户端获取到所有的子节点之后，如果发现自己创建的子节点序号最小，就认为该客户端获取到了锁。使用完锁后，将该节点删除。

　　3. 如果发现自己创建的节点并非lock所有子节点中最小的(1 2 3获取到了2 )，说明自己还没有获取到锁，此时客户端需要找到比自己小的那个节点(2)，同时对其注册事件监听器，监听删除事件。

　　4. 如果发现比自己小的节点被删除(2)，则客户端的watcher会收到相应的通知，此时再次判断自己创建的节点是否是lock子节点序号最小的，如果是则获取到了锁，如果不是则重复上面的步骤，继续获取比自己小的一个节点，并注册监听。

java curator API锁的实现

lock.acquice(3,TimeUnit.SECONDS); //获取锁 获取不到等待3s钟
......
lock.release(); //用完释放锁

参考redis分布式锁：

https://www.cnblogs.com/ssskkk/p/10324158.html#_label2

ZK集群

配置集群：

1.在每个zookeeper的data目录下创建一个myid文件，内容分别是1、2、3...这个文件就是记录每个服务器的id。

2.在每一个zookeeper的zoo.cfg配置客户端访问端口(clientPort)和集群服务器IP列表

leader选举机制：

ServerId:服务器id,比如有三台服务器，编号分别是1,2,3。编号越大在选择算法中的权重越大。

Zxid：数据ID 服务器中存放的最大数据ID，值越大说明数据越新，在算法选举中 数据越新权重越大。

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

　　也就是说，每个对节点的改变都将产生一个唯一的Zxid。

　　如果Zxid1的值小于Zxid2的值，那么Zxid1所对应的事件发生在Zxid2所对应的事件之前。

在Leader选举中：如果某台zookeeper获得超过半数的选票，则此Zookeeper就可以成为Leader了。

ZK集群角色

Leader领导者：

　　1.处理事物请求(增删改)

　　2.集群内部各服务器的调度者

Follower跟随者：

　　1.处理客户端非事物请求(查询)，转发事物请求给Leader服务器

　　2.参与Leader选举投票

Observer观察者(分担Follower压力)：

　　1.处理客户端非事物请求(查询)，转发事物请求给Leader服务器

zookpeer 和 redis 集群内一致性协议及选举对比

一致性问题：分布式环境引入副本机制后，不同数据节点间可能出现的，并无法依靠计算机应用程序自身解决的数据不一致情况。

简单的讲，数据一致性就是指在对一个副本数据进行更新的同时，必须确保也能够更新其他的副本，否则不同副本间的数据将不再一致。

引用文章：https://www.cnblogs.com/stateis0/p/9062133.html

zookeeper 选举和数据同步使用的都是zab算法

redis 的哨兵在崩溃选举的时候采用的是 raft算法，但是redis在做主从数据同步的时候，用的是异步方法。

所以redis的性能比较高，但一致性不如zookeeper

下面简单介绍这几个算法：

Paxos算法：

　　paxos算法是Lamport宗师提出的一种基于消息传递的分布式一致性算法，使其获得2013年图灵奖。(其中决策模型是根据希腊城邦发布律法的议会模型去制定的)

　　其中有两阶段提交，一阶段提交：告诉其他议员 我们要讨论某个预案。二阶段提交：将议案内容给到其他议员。

raft协议：

　　基于Paxos算法，但更容易理解与实现

　　对于日志不一致的现象，Raft通过跟随者 强制复制领导者的日志来保证的。

　　客户端的一条指令到达，领导者会为这条指令创建一条日志目录，并且并行发送到其他跟随者。

　　在领导选举的时候，只能让安全的节点当Leader，所谓安全，就是对应节点拥有当前领导者已经提交的所有日志。

zab协议：

　　专门为zookeeper设计的一个一致性算法

Redis ReadLock：

　　基于 Redis 实现分布式锁的方式名叫 Redlock，此种方式比原先的单节点的方法更安全。

　　参考：https://zhuanlan.zhihu.com/p/111354065?from_voters_page=true

注册中心集成

TODO