zookeeper集群搭建及其一致性原理

源于蚂蚁课堂的学习，点击这里查看（老余很给力）

集群环境搭建

1.修改每台zk集群节点 zoo.cfg 文件 vi zoo.cfg
server.1=192.168.212.147:2888:3888
server.2=192.168.212.154:2888:3888
server.3=192.168.212.155:2888:3888

2.修改data目录myid 分别为1,2,3
Id的取值范围1-255

注意：需要关闭每台节点防火墙systemctl stop firewalld

过半机制

zookeeper集群中用的最多的一个机制就是过半机制。
所谓过半，就是结果为正的数目超过总数的一半，则输出结果
如：leader的选举，集群节点的可用，一致性的同步等

 集群中的角色

ZK集群中大致分为三种角色：
leader：领导者，负责整个集群中写的操作，一个集群中只会出现一个leader角色，可参与选举。
follower：跟随者，负责集群中读的操作，当leader节点宕机后，开始进行选举投票。
observer：观察者，负责集群中读的操作，功能近似follower，只能不能参与选举。


当有写的请求发送至follower或observer时，该节点会将此请求转发至leader进行写，之后再进行节点间数据的同步。

数据一致性策略

所有节点都有一个myid文件和zxid文件。
总所周知，leader节点用领导者，其性能一定要优于平均节点的性能才行，但是服务器性能程序不得而知。
故，需要我们人工指定服务器的性能，那么我们就在当前服务器节点的zk中加入myid文件，其值越大，性能越高。
但同一集群中，myid不可重复，因为选举时会比较这个值。

zxid则代表当前ZK节点参与数据变更的次数，是一个自增长的值，值越大，参与数据变更越多，也意味着当前ZK节点
越接近真实情况。


当leader进行写的操作后，会将zxid自增，且将其代为参数，通过发布订阅的方式，通知其集群的follower和observer。
follower和observer收到通知会判断当前自身节点是否可以做数据同步，将结果一一返回至leader。leader收到各自
节点信息后，统计可以同步节点的数量>总集群数/2 ，则进行数据同步，否则，进行延时重试。

也就是所谓的最终一致性。

 ZK选举策略

选举依照过半机制。
集群中所有的非observer节点都会参与，举个例子，有五台ZK做集群，myid分别为1~5。按照顺序启动。
当节点1启动时，发现整个集群只有自己，所以把票投给自己，此时集群还不可用（活跃节点数为过半）。
节点2启动，则节点1和节点2会把票都重新投给节点2，此时集群不可用。
节点3启动，按上原理，它持有3票，票数过半，则当选为leader角色，此时集群已经可以使用了。
之后的节点4和5启动后，即使其myid大于节点3，也只能充当follower角色。

当leader宕机后，会先从集群中选出zxid最大的节点，表明这些节点数据最解决真实。再依照其myid去选举性能最好
的节点当选新的leader。


有几个概念可以了解一下：
选举概念
Myid:服务节点上的id
Zxid：服务器事务id，数据越新，zxid越来大
epoch：逻辑时钟，在服务端是一个自增序列，每次进入下一轮投票后，就会加1；

server状态：
Looking（选举状态）
Leading（领导者状态，表明当前server是leader）
Following（跟随者状态，表明当前server是Follower）
Observing（观察者状态、表明当前server是Observer）

 ZKClinet连接集群 

    //参数1 连接地址
    private static final String ADDRES = "192.168.212.130:2181,192.168.212.152:2181,192.168.212.153:2181";
    // 参数2 zk超时时间
    private static final int TIMEOUT = 5000;

    public static void main(String[] args) {
        ZkClient zkClient = new ZkClient(ADDRES, TIMEOUT);
        String path = "/data";
        zkClient.createPersistent(path);
        zkClient.close();
    }

 总结 

1.ZK官网建议集群节点数为奇数。
    集群可用的过半机制导致。
    举个例子，5台服务器允许ZK集群宕机的服务器个数是2台；6台服务器也是允许2台宕机，故为节约成本，奇数最好。

2.Observer的使用
    当集群节点数量庞大时，leader宕机会导致其集群节点选举时间太长，导致zk不可用的现象，故参与选举的节点
不易太多，所以引入observer类型的节点

3.网络分区(脑裂)
    在集群的情况下，一般只会选举一个master节点、其他都是为从节点，那么如果发生了网络抖动或者部分节点相互
无法通讯那么就会导致部分节点从新选举，这样就会存在多个master节点；

4.CAP概念
① C：Consistency 在分布式系统中的所有数据备份，在同一时刻是否同样的值。等同于所有节点访问同一份最新的数据副本
② A：Availability，在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求
③ P：Partition tolerance 在分布式系统中网络分区存在脑裂问题以后，部分server与集群其他节点失去联系 无法组成一个群体； 该问题一定是存在的~~~

目前我们当前技术环境下，不能同时满足CA，但是可以满足CP或者AP

Eureka与Zookeeper区别 

相同点：
Eureka和Zookeeper都可以实现微服务注册中心；

首先在这时候要明白一点：
服务注册中心，可以短暂读取以前服务注册列表信息，但是不可以接受节点宕机不可用；

不同点：
Zookeeper保证CP(一致性和分区容错) 当ZK在某种情况下出现宕机，会重新实现ZK选举新的领导者，
如果zk选举的新的领导者时间过长，或者投票没有过半数，那么会导致整个zk集群节点不可用的，
即服务注册中心不可用 ，所以Zk必须要保证数据一致性问题；

Eureka保证AP,设计时优先考虑可用性，完全去中心化的设计思想，每个节点都均等；没有主从区分，
几个节点挂掉了也不会影响正常的Eureka使用，Eureka客户端在连接时发现连接不可用会自动切换其他连接，
只要Eureka有一个节点存在也就可以保证Eureka整个服务注册中心的使用；

Zk保证数据一致性问题，Eureka保证可用性；