【分布式协调服务】-- zookeeper 出现背景

集群服务的问题：

1. 协议地址的维护
   一个服务分别部署在多个服务器上，每个服务器的地址都是一个协议地址
2. 负载均衡机制
   转发请求，均衡各个服务节点的负载
3. 服务动态上下线感知
   （上线：某个服务发布上线调用者可以知晓； 下线：如若集群中某个节点服务出问题宕机可以迅速定位）

如何解决集群服务问题

思路: (我们需要一个什么样的东西来解决上述问题)

1. 需要有一个中间件
2. 发布服务的时候可以注册到中间件上去，在中间件上维护一个类似电话簿的功能（存着所有目标服务器的地址），断开时也可以立即知晓。
3. 客户端只需要拿到中间件地址即可知道目标服务器的所有信息
4. 中间件可以感知各个服务的上下线状况，
5. 这样开发者更专注与其应用本身的逻辑而不是关注分布式系统处理。

引入了zookeeper(分布式协调服务)

zookeeper是用来协调各个服务访问的顺序性，也用来管理中间件。

1. zookeeper起源于雅虎，最初设计目标是解决共享资源竞争的问题，解决了多节点访问共享资源时候各个节点的接入顺序，（各个节点都是独立的进程）
2. 后来，为了防止单点故障，zookeeper作为了一个中间件也需要做集群，来保证本身的高可用。
3. 由此引入了zookeeper集群中各个中间件之间的数据同步问题，集群中的每个节点都可以接收到请求，而且每个节点的数据都必须要保持一致，这样就引入了一个leader节点来负责协调和做数据同步操作。因为集群中如果是去中心化的没有leader界定的时候，那么每个节点都可以接受所有的请求，最后这个集群的数据同步的复杂度将会是非常大的。
4. 根据上述的设想我们在zookeeper集群中引入了leader节点，那么leader节点故障了该如何处理？
5. zookeeper用了基于paxos理论所衍生出来的zab协议来做leader节点故障之后的leader选举和节点故障恢复。
6. 在分布式系统中，每个节点都可以明确的知道自己进行的事务操作过程的结果（成功与失败），却无法直接知晓其他节点的操作结果，所以当一个事务涉及到跨节点时，就需要用到分布式事务，相关的一致性协议有CAP理论，Base理论，2PC协议和3PC协议。

上述便是zookeeper出现的背景，以及引入的各种协议，后面的文章将详细去剖析zookeeper内涉及到的内容。

tips:

数据不同步问题？？

A访问集群的某一个节点x，注册上去了一个用户,

B访问集群中的另外一个节点y，此时查不到A注册上去的用户，

数据同步引入CAP理论

如果为了保持强一致性，就需要在写操作完成之后，先同步然后再响应下一个请求，会降低性能，不可取，所以保持高性能，保证最终一致性。

事务请求（增删改请求）
如果事务请求落在了follower节点上，follower会转发改请求到leader上，交由leader节点处理。

为什么所有的事务请求都要放到leader上，协议请求要放在follower上？

中心化设计理念。
去中心化节点设计比较复杂，zookeeper简化复杂性。

中心化与去中心化：

中心化：
有领导leader，和follower,对leader依赖性比较强。

去中心化：
各自负责自己的领域，没有leader，某个节点故障只影响自己部分小面积的。