大数据学习06之Zookeeper

1.集群与分布式

集群 ：将一个任务部署到多个服务器中，每个服务器都能独立完成该任务。（全能）

分布式：将一个任务的不同部分分派给不同的服务器完成，即划分子任务交给节点完成（专精）

2.CAP原则

C---Consistency 一致性，让不同节点存储的数据保持一致，即相同

A---Availability 可用性，访问即可用

P---Partition 分区容错性，故障时保证基本服务可用，仍然能够对外提供满足一致性和可用性的 服务，除非整个网络环境都发生了故障。这里可以理解为是否可以对数据进行分区，这是考虑到性能 和可伸缩性。

2.1 取舍策略

CA:保证一致性和可读性，分区性受损，无法扩张节点

CP:保证一致性和分区性，保证一致性时需要同步节点，从而要停止用户访问，可读性受损

AP:保证可读性和分区性，不同节点间的数据会有不同的情况出现，一致性受损

2.2 总结

现如今，对于多数大型互联网应用，主机众多、部署分散，而且现在的集群规模越来越大，节点只会越来越多，所以 节点故障、网络故障是常态，因此分区容错性也就成为了一个分布式系统必然要面对的问题。那么就只能在 C 和 A 之间进 行取舍。但对于传统的项目就可能有所不同，拿银行的转账系统来说，涉及到金钱的对于数据一致性不能做出一丝的让 步，C 必须保证，出现网络故障的话，宁可停止服务。而互联网非金融项目普遍都是基于 AP 模式。

总而言之，没有最好的策略，好的系统应该是根据业务场景来进行架构设计的，只有适合的才是最好的。

2.3 BASE理论

BA---Base Available---基本可用

S ---Soft state---软状态

E ---Eventually consistent---最终一致性

核心思想：无法做到强一致性，那就使系统最终一致性，允许短时间内的非一致性可以被访问，软状态---弱一致性。

2.3.1 BA---Base Available基本可用

基本可用是指分布式系统在出现故障的时候，允许损失部分可用性（例如响应时间、功能上的可用性）。需要注意的 是，基本可用绝不等价于系统不可用。 ​ 响应时间上的损失：正常情况下搜索引擎需要在 0.5 秒之内返回给用户相应的查询结果，但由于出现故障（比如系统 部分机房发生断电或断网故障），查询结果的响应时间增加到了 1~2 秒。 ​ 功能上的损失：购物网站在购物高峰（如双十一）时，为了保护系统的稳定性，部分消费者可能会被引导到一个降级 页面。

2.3.2 Soft state---软状态

什么是软状态呢？相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种 “硬状态”。 ​ 软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据会有多个副 本，允许不同副本数据同步的延时就是软状态的体现。

2.3.3 Eventually consistent---最终一致性

系统不可能一直是软状态，必须有个时间期限。在期限过后，应当保证所有副本保持数据一致性。从而达到数据的最终一致性。这个时间期限取决于网络延时，系统负载，数据复制方案设计等等因素。 ​ 实际上，不只是分布式系统使用最终一致性，关系型数据库在某个功能上，也是使用最终一致性的，比如备份，数据 库的复制都是需要时间的，这个复制过程中，业务读取到的值就是旧值。当然，最终还是达成了数据一致性。这也算是一 个最终一致性的经典案例。

2.3.4 总结

总的来说，BASE 理论面向的是大型高可用可扩展的分布式系统，和传统事务的 ACID 是相反的，它完全不同于 ACID 的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间是不一致的。

3. 数据的一致性

3.1 定义

复制是导致出现数据一致性问题的唯一原因，因为单节点系统很容易就可以达成一致性，而一些分布式系统通过复制 数据来提高系统的可靠性和容错性，将数据的不同的副本存放在不同的机器，这样的多节点系统一致性就成为了问题。 ​ 在数据有多份副本的情况下，如果网络、服务器或者软件出现故障，会导致部分副本写入成功，部分副本写入失败。 这就造成各个副本之间的数据不一致，数据内容冲突。应用系统需要对分布式数据处理系统的数据不一致性有所了解并进 行某种意义上的补偿和纠错，以避免出现应用系统数据不正确。

3.2 模型

强一致性：要求所有服务器的数据时时刻刻保持一致

弱一致性：数据一致的服务器超过半数以上，就可以被认为是软一致性。

4.Paxos算法

4.1简介

Paxos算法是Leslie Lamport宗师提出的一种基于消息传递的分布式一致性算法，使其获得2013年图灵奖。 ​ Paxos在1990年提出，被广泛应用于分布式计算中，Google的Chubby，Apache的Zookeeper都是基于它的理论来实现的 ​ Paxos算法解决的问题是分布式一致性问题，即一个分布式系统中的各个进程如何就某个值（决议）达成一致。 ​ 传统节点间通信存在着两种通讯模型：共享内存（Shared memory）、消息传递（Messages passing），Paxos是一个 基于消息传递的一致性算法。

4.2 算法描述

Paxos 描述了这样一个场景：

• 有一个叫做 Paxos 的小岛(Island)上面住了一批居民(Islander)；
• 岛上面所有的事情由一些特殊的人决定，他们叫做议员(Senator)；
• 议员的总数(Senator Count)是确定的，不能更改；
• 岛上每次环境事务的变更都需要通过一个提议(Proposal)，每个提议都有一个编号(PID)，这个编号是一直增长的，不能倒 退；
• 每个提议都需要超过半数((Senator Count)/2 +1)的议员同意才能生效(少数服从多数)；
• 每个议员只会同意大于当前编号的提议，包括已生效的和未生效的；
• 如果议员收到小于等于当前编号的提议，他会拒绝，并告知对方：你的提议已经有人提过了。这里的当前编号是每个议员在 自己记事本上记录的编号，他会不断更新这个编号；
• 整个议会不能保证所有议员记事本上的编号总是相同的；
• 现在议会有一个目标：保证所有的议员对于提议都能达成一致的看法。 现在议会开始运作，所有议员一开始记事本上面记录的编号都是0。有一个议员发了一个提议：将电费设定为1元/度。他首先看 了一下记事本，嗯，当前提议编号是0，那么我的这个提议的编号就是1，于是他给所有议员发消息：1号提议，设定电费1元/ 度。其他议员收到消息以后查了一下记事本，哦，当前提议编号是0，这个提议可接受，于是他记录下这个提议并回复：我接受 你的1号提议，同时他在记事本上记录：当前提议编号为1。发起提议的议员收到了超过半数的回复，立即给所有人发通知：1号 提议生效！收到的议员会修改他的记事本，将1好提议由记录改成正式的法令，当有人问他电费为多少时，他会查看法令并告诉 对方：1元/度。 再看冲突的解决：假设总共有三个议员S1-S3，S1和S2同时发起了一个提议:1号提议，设定电费。S1想设为1元/度, S2想设为 2元/度。结果S3先收到了S1的提议，于是他做了和前面同样的操作。紧接着他又收到了S2的提议，结果他一查记事本，咦，这 个提议的编号小于等于我的当前编号1，于是他拒绝了这个提议：对不起，这个提议先前提过了。于是S2的提议被拒绝，S1正式 发布了提议: 1号提议生效。S2向S1或者S3打听并更新了1号法令的内容，然后他可以选择继续发起2号提议。

4.3 Paxos推断

小岛(Island) 服务器集群 议员(Senator) 单台服务器 议员的总数(Senator Count)是确定的 提议(Proposal) 每一次对集群中的数据进行修改 每个提议都有一个编号(PID)，这个编号是一直增长的 每个提议都需要超过半数((Senator Count)/2 +1)的议员同意才能生效 每个议员只会同意大于当前编号的提议 每个议员在自己记事本上面记录的编号，他不断更新这个编号 整个议会不能保证所有议员记事本上的编号总是相同的 议会有一个目标：保证所有的议员对于提议都能达成一致的看法。 前期投票(>1/2)，后期广播(all) Paxos算法 数据的全量备份 弱一致性 => 最终一致性

4.4 算法模型延伸

如果Paxos岛上的议员人人平等，在某种情况下会由于提议的冲突而产生一个“活锁”（所谓活锁我的理解是大家都没有死，都在 动，但是一直解决不了冲突问题）。Paxos的作者在所有议员中设立一个总统，只有总统有权发出提议，如果议员有自己的提 议，必须发给总统并由总统来提出。 情况一：屁民甲(Client)到某个议员(ZK Server)那里询问(Get)某条法令的情况(ZNode的数据)，议员毫不犹豫的拿出他的 记事本(local storage)，查阅法令并告诉他结果，同时声明：我的数据不一定是最新的。你想要最新的数据？没问题，等 着，等我找总统Sync一下再告诉你。 情况二：屁民乙(Client)到某个议员(ZK Server)那里要求政府归还欠他的一万元钱，议员让他在办公室等着，自己将问题反 映给了总统，总统询问所有议员的意见，多数议员表示欠屁民的钱一定要还，于是总统发表声明，从国库中拿出一万元还债， 国库总资产由100万变成99万。屁民乙拿到钱回去了(Client函数返回)。 情况三：总统突然挂了，议员接二连三的发现联系不上总统，于是各自发表声明，推选新的总统，总统大选期间政府停业，拒 绝屁民的请求。

无主集群模型 人人都会发送指令,投票 投票人数有可能导致分区(分不同阵营)， 6个节点 33对立 类似于以前党争 事务编号混乱，每个节点都有可能有自己的提议 提议的编号不能重复和小于

有主集群模型 只能有一个主发送指令，发送提议 单主会单点故障，肯定有备用的方案 重新选举，议员会把票投给数字编号和事务编号都大于自己的议员 数字编号（议员 ID，ZooKeeper 中叫 myid）：为了快速选出总统 事务编号（会议 ID，ZooKeeper 中叫 ZXID）：为了确定谁的数据是最全的 选主过程：先比较 ZXID，如果 ZXID 相同再比较 myid 如果存在多个主就会脑裂 过半原则：选主过程中，如果某个议员获得了超过半数的选票，才可以成为主 议员同步数据只需要从主节点同步 节点越多业务能力越强，但是选举速度也会越慢 减少参与选举和投票的人数（例如 ZooKeeper 的 Observer） 主要集群中节点数目高于1/2+1，集群就可以正常运行

5.Raft算法

后续补充

6.ZAB协议

7.ZooKeeper集群配置

7.1 node1

先在 node01 机器上执行以下操作。 解压。

server.1 中的 1 是 myid 文件中的内容，2888 用于集群内部通信，3888 用于选举 Leader。

7.2 node02/node03

7.3 node01/02/03

7.4 环境遍历

7.5 Zookeeper一键启停

#!/bin/bash
user=$(whoami)
case $1 in
"start")
for i in node01 node02 node03
do
echo -e "\e[1;34m==================== $i ZooKeeper 启动 ====================\e[0m"
ssh $user@$i "/opt/apache-zookeeper-3.6.3-bin/bin/zkServer.sh start"
done
;;
"stop")
for i in node01 node02 node03
do
echo -e "\e[1;34m==================== $i ZooKeeper 停止 ====================\e[0m"
ssh $user@$i "/opt/apache-zookeeper-3.6.3-bin/bin/zkServer.sh stop"
done
;;
"status")
for i in node01 node02 node03
do
echo -e "\e[1;34m==================== $i ZooKeeper 状态 ====================\e[0m"
ssh $user@$i "/opt/apache-zookeeper-3.6.3-bin/bin/zkServer.sh status"
done
;;
"restart")
for i in node01 node02 node03
do
echo -e "\e[1;34m==================== $i ZooKeeper 重启 ====================\e[0m"
ssh $user@$i "/opt/apache-zookeeper-3.6.3-bin/bin/zkServer.sh restart"
done
;;
esac

8.Zookeeper存储模型

8.1 存储结构

树状结构

键值对

绝对路径方式呈现

8.2 节点分类

持久化节点

create /java

临时节点

cteate -e /java

序列化节点

cteate -s /java

9.Zookeeper监听机制