第三（二）天：环境搭建
一、克隆三台服务器
1、克隆
须提前将要克隆的服务器关闭
2、修改主机名
临时修改：hostname hadoop02（修改后的主机名
永久修改：vim /etc/sysconfig/network
HOSTNAME=hadoop02
zookeeper集群最好是奇数个集群
3、固定ip
去掉选中的行，并将最后一行的eth1改为eth0
将选中的区域改为上面最后一行中的address，并删除uuid一行
setup配置地址
service network restart重启
二、配置免密登录
1、在每台服务器上生成公私钥：
ssh-keygen（然后一路回车即可）
2、将公钥远程注册给其他的服务器
ssh-copy-id 其他服务器的ip地址/主机名
对每一台均做如下操作
经验证：免密登录成功
访问其余主机：ssh + 其他服务器的ip地址/主机名
退出：exit
3、配置主机名和ip地址的映射
对每一个主机做如下操作
三、关闭防火墙
临时关闭 service iptables stop
永久关闭 chkconfig iptables off
对打开的三个主机一起执行关闭防火墙的操作，可以利用xShell的右下角中的标签，在下放输入命令，则三台机器都会执行
四、zookeeper集群配置
1、删除之前配置的伪分布式
进入/home/software执行rm -rf zookeeper-3.4.7
2、重新解压
3、拷贝模板文件起名为zoo.cfg并修改zoo.cfg
（1）修改dataDir属性
（2）并在文件末尾加上如下内容
2888：原子广播的端口
3888：选举的端口
注意：配置文件的等号的左右两端不能有空格
4、创建目录及文件
在zookeeper的安装目录创建一个tmp目录，并在tmp目录创建myid文件
myid文件中的内容
5、拷贝
将hadoop01中配置好的zookeeper复制到hadoop02与hadoop03中，并根据服务器的service好，配置myid编号
（1）删除原先存在的zookeeper
（2）复制
（3）修改编号
6、启动
hadoop01
hadoop02
hadoop03
如出错排查：先把进程停掉，环境变量，防火墙，配置文件，myid
启动日志：bin目录下的zookeeper.out
五、zookeeper选举机制
（一）概述
1、当一个zookeeper集群在启动的时候，会进入选举状态，此时所有的节点（服务器）都会推荐自己当leader。并且会把自己的选举信息发送给其它节点
2、当节点收到其他节点发送过来的选举信息之后，会两两进行比较，最后胜出的节点当leader
（二）细节
1、选举信息包括：
a. 当前节点的最大事务id
b. 选举编号，即myid
c. 逻辑始终值-保证选举的轮数
2、比较原则
a. 先比较最大事务id，谁大谁赢
b. 如果事务id一样的话，比较myid，谁大谁赢
c. 如果一个节点胜过了一半以上的节点，那么这个节点就是leader–过半性
3、在zookeeper中，不存在单点故障的说法，如果leader宕机，那么整个集群会选举一个新的leader继续对外提供服务
4、如果leader宕机之后重新启动，这个时候会看作一个新的节点加入集群，此时这个节点一定是follower
5、如果一个集群已经选举出来leader，为了维持集群的稳定性，无论新添加的节点的事务id和myid是多少，都不会触发leader的重新选举，新加的节点只能是follower
6、如果一个集群出现多个leader，这种现象叫做脑裂
7、zookeeper出现脑裂的条件是：
a. 集群产生分裂
b. 分裂后产生了选举
8、在zookeeper中如果存活的节点（可以相互通信的服务器）不足一半，则这些节点不会发生选举。此时这些节点也不会对外提供服务–过半服务的特性
9、zookeeper会给每一次选举出来的leader分配一个全局的递增的编号，称之为epochid，当zookeeper发现存在多个leader时，会自动将epochid较小的节点的状态切换成follower，利用这种方案可以保证整个集群只存在唯一的leader
10、集群中节点的状态
a. Looking/voting：选举状态
b. Follower：追随者
c. leader：领导者
d. observer：观察者
六、ZAB协议
（一）概述
1、ZAB（zookeeper Atomic Broadcast）协议专门为zookeeper设计的用于进行原子广播和崩溃恢复的一套协议
2、ZAB协议是基于2PC算法设计实现的。利用了过半性+PAXOS进行了改造
（二）原子广播
1、作用：保证集群中各个节点之间的数据是一致的，即访问任意一个节点，获取到的数据都是相同的
2、基于2PC算法设计实现的
3、2PC-two Phase Commi-两阶段提交算法，顾名思义，讲一个请求拆分成两个阶段
a. 请求阶段
b. 提交阶段：如果协调者收到所有参与者返回的yes，那么认为这个请求可以执行，那么就会命令所有的参与者执行这个请求
c. 终止阶段，只要协调者没有收到所有参与者返回的yes，那么就会认为这个请求无法执行，也就要求所有的参与者放弃刚才的请求。
4、在2PC算法中，要么就是请求执行，要么就是请求中止
5、2PC算法的思想就是"一票否决"
6、2PC算法很容易理解，并且实现也很容易，但在分布式环境中，2PC算法的成功率很低。效率也很低，在2PC算法中引入了PAXOS算法（过半性）的原来进行改进
7、原子广播的过程
follower不处理请求，而是将所有请求转交给leader进行处理——>当leader接收到请求后，会将请求记录到本地的日志中（log.xxx)，如果记录成功，leader就会将请求放到队列中发送给follower——>follower收到队列后，会将请求从队列中取出，然后试图记录到本地的日志中。——>如果记录成功，则follower就会认为可以执行这个请求，并且返回给leader一个yes；如果记录失败，则followerr会认为这个请求不能执行，并且返回给leader一个no——>如果leader收到半数以上的节点返回的yes，则会认为这个请求可以执行，就会命令这些follower执行这个请求；半数以上的no，则会任务这个请求不能执行，通知所有的follower删除刚才的记录
8、follower存在记录日志失败的可能，例如，文件被占用、磁盘损坏、磁盘已满。都可能导致日志文件记录失败，这种情况不是zookeeper的原因，zookeeper无法解决
9、
（三）崩溃恢复
1、当leader宕机之后，整个集群并不会就此停止工作，而是会选举出来一个新的leader，继续对外提供服务
2、在zookeeper集群中，会对每一个选举出来的leader分配一个全局递增的唯一的编号，称之为epochid，当leader被选举出来之后，这个leader就会将epochid分发给每一个follower。follower收到这个id之后，就会将这个id存储在acceptedEpoch文件中
3、作用：避免单点故障
4、如果follower记录失败，那么当follower修复成功之后，会给leader发送请求，发送请求的过程中会将自身的事务id告诉leader，leader收到请求之后，如果事务id一样，说明在follower出现问题的时候，leader没有做过任何的事务操作。leader的事务id大于follower的事务id，这个时候leader会将差的事务请求放到队列中发送给follower。要求follower补齐事务。在follower没有补齐事务之前不对外提供服务
（四）观察者
概述
1、observer在zookeeper集群中既不参见选举也不参加投票，但是会监听投票的结果和选举的结果，
2、observer大致可以理解为没有选举权和投票权的follower。–只有干活的义务没有选举的权利
3、在实际开发过程中，若集群规模较大（节点比较多）的时候，或者网络环境比较差的时候。我们将一个集群中90%-97%的节点设置为observer
在集群规模较大的时候，由于信号丢失会造成选举无效（不过半（设置的总数）），如果出现上述情况，选举的效率就比较低；集群规模较大的时候，网络因素不确定。如果导致选举无效的话，就会触发新一轮的选举。效率非常低下
设置为observer
4、配置observer
a. 修改zoo.cfg
i 添加peerType=observer
ii 在要设置为observer的主机后面添加：observer
（五）特征
1、过半性：过半选举、过半存过、过半操作
2、数据一致性：从任意节点获取数据，拿到的数据都是一样的
3、原子性：一个操作要么所有的节点均成功，要么均失败
4、顺序性：所有节点获取到的请求顺序都是一致的–队列
5、可靠性：崩溃恢复
补充：（需先安装nc）
1、查看节点是否宕机：echo ruok|nc hadoop01 2181
2、查看节点状态：echo stat|nc hadoop01 2181
3、查看节点的配置信息：echo conf|nc hadoop01 2181
安装nc-1.84…
首先将nc放入/home/software下
执行安装命令
具体操作
七、分布式一致性算法-Paxos
没有具体的公式，只是一个思想，见ppt
八、查看日志（不是乱码状态）
复制两个包到/tmp/version-2下
使用如下命令查看
