zookeeper学习

CAP理论

在分布式环境中，一致性是指数据在多个副本之间是否能够保持一致的特性。在一致性的需求下，当一个系统的一致性的状态下执行更新操作后，应该保持系统的数据仍然处于一致的状态

可用性

可用性是指系统提供的服务一致处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果

有限的时间内是指，对于用户的一个操作请求，系统必须能够在指定的时间内返回对应的处理结果，如果超出了这个时间范围，那么系统就被认为是不可用的，另外有限的时间是一个在系统之初九设定的系统运行指标

返回结果是可用性的另一个非常重要的指标，他要求系统在完成用户请求的处理后返回一个正常的响应结果。正常的响应结果通常能够明确的反应出对请求的处理结果，既成功或失败，而不是一个让用户感到非常困惑的结果

分区容错性

分区容错性约束了一个分布式系统需要具有如下特性：分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性的可用性服务，除非是整个王立哦环境发生了故障

网络分区是指在分布式系统中，不容的节点分布在不同的子网络（机房或者异地网络）中，由于一些特殊的原因导致这些子网络之间出现网络不连通的情况，但各个子网络的内部网络是正常的，从而导致整个系统的网络环境被切割成了若干个孤立的区域，需要注意的是，组成一个分布式网络的每个节点的加入与退出都可以看做是一个特殊的网络分区

但是分布式系统不可能同时满足这三个条件，最多满足其中的两项

BASE理论

他是基于CAP定理逐步演化而来的，其核心思想是即使无法做到强一致性，但是每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性

基本可用

基本可用是指分布式系统在出现不可预知的故障的时候，允许损失部分的可用性但是折不等价于系统不可用，下面两个例子

响应时间上的损失：正常情况下，一个在线搜索引擎需要在0。5秒之内返回给用户相应的查询结果，但由于出现故障（比如系统部分机房发生断电或网络故障），查询结果的响应时间增加到1~2秒

功能上的损失：正常情况下，一个电子商务网站上进行购物，消费者几乎能够顺利完成每一笔订单，但是在一些节日大促购物高峰的shi'h时候，由于消费者的购物行为过激，为了保护购物系统分稳定，部分消费者可能会被引导到一个降级页面

弱状态

也成为软状态和硬件状态相对，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同的节点的数据副本之间进行数据同步的过程中存在延时

最终一致性

最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能勾到达一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证数据的强一致性

zookeeper是一个典型的分布式数据一致性解决方案，基于它可以实现数据发布订阅，负载均衡，分布式协调／通知，集群管理，master选举，分布式锁和分布式队列等功能

zookeeper目标

zookeeper简单的数据模型

使得分布式程序能够通过一个共享的，树形结构的名字空间来进行相互的协调（被称为znode的数据节点组成）而且zookeeper将犬粮数据存储在内存中，以此以来实现提高服务器吞吐，减少延迟的目的

可以构建集群

组成zookeeper集群的每台机器都会在内存中维护当前的服务器状态，并且每台机器之间都能保持着通信，并且集群中存在超过一半的机器能够正常工作，那么整个集群就能勾正常对外提供服务

zookeeper客户端程序会选择和集群中任意一台机器共同创建一个tcp连接，而一旦客户端和某台zookeeper服务器之间断开后，客户端会自动连接到集群中的其他机器

顺序访问

对于客户端的每个更新请求，zookeeper都会分配一个全局唯一的递增编号，这个编号反映了所有事务操作的先后顺序，应用程序可以使用zookeeper这个特性实现更高层次的同步原语

高性能

由于zookeeper将全量数据存储在内存中，并直接服务于客户端所有的非事物请求，由此它尤其适用以读为主的应用场景

zookeeper的ZAB协议

ZAB协议支持崩溃恢复的原子广播协议

在zookeeper中重要依赖ZAB协议实现分布式数据一致性，基于该协议，zookeeper实现了基于主备模式的系统架构来保持集群中各副本之间数据的一致性。

zookeeper使用一个单一的主进程来接受并处理客户端的所有事务请求，并采用ZAB的原子广播协议，将服务器数据的状态变更以事物Proposal的形式广播到所有的副本进程上去，这个架构主要保证了同一时刻集群中只能够有一个主进程来广播服务器的状态变更

ZAB协议：

所有的事务请求必须由一个全局唯一的一个服务器来处理，这样的服务器被称为Leader服务器，而余下的其他服务器则成为Follower服务器。leader服务器负责将一个客户端事务请求转换成一个Proposal（提议），并将Propsal分发给集群中所有的Follower服务器，之后leader服务器需要等待所有的Follower服务器的反馈，一旦超过一半的Follower服务器进行了正确的反馈后，那么leader就会再次向所有的Follower服务器分发Commit消息，要求其将前一个Proposal进行提议