1.CAP协议理论
CAP在分布式系统中主要指的是:一致性(Consistency) 可用性(Available) 分区容错性(Partition Tolerance).但是在分布式系统中无法同时满足三个条件,最多同时满足两个条件,因为P是必须的所以只能在C和A中来选择。
一致性(Consistency)：
指数据在多个副本之间的数据是否能够保持强一致性。
在一致性的需求下，当一个系统在数据一致的状态下执行更新操作后，应该保证系统的数据仍然处于一致的状态。
例如：数据分布在不同分布式节点上，如果对第一个节点的数据进行了更新操作并且更新成功后，其他节点上的数据也应该得到更新，并且所有用户都可以读取到其最新的值，那么这样的系统就被认为具有强一致性（或严格的一致性，最终一致性）。
可用性(Available)：
指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在限定的时间(响应时间)内返回结果,如果超过这个时间范围,那么系统将被认为不可用。
“返回结果”是可用性的另一个非常重要的指标，它要求系统在完成对用户请求的处理后，返回一个正常的响应结果。正常的响应结果通常能够明确的反映出对请求的处理结果，即成功或失败，而不是一个让用户感到困惑的返回结果。
分区容错性(Partition Tolerance)：
分布式系统在遇到任何网络分区故障存储故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。
网络分区是指在分布式系统中，不同的节点分布在不同的子网络（机房或异地网络等）中，由于一些 特殊的原因导致这些子网络之间出现网络不连通的状况，但各个子网络的内部网络是正常的，从而导致整个系统的网络环境被切分成了若干个孤立的区域。需要注意的是，组成一个分布式系统的每个节点的加入与退出都可以看作是一个特殊的网络分区。
由于一个分布式系统无法同时满足上面的三个需求，而只能满足其中的两项，因此在进行对CAP定理的应用的时候，需要根据业务的要求抛弃其中的一项。
因此，将精力浪费在思考如何设计能满足三者的完美系统上是愚钝的，应该根据应用场景进行适当取舍。
1.2一致性的分类
一致性是指从系统外部读取系统内部的数据时,在一定约束条件下相同,数据变动在系统内部各节点应该是同步的。根据一致性的强弱程度不同,一致性分为如下几种：
强一致性(strong consistency)
任何时间,任何用户都能读到最近一次更新的最新数据。
如果数据不一致,就不对外提供服务,保证用户读取的数据始终一致的.
弱一致性
用户无法在确定的时间内读到最新的数据。
客户端写入leader数据后，部分节点因为某些原因未同步到最新数据,且能够容忍部分数据不完整访问不到 则是弱一致性。
单调一致性
如果进程已经获取过数据对象的某个值，那么任何后续访问都不会返回该值之前的值。
任何时间，任何用户一旦读到某个数据在某次更新后的值，那么就不会再读到比这个值更旧的值。也就是说，可获取的数据顺序必是单调递增的。
会话一致性
任何用户在某次会话中，一旦读到某个数据在某次更新后的值，那么在本次会话中就不会再读到比这值更旧的值，会话一致性是在单调一致性的基础上进一步放松约束，只保证单个用户单个会话内的单调性，在不同用户或同一用户不同会话间则没有保障。
最终一致性
用户只能读到某次更新后的值，但系统保证数据将最终达到完全一致的状态，只是所需时间不能保障。
对于一致性，可以分为从客户端和服务端两个不同的视角。从客户端来看，一致性主要指的是多并发访问时更新过的数据如何获取的问题。从服务端来看，则是更新如何复制分布到整个系统，以保证数据最终一致。一致性是因为有并发读写才有的问题，因此在理解一致性的问题时，一定要注意结合考虑并发读写的场景。
2.Zookeeper提供的一致性服务(CP)
顺序一致性
任意特定客户端对数据更新都会按其发送顺序被提交。
如果一个客户端将Znode z的值更新为a，在之后的操作中，它又将z的值更新为b，则没有客户端能够在看到z的值是b之后再看到值a（如果没有其他对z的更新）。
原子性
每个更新要么成功，要么失败。这意味着如果一个更新失败，则不会有客户端会看到这个更新的结果。
单一系统映像
一个客户端无论连接到哪一台服务器，它看到的都是同样的系统视图。
这意味着，如果一个客户端在同一个会话中连接到一台新的服务器，它所看到的系统状态不会比 在之前服务器上所看到的更老。
当一台服务器出现故障，导致它的一个客户端需要尝试连接集合体中其他的服务器时，所有滞后于故障服务器的服务器都不会接受该 连接请求，除非这些服务器能赶上故障服务器。
持久性
一个更新一旦成功，其结果就会持久存在并且不会被撤销。这表明更新不会受到服务器故障的影响。
实时性
在特定的一段时间内，客户端看到的系统需要被保证是实时的（在十几秒的时间里）。在此时间段内，任何系统的改变将被客户端看到，或者被客户端侦测到。
2.1 Zookeeper中的CAP应用
这三个基本需求，最多只能同时满足其中的两项，因为P是必须的,因此往往选择就在CP或者AP中。
在此ZooKeeper保证的是CP。
分析：可用性（A:Available）
不能保证每次服务请求的可用性。任何时刻对ZooKeeper的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性；在数据同步过程中通过锁机制来同步数据。但是它不能保证每次服务请求的可用性（注：也就是在极端环境下，ZooKeeper可能会丢弃一些请求，消费者程序需要重新请求才能获得结果）。所以说，ZooKeeper不能保证服务可用性。
进行leader选举时集群都是不可用。在使用ZooKeeper获取服务列表时，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。所以说，ZooKeeper不能保证服务可用性。
