标签：参与 系统默认 重要 数据流 系统架构 递增 http nbsp 没有
Zookeeper中的角色主要有以下三类
领导者（Leader）
领导者负责进行投票的发起和决议，更新系统状态
学习者（Learner）
跟随者（Follwer）
Follwer用于接收客户请求并向客户端返回结果，在选主过程中参与投票
观察者（ObServer）
ObServer可以接收客户端连接，将写请求转发给leader节点。但ObServer不参加投票过程，只同步leader的状态。ObServer的目的是为了扩展系统，提高读取速度。
客户端（Client）
请求发起方
Zookeeper的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和leader的状态同步之后，恢复模式就结束了，状态同步保证了leader和Server具有相同的系统状态。
为了保证事务的顺序一致性，zookeeper采用了递增事务id号（zxid）来标识事务，所有的提议（proposal）都在被提出的时候加上了zxid。其中zxid是一个64位的数组，它高32位是epoch用来表示leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch,标识当前属于哪个leader的统治时期，低32位用于递增技数。
每个Server在工作过程中有三种状态：
LOOKING:当前Server不知道leader是谁，正在搜寻。
LEADING:当前Server即为选举出来的leader。
FOLLOWING:leader已经选举出来，当前Server与之同步。
当leader崩溃或者leader失去大多数的follower，这时候zk进入恢复模式，恢复模式需要重新选举出一个新的leader，让所有的Server都恢复到一个正确的状态。Zk的选举算法有两种：一种是基于basic paxos实现的，另外一种是基于fast paxos算法实现的。系统默认的选举算法为fast paxos。
Fast paxos流程是在选举过程中，某Server首先向所有的Server提议自己要成为leader，当其它Server收到提议以后，解决epoch和zxid的冲突，并接收对方的提议，然后向对方发送接受提议完成的消息，重复这个流程，最后一定能选出Leader。
1、 最终一致性：client不论连接到哪个Server，展示给它都是同一个视图，这是zookeeper最重要的性能。
2、 可靠性：具有简单、健壮、良好的性能，如果消息m被一台服务器接收，那么它将被所有服务器接受。
3、 实时性：ZooKeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效信息，但由于网络延时等原因，ZooKeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口
4、 等待无关：慢的或者失效的client不得干预快速的client请求，使得每个client都能有效的等待。
5、 原子性：更新只能成功或者失败，没有中间状态。
6、 顺序性：包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息a在消息b前发布，则在所有Server上消息a都将消息b前被发布；偏序是指如果一个消息b在消息a后备同一个发送者发布，a必将排在b前面。
Zookeeper架构图中我们需要掌握
1、 Zookeeper分为服务器端和客户端，客户端可以连接到整个Zookeeper服务的任意服务器上（除非leaderServers参数显示设置，leader不予许接收客户端连接）。
2、 客户端使用并维护一个TCP连接，通过这个连接发送请求、接受响应、获取观察的事件以及发送心跳。如果这个TCP连接中断，客户端将自动尝试连接到另外的Zookeeper服务器。客户端第一次连接到Zookeeper服务器时，接受这个连接的ZooKeeper服务器会为这个客户端建立一个会话。当这个客户端连接到另外的服务器时，这个会话被新的服务器重新建立。
3、 上图中的每一个Server代表一个安装ZooKeeper服务的机器，即是整个提供ZooKeeper服务的集群（或者是由为集群组成）
4、 组成Zookeeper服务的服务器必须彼此了解。它们维护一个内存中的状态图像，以及持久存储中的事务日志和快照，只要大多数服务器可用，ZooKeeper服务就可用。
5、 ZooKeeper启动时，将从实例中选举一个leader，Leader服务处理数据更新等操作，一个更新操作成功的标志是当且仅当大多数Server在内存中成功修改数据。每个Server在内存中存储了一份数据。
6、 Zookeeper是可以集群复制的，集群间通过Zab协议（Zookeeper Atomic Broadcast）来保持数据的一致性。
7、 Zab协议包括两个阶段：leader election阶段和Atomic Broadcast阶段
a) 集群中将选举一个leader，其他的机器则称为follower，所有的写操作都被传送给leader，并通过broadcast将所有的更新告诉给follower。
b) 当leader崩溃或者leader失去大多数follower时，需要重新选举出一个新的leader，让所有的服务器都恢复到一个正确的状态。
c) 当leader被选举出来，且大多数服务器完成了和leader的状态同步后，leadder election的过程就结束了，就将会进入到Atomic broadcast的过程。
d) Atomic Broadcast同步leader和follower之间的信息，保证leader和follower具有相同的系统形态。
Zookeeper中Leader选举算法采用了Zab协议。Zab核心思想是当多数Server写成功，则任务数据写成功。
1、 如果有3个Server，则最多允许1个Server挂掉。
2、 如果有4个Server，则同样最多允许1个Server挂掉。
既然3个或者4个Server，同样最多允许1个Server挂掉，那么它们的可靠性是一样的，所以选择奇数个ZooKeeper Server即可，这里选择3个Server。
1、 比如Client向ZooKeeper的Server1上写数据，发送一个写请求。
2、 如果Server1不是Leader，那么Server1会把接收到的请求进一步转发给Leader，因为每个Zookeeper的Server里面有一个是Leader，这个Leader会将写请求广播给各个Server，比如Server1和Server2，各个Server写成功后就会通知Leader。
3、 当Leader收到大多数Server数据写成功了，那么久说明数据写成功了，写成功之后，Leader会告诉Server1数据写成功了。
4、 Server1会进一步通知Client数据写成功了，这是就认为整个写操作成功。
标签：参与 系统默认 重要 数据流 系统架构 递增 http nbsp 没有
原文地址：http://www.cnblogs.com/fhhk/p/7424192.html
