分布式协调-Zookeeper-概念与理论

一、分布式环境的特点

分布性

分布式系统由多台计算机组成，它们在地域上是分散的，可以散布在一个单位、一个城市、一个国家，甚至全球范围内。整个系统的功能是分散在各个节点上实现的，因而分布式系统具有数据处理的分布性。

并发性

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

无序性

进程之间的消息通信，会出现顺序不一致问题。

全局性

分布式系统中必须存在一个单一的、全局的进程通信机制，使得任何一个进程都能与其他进程通信，并且不区分本地通信与远程通信。同时，还应当有全局的保护机制。系统中所有机器上有统一的系统调用集合，它们必须适应分布式的环境。在所有CPU上运行同样的内核，使协调工作更加容易。

二、分布式环境下面临的问题

网络通信

网络本身的不可靠性，因此会涉及到一些网络通信问题。

网络分区(脑裂)

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

三态

在分布式架构里面，除了成功、失败、超时。

分布式事务

ACID(原子性、一致性、隔离性、持久性)。

三、分布式优缺点

优点

(1)资源共享

若干不同的节点通过通信网络彼此互联，一个节点上的用户可以使用其他节点上的资源，如分布式系统允许设备共享，使众多用户共享昂贵的外部设备，如彩色打印机；允许数据共享，使众多用户访问共用的数据库；可以共享远程文件，使用远程特有的硬件设备（如高速阵列处理器），以及执行其他操作。

(2)加快计算速度

如果一个特定的计算任务可以划分为若干个并行运行的子任务，则可把这些子任务分散到不同的节点上，使它们同时在这些节点上运行，从而加快计算速度。另外，分布式系统具有计算迁移功能，如果某个节点上的负载太重，则可把其中一些作业移到其他节点去执行，从而减轻该节点的负载。这种作业迁移称为负载平衡。

(3)可靠性高

分布式系统具有高可靠性。如果其中某个节点失效了，则其余的节点可以继续操作，整个系统不会因为一个或少数几个节点的故障而全体崩溃。因此，分布式系统有很好的容错性能。

系统必须能够检测节点的故障，采取适当的手段，使它从故障中恢复过来。系统确定故障所在的节点后，就不再利用它来提供服务，直至其恢复正常工作。如果失效节点的功能可由其他节点完成，则系统必须保证功能转移的正确实施。当失效节点被恢复或者修复时，系统必须把它平滑地集成到系统中。

(4)通信方便、快捷

分布式系统中各个节点通过一个通信网络互联在一起。通信网络由通信线路、调制解调器和通信处理器等组成，不同节点的用户可以方便地交换信息。在低层，系统之间利用传递消息的方式进行通信，这类似于单CPU系统中的消息机制。单CPU系统中所有高层的消息传递功能都可以在分布式系统中实现，如文件传递、登录、邮件、Web浏览和远程过程调用( Remote Procedure call，RPC)。

分布式系统实现了节点之间的远距离通信，为人与人之间的信息交流提供了很大方便不同地区的用户可以共同完成一个项目，通过传送项目文件，远程登录进入对方系统来运行程序，如发送电子邮件等，协调彼此的工作。

缺点

尽管分布式系统具备众多优势，但它也有自身的缺点，主要是可用软件不足，系统软件、编程语言、应用程序以及开发工具都相对很少。此外，还存在通信网络饱和或信息丢失和网络安全问题，方便的数据共享同时意味着机密数据容易被窃取。虽然分布式系统存在这些潜在的问题，但其优点远大于缺点，而且这些缺点也正得到克服。因此，分布式系统仍是人们研究、开发和应用的方向。

四、中心化和去中心化

冷备或者热备（上岗的速度不同，占用资源不同，单例的懒饿汉相似）

分布式架构里面，很多的架构思想采用的是：当集群发生故障的时候，集群中的人群会自动“选举”出一个新的领导。

最典型的是： zookeeper / etcd

五、经典的CAP/BASE理论

CAP

C（一致性 Consistency）: 所有节点上的数据，时刻保持一致

可用性（Availability）：每个请求都能够收到一个响应，无论响应成功或者失败

分区容错（Partition-tolerance）：表示系统出现脑裂以后，可能导致某些server与集群中的其他机器失去联系

CP / AP

CAP理论仅适用于原子读写的Nosql场景，不适用于数据库系统

六、BASE

基于CAP理论，CAP理论并不适用于数据库事务（因为更新一些错误的数据而导致数据出现紊乱，无论什么样的数据库高可用方案都是

徒劳），虽然XA事务可以保证数据库在分布式系统下的ACID特性，但是会带来性能方面的影响；

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

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

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

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

七、初步认识zookeeper

zookeeper是一个开源的分布式协调服务，是由雅虎创建的，基于google chubby。

zookeeper是什么

分布式数据一致性的解决方案

zookeeper能做什么

数据的发布/订阅（配置中心:disconf）、负载均衡（dubbo利用了zookeeper机制实现负载均衡）、命名服务、

master选举(kafka、hadoop、hbase)、分布式队列、分布式锁

zookeeper的特性

顺序一致性

从同一个客户端发起的事务请求，最终会严格按照顺序被应用到zookeeper中

原子性

所有的事务请求的处理结果在整个集群中的所有机器上的应用情况是一致的，也就是说，要么整个集群中的所有机器都成功应用了某一事务、

要么全都不应用

可靠性

一旦服务器成功应用了某一个事务数据，并且对客户端做了响应，那么这个数据在整个集群中一定是同步并且保留下来的

实时性

一旦一个事务被成功应用，客户端就能够立即从服务器端读取到事务变更后的最新数据状态；（zookeeper仅仅保证在一定时间内，近实时）

八、zookeeper安装

单机环境安装

下载zookeeper的安装包

http://apache.fayea.com/zookeeper/stable/zookeeper-3.4.10.tar.gz

解压zookeeper

tar -zxvf zookeeper-3.4.10.tar.gz

cd 到 ZK_HOME/conf , copy一份zoo.cfg

cp zoo_sample.cfg zoo.cfg

sh zkServer.sh

{start|start-foreground|stop|restart|status|upgrade|print-cmd}

sh zkCli.sh -server ip:port

集群环境

zookeeper集群, 包含三种角色: leader / follower /observer

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

observer不参与投票。只接收投票结果。
不属于zookeeper的关键部位。

在zoo.cfg里面增加

peerType=observer

server.1=192.168.11.129:2888:3888:observer

server.2=192.168.11.131:2888:3888

server.3=192.168.11.135:2888:3888

第一步：修改配置文件

server.id=host:port:port

id的取值范围： 1~255；用id来标识该机器在集群中的机器序号

server.N=YYY:A:B

其中N表示服务器编号，YYY表示服务器的IP地址，A为LF [ follower服务器(F)与leader服务器(L)之间 ] 通信端口，表示该服务器与集群中的leader交换的信息的端口。B为选举端口，表示选举新leader时服务器间相互通信的端口（当leader挂掉时，其余服务器会相互通信，选择出新的leader）。一般来说，集群中每个服务器的A端口都是一样，每个服务器的B端口也是一样。但是当所采用的为伪集群时(即一个物理机器上部署多个broker节点)，IP地址都一样，只能时A端口和B端口不一样。

server.1=192.168.11.129:2888:3888