文章目录
简介
zookeeper是一种分布式应用程序的分布式开源协调服务，主要用来解决分布式应用中遇到的一些数据管理问题。例如：状态同步、集群管理。
两种工作模式
zk核心是原子广播，该机制保证了各个server之间的同步，实现该机制的协议叫做zab协议，下面我们就展开介绍zab协议中的两种工作模式。
恢复模式
当出现以下三种情况时候，zk就会进入恢复模式：
1. 服务框架启动过程中
2. leader服务器中断、崩溃、重启等
3. 过半的服务器不在与leader保持正常通信
恢复模式下，会在所有的follower服务器中选举一台leader，当leader被选举出来时，集群中多数的服务器与leader完成状态同步之后就会退出恢复模式，注意我说的是多数，即只要半数以上的follower能和新的leader完成状态同步(也可以理解为数据同步)之后，就会进入消息广播模式，而消息广播模式就是第二种工作模式，这一模式下文会有介绍。
需要特别说明的新server加入zk何时生效，由上文我们可知只有在恢复模式下再会进行leader选举和状态同步，所以新加入的server必须在恢复模式下才会生效。
广播模式
消息模式是一种基于FIFO的tcp原子广播协议，当有客户端进行事务请求时，leader会为其生成一个对应事务的proposal，并将其发送到集群中的所有机器，然后收集选票，当大部分通过后，就会进行事务提交。具体的工作步骤如下：
1. leader收到接受消息后，将消息赋予一个全局唯一的64位自增id，通常称为zxid，这个zxid的作用是为了当出现大量消息的时候，zk可根据zxid的大小决定消息有序发送。
2. leader将消息发送给所有follower
3. follower收到proposal后，会将proposal写到本地事务中，事务写成之后会给zk回一个ack确认。
4. leader收到大部分ack确认后，会向所有的follower发送commit，告诉他们执行事务。
5. follower执行事务
zookeeper节点模型
如下图所示，节点是树形结构，当需要访问根目录下的节点时候必须使用绝对路径而不是相对路径
zookeeper特性
- 资源共享：例如存储能力、计算能力、数据、服务共享
- 扩展性：分布式协调服务很好的完成了扩展性
- 并发性：zk支持多个用户同步访问
- 性能：负载增加时，服务不会被影响
- 容错性：一些组件出错不会影响整个系统大体流程
- api抽象：服务使用的各个独立组件对用户隐藏，仅暴露一个服务
zookeeper角色
- leader：负责发起投票和决议，更新系统状态
- follower：follower用于接受客户端请求并返回结果，同时在选举中也参与投票
- observer：可接受客户端连接，将请求转发给leader，但observer不参数投票，只同步leader状态，可以看得出来observer是扩展系统提高，提高读取速度的。
- 客户端：请求发起方。
zookeeper工作优点
- 顺序一致性：客户端更新将发送顺序应用
- 原子性：要么同时成功，要么同时失败
- 统一视图：无论服务器连接到那台服务器，客户端都会看到相同服务视图
- 可靠新
- 及时性：系统的客户试图保证特定时间范围内数据是最新的
znode节点分类和操作示例
创建节点
create /zkZsy app1
ls / #可查看节点是否创建成功
get /zkZsy #查看节点内容
修改节点数据
set /zkZsy zkZsyaaaa
删除节点
delete /zkZsy
临时节点
临时节点会在客户端会话结束时，就被关闭，常用于进行集群管理和服务上下线。
create -e /zkCxq app1
持久节点
常规命令就会创建持久节点，除非显示删除，否则不会被删除
create /zkZsy app1
顺序节点
如下所示相同节点用 -s之后，会在创建节点时在节点后一个序列区分
create -s /zkCxq app1
Created /zkCxq0000000005
create -s /zkCxq app1
Created /zkCxq0000000006
create -s /zkCxq app1
Created /zkCxq0000000007
注意
zk岁提供节点存储，但不建议将zk当数据，zk规定了节点数据大小不可超过1
，所以当有大量数据存储时，建议在redis或者数据库存数据，znode存储索引即可