在学习的过程当中,咱们总须要一个来自灵魂的拷问: 为何?node
这个问题有深度,那要从五百万年提及,在遥远的塞伯坦星球.....算法
扯远了...服务器
在遥远在单机单服务的时代 , 想要扩展服务 , 只能增长硬件配置 . 如今看来 ,有如下问题:架构
这时候,分布式应运而生,将业务拆分开来,好比:仓库,订单,支付等等,各管各的 , 风险拆分, 好比: 订单服务挂了,不影响仓库和支付.分布式
这是分布式的初始模式, 风险少了, 再用个Nginx作个代理,集群化.而后彷佛大概也许Mybe能够 浪里个浪了 ~~工具
当项目愈来愈大,模块愈来愈多.又来问题了.性能
一开始的服务拆分并不必定很理想, 再加后期业务迭代, 可能产生不少个模块,各模块间的调用混乱 , 一条业务线中不知道串了多少个模块.学习
下图参考下: T_T代理
当你想了解一条线的时候,内心可不止一万个那啥...server
那么急需,迫切的须要一个能够把这个东西治理一下的工具.
buling~ buling ~ zookeeper来啦
先来感觉下使用zookeeper后的赶脚
啊.kimoji...
Zookeeper是一个高性能的分布式系统的协调服务
最终一致性
保证各个节点服务器数据可以最终达成一致,zk的招牌功能
顺序性
从同一客户端发起的事务请求,都会最终被严格的按照其发送顺序被应用到zk中,这也是zk选举leader的依据之一
可靠性
凡是服务器成功的使用一个事务,并完成了客户端的响应,那么这个事务所引发的服务端状态变动会被一直保留下去
实时性
zk不能保证多个客户端能同时获得刚更新的数据,因此若是要最新数据,须要在读数据以前强制调用sync接口来保证数据的实时性
原子性
数据更新要么成功要么失败
单一视图
不管客户端连的是哪一个节点,看到的数据模型对外一致
Leader
更新系统状态,处理事务请求,负责进行投票的发起和决议
Leaner
处理客户端非事务请求,并向客户端返回结果. 将写事务请求转发给Leader,同步Leadker的状态. 选举过程当中参与投票.可被选举.
接收客户端读请求,将客户端写请求转发给Leader,不参与投票过程,只同步Leader状态.目的是为了扩展系统,提升读取速度.
Client
请求发起方
数据写入最终一致性ZAB算法 .
Leader负责处理写事务请求,Follower负责向Leader转发写请求,响应Leader提出的提议.
先了解几个关键字:
状态
事务ID
流程
znode是zk特有的数据模型,是zk中数据最小单元,znode上能保存数据,经过挂载子节点造成一个树状的层次结构。根由/斜杠开始。
节点类型
主要用来经过版本号来实现分布式锁的一些控制
znode watch机制也是zk的核心功能之一,是配置管理功能的基石。client端经过注册watch对象后,只要相应的znode触发更改,watch管理器就会向客户端发起回调,可借此机制实现配置管理的分布式更新和同步队列等场景。
[1]洛神独舞:Zookeeper架构原理和使用场景总结