分布式协同服务-Zookeeper初识

• 分布式环境的特点
• 分布性
• 并发性
• 无序性

• 网络通信
• 网络分区
• 三态
• 分布式事务

• CAP理论
• BASE理论

• Zookeeper是什么
• Zookeeper能做什么
• Zookeeper的特性
• Zookeeper安装
• 单机安装
• 集群环境
• 集群中的角色
• 集群环境搭建

分布式环境的特点

什么是分布式架构？它是基于一个硬件或者多个硬件设备以及多个软件组成的分布在不同网络计算机的的一种系统架构，它们之间通信是通过消息传递进行的。在正式进入Zookeeper之前，我们先了解一下什么是分布式环境的特点。

分布性

严格上来说，分布式架构在空间上部署是可以任意的，可以部署在机房，也可以部署在单机上，甚至是不同的城市。也就是说，只要条件允许，任何一台网络计算机都可以部署分布式系统，也就是异地多活。

并发性

程序运行过程中，并发性操作很常见的。比如同一个分布式系统中的多个节点，同时去访问一个共享资源。像数据库，分布式存储等。

无序性

进程之间的通信是无序的。因为进程是随机分到的cpu时间，导致先请求并不一定先响应。

分布式环境下面临的问题

网络通信

网络本身的不可靠性，因此会设计到一些网络通信问题。

网络分区

当网络发生异常时，导致分布式系统中部分节点之间的网络延迟不断增大，最终导致组成分布式架构的所有节点，只有部分节点能够正常通信。网络分区也叫脑裂。

三态

一般的单机机构中，只有两种状态：成功和失败。而在分布式架构中，除了上诉两种状态之外，还有一个状态——超时态。

分布式事务

单机情况下解决ACID事务很好解决。利于Spring AOP做事务管理。然而，分布式环境下面临的事务则不是那么容易。需要借助第三方技术，这个后续进行展开。
ACID(原子性、一致性、隔离性、永久性)

中心化和去中心化

• 中心化：比如一个领导手下有5、6员工，其中一个员工病倒了，领导就叫其他员工接替他的工作，使工作任务顺利进行。
• 去中心化：如果领导病倒了，员工在手头工作完成的情况下没有收到新的任务安排，导致任务停滞不前。通常使用冷备或者热备来解决这个问题。在分布式架构里面，很多的架构思想采用的是：当集群发生故障时，集群中的人群会自动“选举”出一个新的领导。最典型的是：Zookeeper和etcd

经典的CAP/BASE理论

CAP理论

• C(一致性 Consistency):所有节点上的数据时刻保持一致
• A(可用性 Availability):每个请求都能够收到一个响应，无论是成功还是失败
• P(分区容错 Partition-tolerance):系统出现脑裂以后，可能导致某些server与集群中的其他机器失去联系

CAP理论原则指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），最多只能同时三个特性中的两个，三者不可兼得。因为网络的不可靠性，所以P一定存在。CA只存其一，CA或者CP。
CAP理论仅适用于原子读写的Nosql场景，不适用于数据库系统

BASE理论

基于CAP理论，CAP理论并不适用于数据库事务（因为更新一些错误的数据而导致数据出现紊乱，无论什么样的高可用方案都是徒劳），虽然XA事务（分布式事务解决方案）可以保证数据库在分布式系统下的ACID特性，但是会带来性能方面的影响；eBay尝试了一种完全不同的套路，放宽了对事务ACID的要求，提出了BASE理论。

• Basically available 基本可用性：数据库采用分片模式，把100w的用户数据分布在5个实例上。如果破坏了其中一个实例，仍然有80%的用户可用。
• soft-state 软状态：在基于client-server模式的系统中，server端是否有状态，决定了系统是否具备良好的水平扩展、负载均衡、故障恢复等特性。server端承诺会维护client端状态数据，这个状态仅仅维持一小段时间，过了这段时间以后，server端就会丢弃这个状态，恢复到正常状态。
• Eventually consitent 最终一致性 ：数据最终会一致。

Zookeeper初识

zookeeper是一个开源的分布式协调服务，是由雅虎创建的，基于Google chubby。

Zookeeper是什么

分布式数据一致性的解决方案

Zookeeper能做什么

数据的发布/订阅（配置中心：disconf(百度开源)）、负载均衡（dubbo利用了zookeeper机制实现负载均衡）、命名服务、master选举（kafka、Hadoop、hbase）、分布式队列、分布式锁…

Zookeeper的特性

• 顺序一致性：从同一个客户端发起事务请求，最终会严格按照顺序被应用到zookeeper中
• 原子性：所有的事务请求的处理结果在整个集群中的所有机器上的应用情况是一致的，也就是说，要么整个集群的所有机器都成功应用了某一事务，要么全部不应用
• 可靠性：一旦服务器成功应用了某一事务数据，并且对客户端做了响应，那么这个数据在整个集群中一定是同步并且保留下来的
• 实时性：一旦一个事务被成功应用，客户端就能够从服务器端读取到事务变更后的最新数据状态(zookeeper仅仅保证一定时间内，近实时)

Zookeeper安装

单机安装

1. 下载zookeeper的安装包
   http://apache.fayea.com/zookeeper/stable/zookeeper-3.4.10.tar.gz
2. 解压zookeeper
   tar -zxvf zookeeper-3.4.10.tar.gz
3. cd 到 ZK_HOME/conf , copy一份zoo.cfg
   cp zoo_sample.cfg zoo.cfg
4. 启动服务
   sh zkServer.sh {start|start-foreground|stop|restart|status|upgrade|print-cmd}
5. 启动客户端
   sh zkCli.sh -server ip:port 如:sh zkCli.sh -server localhost:2181 如下所示,则安装成功
   

集群环境

集群中的角色

三种角色：leader、follower、observer

• observer：observer 是一种特殊的zookeeper节点。可以帮助解决zookeeper的扩展性（如果大量客户端访问我们zookeeper集群，需要增加zookeeper集群机器数量。从而增加zookeeper集群的性能。 导致zookeeper写性能下降， zookeeper的数据变更需要半数以上服务器投票通过。造成网络消耗增加投票成本）
  1.observer不参与投票。 只接收投票结果。
  2.不属于zookeeper的关键部位。

集群环境搭建

1. 修改zoo.cfg文件
   在zoo.cfg文件末尾加上server.id=ip:port:port[:observer]，有多少个服务器加多少条记录

## server.id=ip:port:port[:observer]
##  1、2、3  ----> id
## 2881 ----> follower节点与leader节点交换信息的端口号，不能是zookeeper与客户端连接端口（默认是2181)
## 3181  ---->如果leader节点挂了，需要一个节点来重新选举
server.1=192.168.74.128:2881:3181
server.2=192.168.74.129:2881:3181
server.3=192.168.74.130:2881:3181

1. 在每台zookeeper服务器的dataDir目录下增加一个myid文件zoo.cfg中有一个dataDir(默认：dataDir=/tmp/zookeeper),在dataDir目录下增加一个myid文件 zoo.cfg中有一个dataDir(默认：dataDir=/tmp/zookeeper),在dataDir目录下增加一个myid文件zoo.cfg中有一个dataDir(默认：dataDir=/tmp/zookeeper),在dataDir目录下增加一个myid文件，文件内容是服务器sercer.id中的id。如192.168.74.128中，在/tmp/zookeeper/中建立一个myid文件，其内容是1
2. 启动服务

如果需要增加observe节点，只需在原来的配置上做两点修改【可以指定多个observer】

1. zoo.cfg中增加 peerType=observer
2. server.id=ip:port:port:observer

server.1=192.168.74.128:2881:3181
server.2=192.168.74.129:2881:3181
server.3=192.168.74.130:2881:3181
server.4=192.168.74.131:2881:3181:observer

zoo.cfg配置文件分析

• tickTime=2000 zookeeper中最小的时间单位长度 （ms）

• initLimit=10 follower节点启动后与leader节点完成数据同步的时间

• syncLimit=5 leader节点和follower节点进行心跳检测的最大延时时间

• dataDir=/tmp/zookeeper 表示zookeeper服务器存储快照文件的目录

• dataLogDir 表示配置 zookeeper事务日志的存储路径，默认指定在dataDir目录下

• clientPort 表示客户端和服务端建立连接的端口号： 2181

zookeeper中的一些概念

• 数据模型

zookeeper的数据模型和文件系统类似，每一个节点称为：znode. 是zookeeper中的最小数据单元。每一个znode上都可以
保存数据和挂载子节点。 从而构成一个层次化的属性结构节点特性

• 持久化节点 ： 节点创建后会一直存在zookeeper服务器上，直到主动删除

• 持久化有序节点 ：每个节点都会为它的一级子节点维护一个顺序

• 临时节点 ： 临时节点的生命周期和客户端的会话保持一致。当客户端会话失效，该节点自动清理

• 临时有序节点 ： 在临时节点上多勒一个顺序性特性

• 会话
  

1. Watcher
   zookeeper提供了分布式数据发布/订阅,zookeeper允许客户端向服务器注册一个watcher监听。当服务器端的节点触发指定事件的时候
   会触发watcher。服务端会向客户端发送一个事件通知
   watcher的通知是一次性，一旦触发一次通知后，该watcher就失效
2. ACL
   zookeeper提供控制节点访问权限的功能，用于有效的保证zookeeper中数据的安全性。避免误操作而导致系统出现重大事故。
   CREATE /READ/WRITE/DELETE/ADMIN

zookeeper的命令操作

1. create [-s] [-e] path data acl
   -s 表示节点是否有序
   -e 表示是否为临时节点
   默认情况下，是持久化节点
2. get path [watch]
   获得指定 path的信息
3. set path data [version]
   修改节点 path对应的data
   version 乐观锁的概念 数据库里面有一个 version 字段去控制数据行的版本号
4. delete path [version]
   删除节点

stat信息

cversion = 0 子节点的版本号
aclVersion = 0 表示acl的版本号，修改节点权限
dataVersion = 1 表示的是当前节点数据的版本号
czxid 节点被创建时的事务ID
mzxid 节点最后一次被更新的事务ID
pzxid 当前节点下的子节点最后一次被修改时的事务ID
ctime 创建时间
mtime 最后一次修改时间
ephemeralOwner = 0x0 创建临时节点的时候，会有一个sessionId 。 该值存储的就是这个sessionid
dataLength = 3 数据值长度
numChildren = 0 子节点数

• 点赞
• 收藏
• 分享
• 文章举报