9重新认识Zookeeper：
Apache ZooKeeper 是一个高可靠的分布式协调中间件。由雅虎公司依据 Google Chubby 的一个开源 实现，后来捐献给了Apache；zookeepeer用来解决分布式一致性问题，简单来说，就是在一个分布式系统中，有多个节点，每个节点 都会提出一个请求，但是在所有节点中只能确定一个请求被通过。而这个通过是需要所有节 点达成一致的结果，所以所谓的一致性就是在提出的所有请求中能够选出最终一个确定请求。 并且这个请求选出来以后，所有的节点都要知道并且通过（这个就是典型的拜占庭将军问题）总之分布式系统可以基于 ZooKeeper 实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、配置维护，名字服务、分布式同步、分布式锁和分布式队列等功能。
Zookeeper 的设计思想：
1.单点故障：
在分布式系统架构中，任何的节点都不能以单点的方式存在，因此我们需要解决单点的问 题。常见的解决单点问题的方式就是集群；
⑴.集群中要有主节点和从节点(也就是集群要有角色)
⑵.集群要能做到数据同步，当主节点出现故障时，从节点能够顶替主节点继续工作，但是继 续工作的前提是数据必须要主节点保持一致；
⑶.主节点挂了以后，从节点如何接替成为主节点? 是人工干预?还是自动选举 ；
Leader 角色
Leader 服务器是整个 zookeeper 集群的核心，主要的工作任务有两项：
⑴. 事务请求的唯一调度和处理者，保证集群事务处理的顺序性
⑵. 集群内部各服务器的调度者
Follower 角色
Follower 角色的主要职责是：
⑴. 处理客户端非事务请求、转发事务请求给leader服务器
⑵. 参与事物请求 Proposal 的投票(需要半数以上服务器通过才能通知 leader commit 数据; Leader 发起的选举方案，要求 Follower 投票)
⑶. 参与 Leader 选举的投票
Observer 角色
Observer 是 zookeeper3.3 开始引入的一个全新的服务器角色，从字面来理解，该角色充当 了观察者的角色。观察 zookeeper 集群中的最新状态变化并将这些状态变化同步到 observer 服务器上。Observer 的工作原理与 follower 角色基本一致，而它和 follower 角色唯一的不同在于observer 不参与任何形式的投票，包括事物请求 Proposal 的投票和 leader 选举的投票。简 单来说，observer 服务器只提供非事物请求服务，通常在于不影响集群事物处理能力的前提 下提升集群非事物处理的能力
2.数据同步：
leader节点操作事务请求
如果要满足这样的一个高性能集群，我们最直观的想法应该是， 每个节点都能接收到请求，并且每个节点的数据都必须要保持一致。要实现各个节点的数据 一致性，就势必要一个 leader 节点负责协调和数据同步操作。这个我想大家都知道，如果在 这样一个集群中没有 leader 节点，每个节点都可以接收所有请求，那么这个集群的数据同步 的复杂度是非常大，所以，当客户端请求过来时，需要满足，事务型数据和非事务型数据的分开处理方式，就是leader 节点可以处理事务和非事务型数据。而 follower 节点只能处理非事务型数据。原因是， 对于数据变更的操作，应该由一个节点来维护，使得集群数据处理的简化。同时数据需要能 够通过 leader 进行分发使得数据在集群中各个节点的一致性。
分布式事务
leader 节点如何和其他节点保证数据一致性，并且要求是强一致的。在分布式系统架构中，每一 个机器节点虽然都能够明确知道自己进行的事务操作过程是成功和失败，但是却无法直接获 取其他分布式节点的操作结果。所以当一个事务操作涉及到跨节点的时候，就需要用到分布 式事务，分布式事务的数据一致性协议有 2PC 协议和 3PC 协议
当一个事务操作需要跨越多个分布式节点的时候，为了保持事务处理的 ACID 特性，就需要引入一个“协调者”(TM)来统一调度所有分布式节点 的执行逻辑，这些被调度的分布式节点被称为 AP。TM 负责调度 AP 的行为，并最终决定这 些 AP 是否要把事务真正进行提交;因为整个事务是分为两个阶段提交，所以叫 2pc 执行流程如图：
此处发关于分布式事务，大家简单理解下就好，后面我会针对分布式事务做单独的讲解
集群组成
通常 zookeeper 是由 2n+1 台 server 组成，每个 server 都知道彼此的存在。每个 server 都 维护的内存状态镜像以及持久化存储的事务日志和快照。对于 2n+1 台 server，只要有 n+1台(大多数)server 可用，整个系统保持可用。我们已经了解到，一个 zookeeper 集群如果 要对外提供可用的服务，那么集群中必须要有过半的机器正常工作并且彼此之间能够正常通 信，因此 3 台机器构成的 zookeeper 集群，能够在挂掉一台 机器后依然正常工作。一个 5 台机器集群的服务，能够对 2 台机器挂掉的情况下进行容灾。 如果一台由 6 台服务构成的集群，同样只能挂掉 2 台机器。因此，5 台和 6 台在容灾能力上 并没有明显优势，反而增加了网络通信负担。系统启动时，集群中的 server 会选举出一台server 为 Leader，其它的就作为 follower，observer不参与选举投票，投票超过半数的follower成为leader节点。
Zookeeper集群安装及部署
zookeeper 有两种运行模式:集群模式和单机模式。
下载 zookeeper
zookeeper 安装包:Zookeeper官网下载 ，下载完成后
通过 tar zxvf apache-zookeeper-3.5.5-bin.tar.gz 解压压缩包
单机模式
初次使用 zookeeper，需要将 conf 目录下的 zoo_sample.cfg 文件 copy 一份重命名为 zoo.cfg
#1.进入配置文件夹目录
cd apache-zookeeper-3.5.5-bin/conf/
#2.复制一份自带的配置文件，改名为zoo.cfg，启动默认使用这个配置文件
cp zoo_sample.cfg zoo.cfg
#3.修改dataDir
dataDir=/root/apache-zookeeper-3.5.5-bin/data
#4.创建dataLogDir
dataLogDir=/root/apache-zookeeper-3.5.5-bin/logs
#5.然后再apache-zookeeper-3.5.5-bin/目录下创建data和logs文件夹
mkdir data
mkdir logs
#6.进入bin文件夹 启动zkServer.sh
bin/zkServer.sh start
集群模式
1.虚拟机集群：
虚拟机上搭建的集群相对比较简单，大家参考虚拟机集群搭建这个链接就好，里面介绍的特别细致， 这里我主要还是要说下载真实云服务器上搭建Zookeeper集群，个人认为和虚拟机上区别还是挺大的
2.云服务器搭建真实集群
在本文中单机模式的zoo.cfg配置文件的操作基础上，在zoo.cfg文件的尾部配置
server.1=0.0.0.0:2888:3888
server.2=39.105.162.160:2888:3888
server.3=39.105.163.224:2888:3888
此处为笔者的服务器ip为例 特别注意 0.0.0.0代替的是本机外网ip
其他俩台机器的zoo.cfg配置依次为：
server.1=47.93.37.94:2888:3888
server.2=0.0.0.0:2888:3888
server.3=39.105.163.224:2888:3888
server.1=47.93.37.94:2888:3888
server.4=39.105.162.160:2888:3888
server.3=0.0.0.0:2888:3888
按照如图一次配置3888和 2888端口的出入方向规则，然后重启服务器，三台云服务器重复同样的操作
接着进入data文件夹中创建myid
cd data
vi myid
# 在文件中输入1
***myid中的数字要和zoo.cfg文件中的 server.x所对应
第二台机器就把myid改为2，机器端口就对应server.2=当前机器ip:2888:3888
第三台机器就把myid改为3，机器端口就对应server.3=当前机器ip:2888:3888
接着修改profile文件
vi /etc/profile
按照如图下面配置在文件底部加入如下配置：
# zookeeper
export ZOOKEEPER_HOME=/usr/local/apache-zookeeper-3.5.5-bin
export PATH=$PATH:$ZOOKEEPER_HOME/bin
最后进入bin文件夹 ，依次启动三台服务器的zookeeper
sh zkServer.sh start
执行
#查看zookeeper状态
sh zkServer.sh status
如图 该服务器为跟随者节点
这是我的第一篇关于zookeeper的文章，后续还会总结更多zookeeper更深入的认识及理解，请大家关注，留下宝贵的手印