Zookeeper的学习理解

分布式服务早已盛行，也是我们日常必备的技能，我们常用的主要就是SpringCloud和Dubbo+Zookeeper两种分布式架构。这篇文章主要就讲述我在学习Zookeeper过程中的学习记录，以及一些理解。

一、概念

Zookeeper称为分布式协调服务。

（1）做什么用的？
解决的就是分布式协调问题。—服务治理
用于解决分布式环境中多个进程之间的同步控制，让他们有序的访问某种临界资源。

（2）微服务需要思考的几个问题？
1.客户端如何访问这么多服务？
2.服务之间如何通信？
3.服务治理？怎样才能保证这么多服务正常运行？
4.服务挂了怎么办？

二、主要功能

（1）分布式锁
保证临界资源正常访问和操作。
Zookeeper分布式锁
Zookeeper如何实现分布式锁？
分布式锁：
三个核心要素（功能）
1加锁
2解锁
3锁超时
三个问题
1保证原子性操作—加锁和锁超时要一次执行
2防止误删锁—超时时间还没有执行完成
3在误删锁的基础上，加守护线程
Zookeeper分布式锁：
持久节点
持久节点有序节点
临时节点
临时节点有序节点

结合Redis的分布式锁理解Zookeeper分布式锁：

具体过程分析：
1.Nginx负载均衡控制两个订单服务请求（同时从数据库中减少5个某一指定商品的数量）分别到达两台服务（JVM），表明时并发执行。
2.当商品数只有5时，若两个请求都成功了，会出现商品数为-5的“脏数据”，这种情况是不允许出现的。—所以出现了分布式锁就是为了避免这种情况发生。
3.Redis接受到两个服务的请求（注意这里是顺序性的，就是这些请求即使是并发过来的，但还是会进行排序。），其中JVM1先进行，Redis从数据库中获取对应的商品id后开始上锁。
4.锁操作
加锁操作：setnx(id,value)，分析到这里时，key是商品id，value可以是任意值。
解（删）锁操作：del()，若不释放改商品的锁，别的进程若何操作该商品呢？
超时设置：expire，操作中断（任意原因）没能执行解锁操作，那锁就一致没能释放，造成死锁。
5.redis获取到商品id后给商品上锁，订单2来了会发现这个key存在，也就是这个商品被上锁了，不能被其他进程操作。
6.通过上面的锁操作大致看来就完成了避免出现脏数据了，JVM1操作结束后，JVM2同样执行上述操作。

任然存在的三个问题：
1.非原子性操作
setnx后，expire前宕机了，又成了死锁。所以需要原子性操作，将setnx和expire整合到一起，set(key,value,expire)放到一个方法中同时操作，即为原子性操作。redis 2.6引入的。
2.误删除操作
2.1 JVM1上锁
2.2 JVM1在expire时间内没有操作完成，释放锁
2.3 JVM2获得到锁
2.4 JVM1操作完成执行del操作，释放的是JVM2的锁，操作未完成。
解决方案：del前判断是不是自己的锁，是则删除，否则不处理，这时候value有作用了，将线程id存入value
3. 上面误删除操作中JVM2锁被JVM1删除后也可能被其他的进程获取到，所以还是有问题，应该判断是否执行完成，执行完成才del。
解决方案，在JVM中除处理数据的线程外增加一个守护线程，专门在expire设置的超时时间前判断是否完成操作，未完成则增加时间继续操作，守护线程持续判断是否完成。

（2）服务的注册与发现
Zookeeper也就是服务的注册中心和发现中心—事件通知机制实现

图解Zookeeper的事件通知机制（如何完成服务的注册和发现）：

三、Zookeeper结构

二叉树，树节点称为Znode节点。
Znode包含哪些元素：
data：Znode存储的数据信息，服务的IP，端口，名字等等
CAL：记录Znode的访问权限，即哪些人或哪些IP可以访问本节点
child：当前节点的子节点引用
start：包含Znode的各种元数据，数据的数据叫做元数据，数据的时间，大小等等

如下图：

四、Zookeeper服务结构
首先思考一个问题：如果zookeeper自身挂了怎么办？
所以要实现高可用，防止单机挂掉，自身也维护了一个集群。

主从模式，一主多从。leader-follower
1.写数据，首先更新主节点，再更新到从节点。
2.读数据，直接从节点读取
实现了读写分离
3.保证数据一致性—这里是顺序一致性，对应前面分析的请求到redis成了顺序
用到ZAB协议
解决集群崩溃恢复
崩溃指的是主节点崩溃,选举leader

ZAB的三种状态
Looking（选举阶段），准节点leading
Discovery（发现阶段），避免多主状态
Synchronization（同步阶段），leading同步数据到follower,超半数同步完成，leading变成leader
上面ZAB协议是为了解决主从同步数据，保证数据一致性（强一致性，弱一致性，顺序一致性），Zookeeper是顺序一致性。
大致过程：
1.follower将写操作的请求转发给主节点
2.leader广播通知所有从节点，准备写了
3.follower收到“准备写”通知，将输入写入事物日志
4.follower通知leader数据准备完成
5.leader广播所有leader，开始写，执行commit

随着深入学习理解，后续再接着更新。