zookeeper 简析

写在前面:

       zookeeper 是为分布式应用程序提供高性能协调服务的一个开源项目,zookeeper本身也是一个分布式的应用,所有的zookeeper节点共同维护着一个与标准文件系统类似的共享分层命名空间以及持久化在磁盘的事务日志和快照,"命名空间"类似于Linux目录结构,与典型文件系统不同的是这个文件系统是,这个"命名空间",存在于内存之中,可以高效的读写,但是读取的效率远高于写入,读写效率比为10:1.

    客户端(一个第三方应用),通过tcp协议连接到zookeeper集群的一个服务器,进行 发送情况,获取响应,注册监听,和心跳检测等操作,如果这tcp连接中断,客户端连接到其他的服务器上去.只要zookeeper的集群中大多数集群机器是可以工作的那么集群就可以正常服务.

zookeeper的数据模型和命名空间

 

zookeeper的命名空间(官网图)

 

     zookeeper的命名空间是一个类似于Linux文件目录,每个节点我们成为--> znode, 比如 app1,app2,app3都是znode.

      znode可以是一个目录,也可以是一个文件,如果是文件那么它将存储 应用(app)的 状态信息,配置,位置信息,等 每个节点的数据量都非常小  通常在 1k到1000k之间,每一个 znode 都有一个版本号 ,当数据更新的时候 版本号会随之更新,zookeeper用数字标示每一个更新,来反应事务的顺序

      每个znode的数据写都是原子性的,  如果有大多数zookeeper集群中的节点(此节点是指zookeeper集群中的机器)响应写入成功，那么则认为写入成功,写操作是原子操作,只能成功或者失败不存在中间状态.

      znode有两种形式,一种是永久性的,另一种是临时znode,如果是临时znode那么在会话结束之后,将被销毁.

zookeeper集群结构

(官网图)

      zookeeper集群中节点分为,leader和follower和observe(观察者),

      follower负责处理client的请求,如果请求是读操作,那么follower将直接从本地副本里面响应client的请求,如何是写操作,这个请求将会被一个协议保护,这个协议要求所有的写操作都交由一台leader角色的机器来处理,

       leader 负责进行投票的发起和决议，最终更新状态 ,不负责任何client客户端单独请求的读取操作,leader将会向其他的所有follower发出更新通知,当多数follower响应更新成功之后,认为写入成功.

      observe 可以接收客户端连接，将写请求转发给leader节点。但是Observer不参加投票过程，只是同步leader的状态。

      其中 follower和observe都会和leader同步状态,当他们同步状态的时候都被成为learner(学习者).

     zookeeper 使用了 一个自定义的原子消息协议, 这个消息协议保证了消息更新是原子性的,zookeeper保证本地副本从不出现偏差.

zookeeper写入流程

 

      write request (写入请求):replicated database 是一个内存数据库  包含全部"命名空间"的信息,为了可恢复性,写入记录会保存到磁盘上,并且写入操作在写入到内存数据之前会序列化到磁盘上

     read request(读取请求): 读取请求直接请求 replicated database

zookeeper 选举机制

     zookeeper集群要求2n+1台机器组成.因为这样才能选举出leader.

     zookeeper 根据 paxos 算法决定是leader  在集群开始时 或者  leader崩溃后, zookeeper集群中每个节点都会投票，如果某个节点获得超过半数以上的节点的投票，则该节点就是leader节点了

     zookeeper核心是原子广播 zab -->两种模式 恢复模式和广播模式 ,zookeeper 集群刚刚启动的时候或者 leader崩溃的时候 进入 恢复模式,当 leader被选举出来之后,并且大多数follows 完成leader的同步之后,进入广播模式,

 

转载于:https://my.oschina.net/u/2969788/blog/868617