101- zookeeper-1

分布式环境特点

分布性

并发性

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

无序性

进程之间的消息通信，会出现顺序不一致的问题

分布式环境下面临的问题

网络通信

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

网络分区（脑裂）

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

三态

在分布式架构里面，除了成功、失败 还有超时

分布式事务

ACID（原子性、一致性、隔离性、持久性）

中心化和去中心化

冷备和热备

经典的CAP/BASE理论

CAP

一致性（Consistency）：所有节点上的数据，时刻保持一致
可用性（Availability）：每个请求都能够收到一个响应，无论响应成功或者失败
分区容错（Partition-tolerance）：表示系统出现脑裂以后，可能导致某些server与集群中的其他机器失去联系
CP / AP
CAP理论仅适用于原子读写的NoSql场景，不适用于数据库系统

BASE

基于CAP理论，CAP理论并不适用于数据库事务（因为i更新一些错误的数据而导致数据出现紊乱，无论什么样的数据高可用方案都是徒劳），虽然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安装

单机环境安装

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 到1. 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

集群环境

zookeeper集群，包含三种角色：leader、follow、observer
observer
observer是一种特殊的zookeeper节点。可以帮助解决zookeeper的扩展性（如果大量客户端访问我们zookeeper集群，需要增加zookeeper集群机器数量。从而增加zookeeper集群的性能。导致zookeeper写性能下降，zookeeper的数据变更需要半数以上服务器投票通过。造成网络消耗增加投票成本）

1. observer不参与投票，只接收投票结果
2. 不属于zookeeper的关键部位。
3. 在zoo.cfg里面增加
   peerType=observer

server.1=192.168.11.129:2181:3181:observer
server.2=192.168.11.131:2181:3181
server.3=192.168.11.135:2181:3181

第一步： 修改配置文件
server.id=host:port:port
id的取值范围： 1~255； 用id来标识该机器在集群中的机器序号
2181是zookeeper的端口； //3306
3181表示leader选举的端口

server.1=192.168.11.129:2181:3181
server.2=192.168.11.131:2181:3181
server.3=192.168.11.135:2181:3181

第二步：创建myid
在每一个服务器的dataDir目录下创建一个myid的文件，文件就一行数据，数据内容是每台机器对应的server ID的数字

第三步：启动zookeeper

192.168.11.129
192.168.11.131
192.168.11.135
zoo.cfg配置文件分析
tickTime=2000 zookeeper中最小的时间单位长度（ms）
initlimit=10 follower节点启动后与leader节点完成数据同步的时间
syncLimit=5 leader节点和follower节点进行心跳检测的最大延时时间
dataDir=/tmp/zookeeper 表示zookeeper服务器存储快照文件的目录
dataLogDir 表示配置zookeeper事务日志的存储路径，默认指定在dataDir目录下
clientPort 表示客户端和服务器端建立连接的端口号

zookeeper中的一些概念

数据模型

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

节点特性

持久化节点：节点创建后悔一直在zookeeper服务器上，直到主动删除
持久化有序节点：每个节点都会为它的一级子节点维护一个顺序
临时节点：临时节点的生命周期和客户端的会话保持一致。当客户端会话失效，该节点自动清理
临时有序节点：在临时节点上多了一个顺序性特性

会话

Watcher

zookeeper提供了分布式数据发布/订阅，zookeeper允许客户端向服务器注册一个watcher监听。当服务器端的节点触发指定事件的时候会触发watcher。服务端会向客户端发送一个事件通知。
watcher的通知是一致性，一旦触发一次通知后，该wathcer就失效

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 表示ack的版本号，修改节点权限
   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 子节点数