分布式协调服务-zookeeper
分布式环境的特点
1.分布性
2.并发性
程序运行过程中，并发性操作是很常见的。比如同一个分布式系统中的多个节点，同时访问一个共享资源。数据库、分布式存储
3.无序性
进程之间的消息通信，会出现顺序不一致问题
分布式环境下面临的问题
网络通信
网络本身的不可靠性，因此会涉及到一些网络通信问题
网络分区(脑裂)
当网络发生异常导致分布式系统中部分节点之间的网络延时不断增大，最终导致组成分布式架构的所有节点，只有部分节点能够正常通信
三态
在分布式架构里面，除了成功、失败、超时
分布式事务
ACID(原子性、一致性、隔离性、持久性)
中心化和去中心化
冷备或者热备
分布式架构里面，很多的架构思想采用的是：当集群发生故障的时候，集群中的人群会自动“选举”出一个新的领导。
最典型的是： zookeeper / etcd
经典的CAP/BASE理论
CAP
C（一致性 Consistency）: 所有节点上的数据，时刻保持一致
可用性（Availability）：每个请求都能够收到一个响应，无论响应成功或者失败
分区容错 （Partition-tolerance）：表示系统出现脑裂以后，可能导致某些server与集群中的其他机器失去联系
CP / AP
CAP理论仅适用于原子读写的Nosql场景，不适用于数据库系统
BASE
基于CAP理论，CAP理论并不适用于数据库事务（因为更新一些错误的数据而导致数据出现紊乱，无论什么样的数据库高可用方案都是
徒劳） ，虽然XA事务可以保证数据库在分布式系统下的ACID特性，但是会带来性能方面的影响；
eBay尝试了一种完全不同的套路，放宽了对事务ACID的要求。提出了BASE理论
Basically available ： 数据库采用分片模式， 把100W的用户数据分布在5个实例上。如果破坏了其中一个实例，仍然可以保证
80%的用户可用
soft-state： 在基于client-server模式的系统中，server端是否有状态，决定了系统是否具备良好的水平扩展、负载均衡、故障恢复等特性。
Server端承诺会维护client端状态数据，这个状态仅仅维持一小段时间, 这段时间以后，server端就会丢弃这个状态，恢复正常状态
Eventually consistent：数据的最终一致性
初步认识zookeeper
zookeeper是一个开源的分布式协调服务，是由雅虎创建的，基于google chubby。
zookeeper是什么
分布式数据一致性的解决方案
zookeeper能做什么
数据的发布/订阅（配置中心:disconf） 、 负载均衡（dubbo利用了zookeeper机制实现负载均衡） 、命名服务、
master选举(kafka、hadoop、hbase)、分布式队列、分布式锁
zookeeper的特性
顺序一致性
从同一个客户端发起的事务请求，最终会严格按照顺序被应用到zookeeper中
原子性
所有的事务请求的处理结果在整个集群中的所有机器上的应用情况是一致的，也就是说，要么整个集群中的所有机器都成功应用了某一事务、
要么全都不应用
可靠性
一旦服务器成功应用了某一个事务数据，并且对客户端做了响应，那么这个数据在整个集群中一定是同步并且保留下来的
实时性
一旦一个事务被成功应用，客户端就能够立即从服务器端读取到事务变更后的最新数据状态；（zookeeper仅仅保证在一定时间内，近实时）
zookeeper安装
单机环境安装
- 下载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
集群的搭建
- 修改zoo.cfg
129/135/136
server.id=ip:port:port
server.1=192.168.30.129:2888:3181 2888表示follower节点与leader节点交换信息的端口号 3181 如果leader节点挂掉了, 需要一个端口来重新选举。
server.2=192.168.30.135:2888:3181
server.3=192.168.30.136:2888:3181
- zoo.cfg中有一个dataDir = /tmp/zookeeper
$dataDir/myid 添加一个myid文件。
- 启动服务
如果需要增加observer节点
zoo.cfg中 增加 ;peerType=observer
server.1=192.168.30.129:2888:3181
server.2=192.168.30.135:2888:3181
server.3=192.168.30.136:2888: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服务器上，直到主动删除
持久化有序节点 ：每个节点都会为它的一级子节点维护一个顺序
临时节点 ： 临时节点的生命周期和客户端的会话保持一致。当客户端会话失效，该节点自动清理
临时有序节点 ： 在临时节点上多勒一个顺序性特性
会话
状态有 未连接，连接中，连接，断开四种
Watcher
zookeeper提供了分布式数据发布/订阅,zookeeper允许客户端向服务器注册一个watcher监听。当服务器端的节点触发指定事件的时候
会触发watcher。服务端会向客户端发送一个事件通知
watcher的通知是一次性，一旦触发一次通知后，该watcher就失效
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 字段去控制数据行的版本号
4.delete path [version]
删除节点
stat信息
cversion = 0 子节点的版本号
aclVersion = 0 表示acl的版本号，修改节点权限
dataVersion = 1 表示的是当前节点数据的版本号
czxid 节点被创建时的事务ID
mzxid 节点最后一次被更新的事务ID
pzxid 当前节点下的子节点最后一次被修改时的事务ID
ctime = Sat Aug 05 20:48:26 CST 2017
mtime = Sat Aug 05 20:48:50 CST 2017
cZxid = 0x500000015
ctime = Sat Aug 05 20:48:26 CST 2017
mZxid = 0x500000016
mtime = Sat Aug 05 20:48:50 CST 2017
pZxid = 0x500000015
cversion = 0
dataVersion = 1
aclVersion = 0
ephemeralOwner = 0x0 创建临时节点的时候，会有一个sessionId 。 该值存储的就是这个sessionid
dataLength = 3 数据值长度
numChildren = 0 子节点数
zookeeper能够实现哪些场景
zab协议 ： 如果客户端发了一个事务请求给到leader， 而leader发送给各个follower以后，并且收到了ack，leader已经commit。 在准备ack给各个follower节点comit的时候，leader挂了，怎么处理的。
- 选举新的leader（zxid的最大值）
- 同步给其他的folower