微服务之Zookeeper

什么是单点故障

通常在分布式系统采用的部署方式是主从模式即一主多从，一个主节点连接着多个从节点，主节点负责分发任务，从节点负责处理任务，当我们主节点出现故障的时候，导致从节点不能继续提供服务，进而导致整个系统的崩溃，我们把这种故障叫做单点故障

什么是分布式协调技术

分布式协调技术主要用来解决分布式环境当中多个进程之间的同步控制，让他们有序的去访问某种临界资源，防止造成”脏数据”的后果。分布式协调技术的核心就是为了实现分布式锁

什么是分布式锁,如何实现分布式锁

分布式锁是控制分布式系统之间共同访问共享资源的一种锁的实现，如果不同的系统的不同主机之间共享了某个资源时，往往需要分布式锁来保证一致性。

2.分布式锁要具备以下几个条件
1.在分布式系统环境下，同一个方法或者属性，在同一时间只能被一台机器的一个线程使用
2. 高可用的获得锁和释放锁
3. 高性能的获得锁和释放锁
4. 具备可重入特性
5. 具备防止锁失效机制，防止死锁
6. 具备非阻塞特性，如果没有获得锁直接返回获取锁失败

3.分布式锁的核心要素 是加锁 解锁 锁超时
要解决三个问题
1.要保证原子性操作 （加锁和锁超时）
2. 要防止误删锁
3.再有一个守护线程 为锁续命

我们一般是使用zookeeper去实现分布式锁

什么是zookeeper

zookeeper是一个为分布式应用提供一致性的的开源组件，它的内部是一个分层的文件目录树结构，树是由节点所组成，Zookeeper 的数据存储也同样是基于节点，这种节点叫做 Znode,Znode 的引用方式是路径引用，类似于文件路径：Znode里面包含以下元素

1. data 用来存储数据的信息
2. ACL 记录Znode的访问权限，即哪些人可以访问哪些ip
3. stat 元数据
4. child 当前节点的子节点引用

zookeeper如何实现分布式锁

zookeeper的节点类型有4种 分为临时节点。临时顺序节点，永久节点，永久顺序节点
那么ZooKeeper如何实现分布式锁呢？思路如下：
首先，在 Zookeeper 当中创建一个持久节点 ParentLock。当第一个客户端想要获得锁时，需要在 ParentLock 这个节点下面创建一个临时顺序节点 Lock1。
之后，Client1 查找 ParentLock 下面所有的临时顺序节点并排序，判断自己所创建的节点 Lock1 是不是顺序最靠前的一个。如果是第一个节点，则成功获得锁。
这时候，如果再有一个客户端 Client2 前来获取锁，则在 ParentLock 下载再创建一个临时顺序节点 Lock2。
Client2 查找 ParentLock 下面所有的临时顺序节点并排序，判断自己所创建的节点 Lock2 是不是顺序最靠前的一个，结果发现节点 Lock2 并不是最小的。
于是，Client2 向排序仅比它靠前的节点 Lock1 注册 Watcher，用于监听 Lock1 节点是否存在。这意味着 Client2 抢锁失败，进入了等待状态。
后面的依次类推，当第一个客户端使用完锁之后 ，监听它的那个客户端就会知道，它就会再去parentLock下查找所有的节点并判断自己是不是最前的节点，如果是就拿到锁，这样就会形成一个有序的等待队列，所以说zookeeper可以让临界资源有序的被访问，这就是zookeeper实现分布式锁的方式

zookeeper如何解决单点故障问题

为了解决单点故障问题，我们传统的方式是采用一个主节点和一个备用主节点的方式，即备用主节点会间断的给主节点发ping包 主节点也会间断的给备用主节点回ping包，但是如果由于网络原因主节回给备用主节点的包 备用主节点没有收到，它以为主节点挂了，自己就开始充当主节点了 此时就会出现双主问题，就会导致数据的紊乱，所以我们zookeeper来解决这个问题，zookeeper也叫服务注与发现中心，就是每个服务在启动的时候都会到这个中心去注册，然后这个中心就会去选举谁来成为主节点，成为主节点的就去当主节点，其他备用主节点全部成为阻塞状态，当出现相同网络问题的时候，我们会直接把主节点从服务列表中直接删掉，然后由这个中心继续选择主节点，那个被删除的主节点会重新向我们的注册中心注册成为备用主节点，然后依次循环这个过程就可以解决单点故障。

zookeeper怎么实现服务的注册与发现

zookeeper可以通过watcher通知机制来实现服务的注册与发现，对于集群部署的服务在启动的时候就会向zookeeper的服务端注册，就是把访问路径写到zookeeper的znode里面去，当用户去访问的时候先通过api网关去请求地址，也就是对应zookeeper服务端的watchTable里面的key 然后zookeeper会执行getData方法并携带watch参数监听着与key对应的value的那个服务，这个时候用户就能得到正常的响应，一旦key对应的那个value服务挂了，watcher可以监听到，所以zookeeper的服务端会第一时间删除那个服务对应的ip，因为是集群模式，zookeeper可以重新选举一个新的IP，然后在api网关中的zookeeper客户端也会异步收到服务端的通知 更新列表，这样就可以达到高可用的指标。

zookeeper是如何实现崩溃恢复的，它是怎么实现自身高可用

zookeeper本身一般也是主从模式部署的 在写数据的时候先写主节点（leader）,在同步到从节点，在读取数据时，直接读取任意从节点。假如zookeeper的当前主节点挂点了，集群就会进行崩溃恢复，分为以下几个阶段

1. 选举阶段，此时集群中的所有节点都处于looking状态，它们会各自向其他节点发起投票，投票当中包含自己服务器id和最新事物id,当一个节点获得一半以上的节点的投票的时候，这个节点就会成为准leader状态，其他节点变成follwing。
2. 发现阶段，用于在从节点当中发现最新的事物日志，然后leader更新自身的日志
3. 同步阶段，最后leader把最新的事物日志,同步给所有的following,当半数的following同步成功，它才成为真正的leader
   自此集群崩溃恢复成功

zookeeper如何实现数据同步

zookeeper的数据同步不是强一致性，也不是弱一致性，而是处于2者之间的顺序一致性，它依靠事物id和版本号，保证了数据的更新和读取是有序的
它的执行过程如下
1.客户端把写入数据请求发送给任意的follower
2.follwer把写入数据的请求转发给leader
3.leader采用2阶段提交的方式，先发送propose广播给follower
4.follower接收到广播之后，先写入日志就是已经执行但是还没提交，返回一个ack给leader
5.leader 接受到半数以上ack消息，广播commit请求给follwer， follwer开始提交