初学zookeeper01

初学zookeeper01 zookeeper

1.zookeeper是一个分布式协调的开源框架;
主要用于分布式集群中应用系统的一致性问题;如怎样避免同时 *** 作同一数据造成解读的问题;
2.zookeeper本质上是一个分布式的小文件存储系统;
3.提供基于类似于文件系统的目录树方式的数据存储,
4.并且可以对树中的节点进行有效管理,从而用来维护和监控你存储的数据的状态变化;
通过监控这些数据状态的变化,从而可以达到基于数据的集群管理
5.例如:统一命名服务,分布式配置管理,分布式消息队列,分布式锁,分布式协调等功能;

什么是zookeeper？
1：zookeeper是apache hadoop的子组件之一
2：zookeeper主要服务于分布式系统。统一配置管理、统一命令服务、分布式锁、集群管理

能干啥zookeeper
ZooKeeper 是一个典型的分布式数据一致性解决方案，分布式应用程序可以基于 ZooKeeper
实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能

zookeeper的数据结构
可以看做是一棵树，每个节点叫做ZNode。每个节点可以通过路径来标识，结构图如下：

ZNode分为俩种类型

短暂/临时：当客户端和服务端断开链接后，所创建的ZNode节点会自动删除

持久：当客户端和服务端断开链接后，所创建的ZNode不会删除

zookeeper如何做到统一配置管理、统一命名服务、分布式锁、集群管理
1.统一配置管理
假设我们现在有三个系统A、B、C，他们有三份配置，分别是ASystem.yml、BSystem.yml、CSystem.yml，这三份配置非常类似，很多的配置项几乎都一样。此时，如果我们要改变其中一份配置项的信息，很可能其他两份都要改。并且，改变了配置项的信息很可能就要重启系统。于是，我们希望把ASystem.yml、BSystem.yml、CSystem.yml相同的配置项抽取出来成一份公用的配置common.yml，并且即便common.yml改了，也不需要系统A、B、C重启。

2.统一命名服务
比如说，现在我有一个域名http://www.xxx.com，但我这个域名下有多台机器：

192.168.1.1

192.168.1.2

192.168.1.3

192.168.1.4

可以统一依靠域名访问
3.分布式锁
系统A、B、C都去访问/locks节点

正在访问的时候会创建带顺序号的临时/短暂的节点
比如说系统A创建了id_1节点，系统B创建了id_2节点，系统C创建了id_3节点。

接着，拿到/locks节点下的所有子节点(id_1,id_2,id_3)，判断自己创建的是不是最小的那个节点
如果是，则拿到锁。
释放锁：执行完 *** 作后，把创建的节点给删掉
如果不是，则监听比自己要小1的节点变化

原理：
系统A拿到/lock节点下的所有子节点，经过比较，发现自己
系统A拿到/locks节点下的所有子节点，经过比较，发现自己(id_1)，是所有子节点最小的。所以得到锁

系统B拿到/locks节点下的所有子节点，经过比较，发现自己(id_2)，不是所有子节点最小的。所以监听比自己小1的节点id_1的状态

系统C拿到/locks节点下的所有子节点，经过比较，发现自己(id_3)，不是所有子节点最小的。所以监听比自己小1的节点id_1的状态……等到系统A执行完 *** 作以后，将自己创建的节点删除(id_3)。通过监听，系统C发现id_1节点已经删除了，发现自己已经是最小的节点了，于是顺利拿到锁….
4.集群管理
以我们三个系统A、B、C为例，在zookeeper中创建临时节点即可

只要系统A挂了，那/groupMember/A这个节点就会删除，通过监听groupMember下的子节点，系统B和C就能够感知到系统A已经挂了。(新增也是同理)

除了能够感知节点的上下线变化，ZooKeeper还可以实现动态选举Master的功能。(如果集群是主从架构模式下)

原理也很简单，如果想要实现动态选举Master的功能，Znode节点的类型是带顺序号的临时节点(EPHEMERAL_SEQUENTIAL)就好了。

Zookeeper会每次选举最小编号的作为Master，如果Master挂了，自然对应的Znode节点就会删除。然后让新的最小编号作为Master，这样就可以实现动态选举的功能了。

zk选举

1.集群至少由三个节点组成

虽然说俩个也可以，如果其中一个节点挂了，zookeeper就不能提供对外服务，失去了集群的意义

2.节点并非越多越好

节点越多

1. 使用的资源越多。
2. zookeeper节点间花费的通讯成本越高，节点间互连的socket也越多，影响zookeeper集群事务处理。
3. 造成脑裂的可能性越大
   3.集群规模为奇数
   3台和4台都是可以挂一台，因为过半性
   
   4.集群角色

Leader

在一个zookeeper集群中只能存在一个leader，集群中事务请求的唯一调度者和处理者，leader根据事务ID保证事务处理的顺序性

如果一个集群中存在多个leader，这个现象称为脑裂，大集群裂变为小集群，会导致数据不同步，数据混乱。

Follower

只能处理非事务请求，如果收到事务请求转发给leader；参与leader选举；参与事务处理投票

observer观察者

与follower相似，可以处理非事务请求；将事务请求转发给Leader服务器。但是它不会参与leader的选举，不会参与投票。

如何成为观察者：在zoo.cfg中添加如下属性：peerType=observer

作用：用于不影响集群事务处理能力的前提下提升集群的非事务处理能力。

5：leader选举机制

1、选举投票必须在同一轮次中进行

如果Follower服务选举轮次不同，不会采纳投票。

2、数据最新的节点优先成为Leader

数据的新旧使用事务ID判定，事务ID越大认为节点数据约接近Leader的数据，自然应该成为Leader。

3、比较myid，id值大的优先成为Leader

如果每个参与竞选节点事务ID一样，再使用myid做比较。myid是节点在集群中唯一的id，myid文件中配置。

6：过半原则

Leader选举投票；事务提议投票；这些投票依赖过半原则。

事务提议投票
假设有3个节点组成ZooKeeper集群，客户端请求添加一个节点。Leader接到该事务请求后给所有Follower发起「创建节点」的提议投票。如果Leader收到了超过集群一半数量的反馈，继续给所有Follower发起commit。此时Leader认为集群过半了，就算自己挂了集群也是安全可靠的。

Leader选举投票
假设有3个节点组成ZooKeeper集群，这时Leader挂了，需要投票选举Leader。当相同投票结果过半后Leader选出。

集群可用节点
ZooKeeper集群中每个节点有自己的角色，对于集群可用性来说必须满足过半原则。这个过半是指Leader角色 + Follower角色可用数大于集群中Leader角色 + Follower角色总数。
假设有5个节点组成ZooKeeper集群，一个Leader、两个Follower、两个Observer。当挂掉两个Follower或挂掉一个Leader和一个Follower时集群将不可用。因为Observer角色不参与任何形式的投票。

7场景实战

1.leader挂了选举过程

假设有3节点组成的集群，分别是server.1（Follower）、server.2（Leader）、server.3（Follower）。此时server.2不可用了。集群会产生以下变化：

状态变更

所有Follower节点变更自身状态为LOOKING。投票内容就是自己节点的事务ID和myid。我们以(事务ID,myid)表示。

假设server.1的事务id是10，变更的自身投票就是（10, 1）；server.3的事务id是8，变更的自身投票就是（8, 3）。

投票机制

将变更的投票发给集群中所有的Follower节点。

server.1将（10, 1）发给集群中所有Follower，包括它自己。server.3也一样，将（8, 3）发给所有Follower。

所以server.1将收到（10, 1）和（8, 3）两个投票，server.3将收到（8, 3）和（10, 1）两个投票。

投票PK

比较规则：先比较事务id（Zxid），如果事务id相同则比较myid；超过一半节点才能成为leader。

对于server.1来说收到（10, 1）和（8, 3）两个投票，与自己变更的投票比较后没有一个比自身投票（10, 1）要大的，所以server.1维持自身投票不变。

对于server.3来说收到（10, 1）和（8, 3）两个投票，与自身变更的投票比较后认为server.1发来的投票要比自身的投票大，所以server.3会变更自身投票并将变更后的投票发给集群中所有Follower。

统计投票

此时server.1和server.3接收桶里的数据是这样的：

server.3经过PK后认为server.1的选票比自己要大，所以变更了自己的投票并重新发起投票。

server.1收到了来自server.3的（10, 1）投票;server.3收到了来自sever.3的（10, 1）投票。

此时server.1和server.3接收桶里的数据变成了这样：

基于ZooKeeper过半原则：桶内投票选举server.1作为Leader出现2次，满足了过半 2 > 3/2 即 2>1。

最后sever.1节点晋升为Leader，server.3变更为Follower。

zookeeper的特性
1.可用性
一个 ZooKeeper 集群如果要对外提供可用的服务，那么集群中必须要有过半的机器正常工作并且彼此之间能够正常通信。

2.顺序一致性

就是执行过程会严格按照顺序执行

3.数据一致性

数据一致性指的是在leader更新数据后，follower必须保证数据与leader一致