分布式协调服务—zookeeper（一）

分布式环境的特点

分布性
并发性
程序运行过程中，并发操作是很常见的。比如同一个分布式系统中的多个节点，同时访问一个共享资源，数据库，分布式锁。
无序性
进程之间的消息通信，会出现顺序不一致的问题。

分布式环境下面临的问题

网络通信
网络本身的不可靠性
网络分区（数据重复）
当网络发生异常导致分布式系统中部分节点之间网络延时不断增大，最终导致组成分布式架构的所有节点，只有部分节点能够正常通信。
三态
在分布式架构里面 除了成功，失败，超时。
分布式事物
ACID 原子性 一致性 隔离型 持久性

中心化去中心化

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

经典的cap/base理论

CAP
C(一致性Consistency);所有节点上的数据时刻保持一致
可用性（Avaliablity；每个请求都能得到一个响应，无论响应是否成功或者失败
分区容错性（Partition-tolerance)；表示系统出现脑裂以后，可能导致某些server与集群中的其他机器失去联系
CP/CA
CAP理论仅使用于原子读写Nosql场景，不适用于数据库

BASE
基于CPA理论，CAP理论并不适用于数据库事物（因为更新一些错误的数据导致数据出现紊乱，无论什么样的数据库高可用方案都是徒劳）XA事物虽然可以保证数据库在分布式系统下的ACID特性，但会带来性能方面的影响

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

Basically avliable:数据库采用了分片的模式，把100万用户分片到5个实例上，如果破坏了其中一个实例，任然可以保证80%的用户可用

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

Eventually consistent:数据的最终一致性

初步认识zookeeper

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

zookeeper是什么？

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

zookeeper能做什么？

数据的发布订阅（配置中心disconf）,负载均衡（dubbo+zookeeper）,命名服务，master选举（kafaka hadoop hbase）分布式队列，分布式锁

zookeeper的特性

顺序一致性 从一个客户端发起事物的请求，最终会严格按照顺序被应用到zookeeper中
原子性 所有的事物请求的处理结果在整个集群中的所有机器上的应用情况是一致的，也就是说，要么整个集群中的所有机器都成功应用了某一事物，要么全都不应用
可靠性 一旦服务器成功应用了某一事物数据，并且对客户端做了响应，那么这个数据在整个集群中一定是同步并且保留下来的。
实时性 一旦一个事物被成功应用，客户端能够立即从服务器端读取到事物变更后的最新数据状态；（zookeeper仅仅保证在一定时间内，近实时）