在学习的过程中,我们总需要一个来自灵魂的拷问: 为什么?
为什么会产生Zookeeper
这个问题有深度,那要从五百万年说起,在遥远的塞伯坦星球.....
扯远了...
在遥远在单机单服务的时代 , 想要扩展服务 , 只能增加硬件配置 . 现在看来 ,有以下问题:
- 硬件贵 (有钱的老板也能接受)
- 扩展麻烦 (在还没有实时扩展的云服务时,加硬件就意味着宕机)
- 没有容错 (一旦生产异常,服务就挂了,灾难)
这时候,分布式应运而生,将业务拆分开来,比如:仓库,订单,支付等等,各管各的 , 风险拆分, 比如: 订单服务挂了,不影响仓库和支付.
这是分布式的初始模式, 风险少了, 再用个Nginx做个代理,集群化.然后似乎大概也许Mybe可以 浪里个浪了 ~~
当项目越来越大,模块越来越多.又来问题了.
一开始的服务拆分并不一定很理想, 再加后期业务迭代, 可能产生很多个模块,各模块间的调用混乱 , 一条业务线中不知道串了多少个模块.
下图参考下: T_T
当你想了解一条线的时候,心里可不止一万个那啥...
那么急需,迫切的需要一个可以把这个东西治理一下的工具.
buling~ buling ~ zookeeper来啦
zookeeper解决了哪些问题
先来感受下使用zookeeper后的赶脚
啊.kimoji...
概念
Zookeeper是一个高性能的分布式系统的协调服务
Zookeeper特性
-
最终一致性
保证各个节点服务器数据能够最终达成一致，zk的招牌功能
-
顺序性
从同一客户端发起的事务请求，都会最终被严格的按照其发送顺序被应用到zk中，这也是zk选举leader的依据之一
-
可靠性
凡是服务器成功的使用一个事务，并完成了客户端的响应，那么这个事务所引起的服务端状态变更会被一直保留下去
-
实时性
zk不能保证多个客户端能同时得到刚更新的数据，所以如果要最新数据，需要在读数据之前强制调用sync接口来保证数据的实时性
-
原子性
数据更新要么成功要么失败
-
单一视图
无论客户端连的是哪个节点，看到的数据模型对外一致
Zookeeper中的四种角色
-
Leader
更新系统状态,处理事务请求,负责进行投票的发起和决议
-
Leaner
- Follower
处理客户端非事务请求,并向客户端返回结果. 将写事务请求转发给Leader,同步Leadker的状态. 选举过程中参与投票.可被选举.
- Observer
接收客户端读请求,将客户端写请求转发给Leader,不参与投票过程,只同步Leader状态.目的是为了扩展系统,提高读取速度.
-
Client
请求发起方
Zookeeper的写入流程
数据写入最终一致性ZAB算法 .
Leader负责处理写事务请求,Follower负责向Leader转发写请求,响应Leader提出的提议.
Zookeeper选举机制
先了解几个关键字:
状态
- looking : 寻找Leader状态,处于该状态需要进入选举过程.或正在进行选举.
- Leading : Leader的状态,表示当前服务的角色为Leader
- Following : 从节点 , Leader已经选出,当前为从节点
- Observer : 观察者状态
事务ID
- zxid : 64位数字,Leader分配,全局唯一且递增.值越大,表示操作越新.
流程
- 每个节点发出一个投票,内容是(myid,zxid)
- 接收来自各个节点的投票,
- 进行投票处理和统计
- zxid对比,选取较大的
- zxid一样的,选取myid较大的
- 当有一半以上的服务器选出同一个节点.选举结束.
- 被选举的Leader节点更新状态
Zookeeper的数据模型:znode
znode是zk特有的数据模型，是zk中数据最小单元，znode上能保存数据，通过挂载子节点形成一个树状的层次结构。根由/斜杠开始。
节点类型
- 持久节点
- 临时节点
- 顺序节点
- 不同节点类型的组合。
Zookeeper版本
- 当前数据节点的版本号
- 当前数据子节点版本号
- acl权限变更版本号
主要用来通过版本号来实现分布式锁的一些控制
Zookeeper : znode watch机制
znode watch机制也是zk的核心功能之一，是配置管理功能的基石。client端通过注册watch对象后，只要相应的znode触发更改，watch管理器就会向客户端发起回调，可借此机制实现配置管理的分布式更新和同步队列等场景。
参考
[1]洛神独舞:Zookeeper架构原理和使用场景总结
来源：oschina
链接：https://my.oschina.net/u/2697791/blog/2875083