分布式协调架构核心原理与应用.pdfVIP

•解决单点故障

•毫秒级处理

•解决分布协调的问题

攘其外状态下

•Zookeeper是的Chubby一个开源的实现，是

Hadoop的分布式协调服务service

•包含一个简单的原语集，分布式应用程序可以基于它实现：

•开源领域首屈一指

特点说明

最终一致性为客户端展示同一个视图，这是zookeeper里面一

个非常重要的功能

可靠性如果消息被到一台服务器接受，那么它将被所有的

服务器接受。（随便连）

Zookeeper不能保证两个客户端能同时得到刚更新

实时性的数据，如果需要数据，应该在读数据之前调

用sync()接口。（最终一致性）

独立性各个Client之间互不干预

原子性更新只能成功或者失败，没有中间状态。

顺序性所有Server，同一消息发布顺序一致。（单点，多

点会有事务问题）

拓扑

•角色模型

–集群状态（可用/不可用）

–主从分工

•攘其外：

–统一视图

•会话session

•数据模型Znode

–目录结构

–节点类型

–Watcher

•原理：

–原子消息广播协议ZAB

•paxos

–journalnode

–sentinel

–zookeeper➔ZAB

•zxid,myid：

•ZXID:epoch+ID

–广播模式原理

–恢复模式原理：无主模型：zab：zxid,myid

•应用场景

–统一命名

–配置管理

–集群管理

•角色模型

–集群状态

•模式安其内

•广播模式壤其外

–Server状态

•LOOKING：当前Server不知道leader是谁，正在搜寻

•LEADING：当前Server即为出来的leader

•FOLLOWING：leader已经出来，当前Server与之同步

–主从分工

•者（leader）

–负责进行投票的发起和决议，更新系统状态

•学习者（learner）

–包括跟随者（follower）和观察者（observer），follower用于接受客户端请求并向客户端返回结果，在选主过

程中参与投票

•Observer

–可以接受客户端连接，将写请求转发给leader，但observer不参加投票过程，只同步leader的状态，observer

的目的是为了扩展系统，提高速度

•客户端（client）

–请求发起方

•大部分分布式应用需要一个主控、协调器或控制器来管理分布的子进

程（如资源、任务分配等）

•目前，大部分应用需要开发私有的协调程序，缺乏一个通用的机制

•协调程序的反复编写浪费，且难以形成通用、伸缩性好的协调器

•ZooKeeper：通用的分布式锁服务，用以协调分布式应用