分布式协调服务zookeeper应用与原理

1. 初步认识zookeeper

ZooKeeper 是一个开源的分布式协调服务，由雅虎创建，是 Google Chubby 的开源实现。分布式应用程序可以基于 ZooKeeper 实现诸如数据发布/订阅（配置中心）、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举（kafka、hadoop、hbase）、分布式锁和分布式队列等功能。

2. 为什么要使用zookeeper

2.1 分布式环境的特点

分布性

当并发量增大时，单机性能的限制无法满足请求并发访问。这时有两种方案：垂直扩展和水平扩展。垂直扩展指扩展单机硬件性能，该方案的缺点是性价比较低，并且有一定瓶颈仍然无法面对海量的数据访问，单机宕机时无法保证高可用性。概况来讲就是无法满足两点：高并发、高可用。水平扩展就是所说的分布式环境，指得是程序部署在不同的服务器上，通过中间件通信。保证了高并发，高可用的特性。

并发性

程序运行过程中，并发性操作是很常见的。比如同一个分布式系统中的多个节点，同时访问一个共享资源：数据库、分布式存储等。

无序性

进程之间的消息通信，会出现顺序不一致问题。在一些情况下，无序性不会影响程序的最终执行结果。但是在一些有强依赖关系的消息通信，先后顺序会影响程序的执行结果。

2.2分布式环境下面临的问题

网络通信

网络本身的不可靠性，因此会涉及到一些网络通信问题，影响到数据最终一致性和程序执行先后顺序。

网络分区(脑裂)

当网络发生异常导致分布式系统中部分节点之间的网络延时不断增大，最终导致组成分布式架构的所有节点，只有部分节点能够正常通信。

2.3 分布式数据一致性 （经典的CAP/BASE理论）

CAP

C（一致性 Consistency）: 所有节点上的数据，时刻保持一致。
A 可用性（Availability）：每个请求都能够收到一个响应，无论响应成功或者失败。
P 分区容错 （Partition-tolerance）：表示系统出现脑裂以后，可能导致某些server与集群中的其他机器失去联系。

单机数据库要满足ACID特性（可用性、一致性、隔离性、持久性），CAP理论仅适用于原子读写的Nosql场景，不适用于数据库系统（因为更新一些错误的数据而导致数据出现紊乱，无论什么样的数据库高可用方案都是徒劳） ，虽然XA事务可以保证数据库在分布式系统下的ACID特性，但是会带来性能方面的影响。分布式环境无法同时满足CAP的特性，只能在其中取舍。一般互联网服务保持高可用性是一切的前提，所以一般选择AC或者AP。

BASE

Bay尝试了一种完全不同的套路，放宽了对事务ACID的要求。提出了BASE理论

Basically available ： 数据库采用分片模式， 把100W的用户数据分布在5个实例上。如果破坏了其中一个实例，仍然可以保证80%的用户可用。

soft-state： 在基于client-server模式的系统中，server端是否有状态，决定了系统是否具备良好的水平扩展、负载均衡、故障恢复等特性。
Server端承诺会维护client端状态数据，这个状态仅仅维持一小段时间, 这段时间以后，server端就会丢弃这个状态，恢复正常状态。

Eventually consistent：数据的最终一致性。

分布式架构里面，很多的架构思想采用的是：当集群发生故障的时候，集群中的人群会自动“选举”出一个新的领导。zookeeper是该理论比较经典的实。ZooKeeper 作为一个分布式数据一致性的解决方案，在分布式环境中满足上述原理，解决分布式问题。

3. zookeeper基本概念

3.1 集群角色

zookeeper中存在三种角色：
leader :Leader作为整个Zookeeper集群的主节点，负责响应所有对Zookeeper状态变更的请求。它会将每个状态更新请求进行排序和编号，以便保证整个集群内部消息处理的FIFO。

follower:参与投票和用户读请求。

observer:是一种特殊的zookeeper节点。可以帮助解决zookeeper的扩展性（如果大量客户端访问我们zookeeper集群，需要增加zookeeper集群机器数量。从而增加zookeeper集群的性能。 导致zookeeper写性能下降， zookeeper的数据变更需要半数以上服务器投票通过。造成网