Zookeeper系列，会从分布式一致性理论开始介绍，设计诸如：CAP，BASE理论，分布式一致性算法：2PC,3PC,Paxos,ZAB以及Zookeeper的节点特性，Zookeeper如何保证一致性及高可用，最后会介绍zk的各种应用。
关于数据的一致性，我们在数据库中有了解过，因为数据库事务的ACID特性的C就代表一致性，这ACIC可以简单的把一致性理解为正确性或者完整性，那么数据一致性通常指关联数据之间的逻辑关系是否正确和完整。我们知道，在数据库系统中通常用事务（访问并可能更新数据库中各种数据项的一个程序执行单元）来保证数据的一致性和完整性。那么，我们现在所说的分布式一致性指的是什么呢？为什么会出现一致性的问题？我们必须首先解决这个疑问，才能继续探究各种分布式一致性的理论与相关算法。
分布式的问题
我们先来介绍一下，为什么要分布式？随着大型网站的各种高并发访问、海量数据处理等场景越来越多，如何实现网站的高可用、易伸缩、可扩展、安全等目标就显得越来越重要。为了解决这样一系列问题，大型网站的架构也在不断发展。提高大型网站的高可用架构，不得不提的就是分布式。集中式系统用一句话概括就是：一个主机带多个终端。终端没有数据处理能力，仅负责数据的录入和输出。而运算、存储等全部在主机上进行。现在的银行系统，大部分都是这种集中式的系统，此外，在大型企业、科研单位、军队、政府等也有分布。集中式系统，主要流行于上个世纪。集中式系统的最大的特点就是部署结构非常简单，底层一般采用从IBM、HP等厂商购买到的昂贵的大型主机。因此无需考虑如何对服务进行多节点的部署，也就不用考虑各节点之间的分布式协作问题。但是，由于采用单机部署。很可能带来系统大而复杂、难于维护、发生单点故障（单个点发生故障的时候会波及到整个系统或者网络，从而导致整个系统或者网络的瘫痪）、扩展性差等问题。
对于淘宝，腾讯等亿级用户量以及复杂的业务逻辑，且不说耦合严重，难于维护，单是这么庞大的并发量，集中式机构根本扛不住，所以就得需要进行分布式了，从2009年开始，阿里就启动了去“IOE”计划，其电商系统正式迈入分布式系统时代。分布式系统是一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。可以将不同的业务模块，数据进行水平切分部署。分布式意味着可以采用更多的普通计算机（相对于昂贵的大型机）组成分布式集群对外提供服务。计算机越多，CPU、内存、存储资源等也就越多，能够处理的并发访问量也就越大。
分布式因为网络的不确定性，节点故障等情况，会带来各种复杂的问题。我们在学习分布式的相关理论时，一定要明确这样一个道理，就是：网络不可靠，网络分区以及节点宕机是常态，另外网络带宽资源是及其珍贵的，我们必须在网络不可靠、分区以及节点宕机的前提下，构建高性能、高可用的分布式系统。
分布式环境的问题有：
通信异常：从集中式向分布式演变过程中，必然会引入网络因素，而由于网络本身的不可靠性，因此也引入了额外的问题。分布式系统需要在各个节点之间进行网络通信，因此当网络通信设备故障就会导致无法顺利完成一次网络通信，就算各节点的网络通信正常，但是消息丢失和消息延时也是非常普遍的事情。
网络分区（脑裂）：网络发生异常情况导致分布式系统中部分节点之间的网络延时不断增大，最终导致组成分布式系统的所有节点，只有部分节点能够正常通行，而另一些节点则不能。我们称这种情况叫做网络分区（脑裂），当网络分区出现时，分布式系统会出现多个局部小集群（多个小集群可能又会产生多个master节点），所以分布式系统要求这些小集群要能独立完成原本需要整个分布式系统才能完成的功能，这就对分布式一致性提出了非常大的挑战。
节点故障：节点宕机是分布式环境中的常态，每个节点都有可能会出现宕机或僵死的情况，并且每天都在发生。
三态：由于网络不可靠的原因，因此分布式系统的每一次请求，都存在特有的“三态”概念，即：成功，失败与超时。在集中式单机部署中，由于没有网络因素，所以程序的每一次调用都能得到“成功”或者“失败”的响应，但是在分布式系统中，网络不可靠，可能就会出现超时的情况。可能在消息发送时丢失或者在响应过程中丢失，当出现超时情况时，网络通信的发起方是无法确定当前请求是否被成功处理的，所以这也是分布式事务的难点。
为什么会有分布式数据一致性问题
在上面，我们介绍了一下分布式和分布式下的一些问题，接下来，我们要讨论，为什么会出现分布式数据一致性问题。因为在分布式系统中，节点宕机是常态，为了高可用性，我们一般会部署多台服务器，势必就会存在数据的复制问题。分布式系统对于数据的复制需求一般来自于以下两个原因：
高可用：将数据复制到分布式部署的多台机器中，可以消除单点故障，防止系统由于某台（些）机器宕机导致的不可用。
性能：通过负载均衡技术，能够让分布在不同地方的数据副本全都对外提供服务。有效提高系统性能。
在分布式系统引入复制机制后，不同的数据节点之间由于网络延时等原因很容易产生数据不一致的情况。复制机制的目的是为了保证数据的一致性。但是数据复制面临的主要难题也是如何保证多个副本之间的数据一致性。
对分布式数据一致性简单的解释就是：当对集群中一个副本数据进行更新的同时，必须确保能够同步更新到其他副本，否则不同副本之间的数据将不再一致。举个例子来说就是：当客户端C1将系统中的一个值K由V1更新为V2，但是客户端C2读的是另一个还没有同步更新的副本，K的值依然是V1,这就导致了数据的不一致性。其中，常见的就是主从数据库之间的复制延时问题。
我们这个系统要重点介绍的分布式一致性协议就是来解决上边的问题的，其中Zookeeper就是分布式一致性问题的工业解决方案，paxos是理论算法，其中zab，raft和众多开源算法是对paxos的工业级实现。Zookeeper使用zab来保证其自身系统的高可用与数据一致性的。
CAP理论
在介绍CAP理论时，我们首先介绍一下分布式事务的概念：分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于分布式系统的不同节点上。通常一个分布式事务会涉及对多个数据源或者业务系统的操作。（这里：例如 MySQL的主从同步更新是否可以看做是分布式事务的一种呢？）
对于本地事务处理或者集中式的事务处理系统，我们可以采用ACID模型来保证数据的严格一致性（事务概念上的）。在分布式系统中，当我们要求分布式系统具有严格一致性时，很可能就需要牺牲掉系统的可用性。如何构建一个兼顾可用性和一致性的分布式系统成为无数工程师探讨的问题，所以出现了诸如CAP和BASE这样的分布式系统经典理论。
CAP是Consistency、Availablity和Partition-tolerance的缩写。分别是指：
1.一致性（Consistency）：每次读操作都能保证返回的是最新数据，在分布式系统中，如果能针对一个数据项的更新执行成功后，所有的用户都可以读到其最新的值，这样的系统就被认为具有严格的一致性。
2.可用性（Availablity）：任何一个没有发生故障的节点，会在合理的时间内返回一个正常的结果，也就是对于用户的每一个请求总是能够在有限的时间内返回结果；
3.分区容忍性（Partition-torlerance）：当节点间出现网络分区（不同节点处于不同的子网络，子网络之间是联通的，但是子网络之间是无法联通的，也就是被切分成了孤立的集群网络），照样可以提供满足一致性和可用性的服务，除非整个网络环境都发生了故障。
CAP理论指出：CAP三者只能取其二，不可兼得。
我们可以分析一下为什么会这样：
首先，如果我们要使网络分区不存在，就必须将系统部署在单个节点上，因为网络总是会出现故障，分区总是存在的，所以当部署在单节点上，可以同时保证CP，但是这时候，就没什么意义了，这都不是分布式了，同时单点故障可能会发生，就不会保证A可用性。
所以我们必须明确一点：对于分布式系统而言，分区容错性是必须要满足的，因为分区的出现时必然，也是必须要解决的问题。所以，P必须要保证，那么我们就要在C和A之间做权衡。
有两个或以上节点时，当网络分区发生时，集群中两个节点不能相互通信（也就是说不能保证可用性A）。此时如果保证数据的一致性C，那么必然会有一个节点被标记为不可用的状态，违反了可用性A的要求，只能保证CP。
反正，如果保证可用性A，即两个节点可以继续各自处理请求，那么由于网络不通不能同步数据，必然又会导致数据的不一致，只能保证AP。
可以不用想到底放弃P，保证CA的时候是怎么弄的，因为P总是存在的，放弃不了。另外，可用性、一致性也是我们一般系统必须要满足的，如何在可用性和一致性进行权衡，所以就出现了各种一致性的理论与算法。
CAP的相关参考
BASE理论
在上边，我们谈到，因为P总是存在的，放弃不了。另外，可用性、一致性也是我们一般系统必须要满足的，如何在可用性和一致性进行权衡，所以就出现了各种一致性的理论与算法。BASE理论是：BASE是指基本可用（Basically Available）、软状态（ Soft State）、最终一致性（ Eventual Consistency）。BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于CAP定理逐步演化而来的，其核心思想是即使无法做到强一致性(Strong consistency)，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性(Eventual consistency)。
在《从Paxos到Zookeeper分布式一致性原理与实践》这本书中，介绍了相关BASE理论：
基本可用：
基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性——但请注意，这绝不等价于系统不可用。以下两个就是“基本可用”的典型例子。
响应时间上的损失：正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了1～2秒。
功能上的损失：正常情况下，在一个电子商务网站上进行购物，消费者几乎能够顺利地完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。
弱状态
弱状态也称为软状态，和硬状态相对，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
最终一致性
最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
注意：最终一致性是一种特殊的弱一致性：系统能够保证在没有其他新的更新操作的情况下，数据最终一定能够达到一致的状态，因此所有客户端对系统的数据访问都能够获取到最新的值。同时，在没有发生故障的前提下，数据达到一致状态的时间延迟，取决于网络延迟、系统负载和数据复制方案设计等因素。
在实际工程实践中，最终一致性存在以下五类主要变种。
1 因果一致性（Causal consistency）
因果一致性是指，如果进程A在更新完某个数据项后通知了进程B，那么进程B之后对该数据项的访问都应该能够获取到进程A更新后的最新值，并且如果进程B要对该数据项进行更新操作的话，务必基于进程A更新后的最新值，即不能发生丢失更新情况。与此同时，与进程A无因果关系的进程C的数据访问则没有这样的限制。
2 读己之所写（Read your writes）
读己之所写是指，进程A更新一个数据项之后，它自己总是能够访问到更新过的最新值，而不会看到旧值。也就是说，对于单个数据获取者来说，其读取到的数据，一定不会比自己上次写入的值旧。因此，读己之所写也可以看作是一种特殊的因果一致性。
3 会话一致性（Session consistency）
会话一致性将对系统数据的访问过程框定在了一个会话当中：系统能保证在同一个有效的会话中实现“读己之所写”的一致性，也就是说，执行更能操作之后，客户端能够在同一个会话中始终读取到该数据项的最新值。
4 单调读一致性（Monotonic read consistency）
单调读一致性是指如果一个进程从系统中读取出一个数据项的某个值后，那么系统对于该进程后续的任何数据访问都不应该返回更旧的值。
5 单调写一致性（Monotonic write consistency）
单调写一致性是指，一个系统需要能够保证来自同一个进程的写操作被顺序地执行。
事实上，最终一致性并不是只有那些大型分布式系统才涉及的特性，许多现代的关系型数据库都采用了最终一致性模型。在现代关系型数据库中，大多都会采用同步和异步方式来实现主备数据复制技术。
1 .在同步方式中，数据的复制过程通常是更新事务的一部分，因此在事务完成后，主备数据库的数据就会达到一致（强一致性）。
- 而在异步方式中，备库的更新往往会存在延时，这取决于事务日志在主备数据库之间传输的时间长短，如果传输时间过长或者甚至在日志传输过程中出现异常导致无法及时将事务应用到备库上，那么很显然，从备库中读取的数据将是旧的，因此就出现了数据不一致的情况。当然，无论是采用多次重试还是人为数据订正，关系型数据库还是能够保证最终数据达到一致——这就是系统提供最终一致性保证的经典案例。
总的来说，BASE理论面向的是大型高可用可扩展的分布式系统，和传统事务的ACID特性是相反的，它完全不同于ACID的强一致性模型，而是提出通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。但同时，在实际的分布式场景中，不同业务单元和组件对数据一致性的要求是不同的，因此在具体的分布式系统架构设计过程中，ACID特性与BASE理论往往又会结合在一起使用。
以上BASE相关的理论来自《从Paxos到Zookeeper分布式一致性原理与实践》。
原文：https://blog.csdn.net/u013679744/article/details/78674779
版权声明：本文为博主原创文章，转载请附上博文链接！