1.zookeeper的初步认识

它是一个可靠的分布式协调服务，主要用来解决分布式一致性问题，同时也是一种粗粒度的分布式锁服务。

1.1 分布式一致性问题

在一个分布式系统中，有多个节点，每个节点都会提出一个请求，所有节点只能确定一个请求被通过，这个通过需要所有节点达成一致的结果。所谓的一致性是所有的请求中能够选出一个最终确定的请求。
由于网络存在不可靠的问题，存在消息丢失，或者网络延迟，如何在这个网络环境下达成请求一致性问题，为了解决这个问题，Paxos协议，在不可靠的网络 通信中，Paxos协议可以解决针对某多个协议达成一致。所以分布式一致性的本质是在多个分布式系统中，多个节点的某一个提议如何能达到一致性问题。

1.2 Google Chubby

在 Google 有一个 GFS(google file system)，他们有一个需求就是要从多个 gfs server 中选出一个 master server。这个就是典型的一致性问题，5 个分布在不同节点的 server，需要确定一个 master server，而他们要达成的一致性目标是：确定某一个节点为 master，并且所有节点要同意。而 GFS 就是使用 chubby 来解决这个问题的。
实现原理:所有的server通过协议到chubby上创建同一个文件，最终只有一个server能够获取创建这个文件，这个server就是master,它会在这个文件中写自己的地址，这样其它的 server 通过读取这个文件就能知道被选出的
master 的地址

1.3 分布式锁服务

从另一个角度来看，chubby提供了粗粒度的分布式锁服务，chubby通过创建文件的形似来提供锁的功能，server向chubby中创建文件就相当于加锁操作，创建文件成功则表示抢占到锁。
由于chubby没有开源，所以雅虎公司基于chubby的思想，自己开发了一个开源软件，类似于分布式协调的一个组件zookeeper。zookeeper并不是作为一个注册中心来设计的，它是作为一个分布式锁的一种设计，而注册中心只是它的一个功能而已。

2.zookeeper的设计猜想

2.1 单点故障问题

在分布式系统中，任何节点都不能以单点的形式存在，因为要解决单点问题，最长用的方法是集群。
1.集群要由主节点和从节点
2.集群要能实现数据同步，当主节点数据出现故障的，则从节点能代替主节点的工作，继续工作的前提是数据要和主节点的数据保持一致。
3.主节点挂了后，从节点如何替换成为主节点，是人工干预还是自己选举？

2.2 leader角色

主要负责工作由两种
1.事务请求的唯一调度者和处理者，保证集群事务处理的顺序性。
2.集群内部各服务之间的调度。

2.3 follower角色

它的主要职责有:
1.处理客户端发起的非事务请求操作，转发事务请求给leader.
2.参与事务请求的proposal的投票(需要半数以上的服务器通过才能通知leader提交数据，leader发起提案，follower投票)。
3.参与leader选举。

2.4 数据同步

要实现各个节点的数据一致，就必须让leader节点负责协调和数据同步操作，事务型数据和非事务型数据的分开处理方式，就是leader可以处理非事务数据和事务数据。而follower只处理非事务数据，对于数据变更的操作，应该由一个节点来维护，使得集群数据处理的简化。同时数据需要能够通过 leader 进行分发使得数据在集群中各个节点的一致性。
leader 节点如何和其他节点保证数据一致性，并且要求是强一致的。在分布式系统中，每一个机器节点虽然都能够明确知道自己进行的事务操作过程是成功和失败，但是却无法直接获取其他分布式节点的操作结果。所以当一个事务操作涉及到跨节点的时候，就需要用到分布式事务，分布式事务的数据一致性协议有 2PC 协议和 3PC 协议.

2.5 2pc提交

当一个事务需要跨多个分布式时节点时，为了保持事务处理的ACID特性，就需要引入协调者来统一执行逻辑，这些调度的分布式节点被称为AP,TM负责AP的行为，最终决定这些AP是否要把真正的事务进行提交，因为整个事务提交需要分为两个阶段提交。所谓为2pc.

2.6 阶段一：提交事务的请求

1.事务询问
协调者向所有的参与者发送事务内容，询问是否可以执行事务提交操作，并开始等待各参与者的响应
2.执行事务
各个参与者节点执行事务操作，并将 Undo 和 Redo 信息记录到事务日志中，尽量把提交过程中所有消耗时间的操作和准备都提前完成确保后面 100%成功提交事务
3.各个参与者向协调者反馈事务询问的响应
如果各个参与者成功执行了事务操作，那么就反馈给参与者 yes 的响应，表示事务可以执行；如果参与者没有成功执行事务，就反馈给协调者 no 的响应，表示事务不可以执行，上面这个阶段有点类似协调者组织各个参与者对一次事务操作的投票表态过程，因此 2pc 协议的第一个阶段称为“投票阶段”，即各参与者投票表名是否需要继续执行接下去的事务提交操作。

2.7 阶段二:执行事务提交

在这个阶段，协调者会根据各参与者的反馈情况来决定最终是否可以进行事务提交操作，正常情况下包含两种可能:执行事务、中断事务

2.8 Observer角色

该角色时观察者角色，Observer 的工作原理与 follower 角色基本一致，而它和 follower 角色唯一的不同在于observer 不参与任何形式的投票，包括事物请求 Proposal 的投票和 leader选举的投票。简单来说，observer 服务器只提供非事物请求服务，通常在于不影响集群事物处理能力的前提下提升集群非事物处理的能力。