1.从Paxos到Zookeeper分布式一致性原理与实践---分布式架构

 

  1.有些系统，既要快速响应用户，同时还要保证系统的数据对任意客户端都是真实可靠的，比如火车票站的售票系统。
  2.有些系统，需要为用户保证绝对可靠的数据安全，虽然在数据一致性存在延时，但最终务必保证严格的一致，比如银行转账系统。
  3.有些系统，虽然向用户展示了一些可以说是'错误'的数据，但是在整个系统使用过程中，一定会在某个流程上对系统数据进行准确无误的检查，
  从而避免用户发现不必要的损失，比如网购系统。

  并发:如果逻辑控制流在时间上重叠，那么它们就是并发的。这里提到的逻辑控制流，通俗的讲，就是一次程序操作，比如读取或者更新内存中的变量值。

分布式一致性问题:
	分布式系统对数据的复制需求一般来源于以下2个原因：
	1.为了提高系统的可用性，以防止单点故障引起的系统不可用
	2.提升系统的整体性能，通过负载均衡技术，能分布在不同地方的数据副本都能提供服务

	所谓的分布式一致性问题，是指在分布式环境中引入数据复制机制后，不同数据节点间可能出现的，并无法依靠计算机应用程序自身解决数据不一致的情况。
  简单的说，数据不一致就是指对一个副本数据进行更新的同时，必须确保也能够更新其他的副本，否则不同副本之间的数据将不再一致。

    如何解决：既然是由于延时引起的问题，那么我可以将写入的动作阻塞，直到数据复制完成后，才完成写入动作。但这又带来新的问题：写入的性能。后续
  所有的写入都将会阻塞在前一个请求的写操作上，系统的性能急剧下降。

    如何保证数据一致性，同时不影响系统的性能，是每一个分布式系统都需要重点考虑和权衡。于是，出现了如下一致性级别：
    1.强一致性
    	这种一致性级别是最符合用户直觉的，它要求系统写入什么，读出来的也会是什么，用户体验最好，但实现起来往往对系统的性能影响比较大。

    2.弱一致性
    	这种一致性级别约束了系统在写入成功后，不承诺立即可以读到写入的值，也不具体承诺多久之后数据能够达到一致，但会尽可能的保证到了某个时间
      级别(比如秒级别)后，数据能够达到一致性状态。弱一致性状态还可以再细分：
      	1.会话一致性
      		该一致性级别只保证对写入的值，在同一个客户端会话中可以立即读到一致的值，但其他的会话不能保证
      	2.用户一致性
      		该一致性级别只能保证对写入的值，在同一个用户中可以立即读到一致的值，但其他用户不能保证。

    3.最终一致性
    	最终一致性是弱一致性的一个特例，系统会保证在一定时间内，能够达到一个数据一致的状态。之所以单独拎出来，是因为它是弱一致性中非常重要的一种
      一致性模型，也是业界在大型分布式系统的数据一致性比较推崇的模型。


1.分布式特点
	定义：分布式系统是一个硬件和软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。
	一个分布式系统中的计算机在空间部署上可以是随意分布的，这些计算机可能被放在不同的机柜上，也可能在不同的机房中，甚至分布在不同的城市。无论如何，
  一个标准的分布式系统在没有任何特定业务逻辑约束的情况下，都会有如下特征：
  1.分布式
  	分布式系统中的多台计算机都会在空间上随意分布，同时，机器的分布情况也会随时变动。

  2.对等性
  	分布式系统中的计算机没有主从之分，既没有控制整个系统的主机，也没有被控制的从机，组成分布式系统的所有计算机节点都是对等的。副本是分布式系统最常见
  的概念之一，指的是分布式系统对数据和服务提供的一种冗余方式。在常见的分布式系统中，为了对外提供高可用的服务，我们往往会对数据和服务进行副本处理。数据
  副本是指在不同节点上持久化同一份数据，当某一节点上存储的数据丢失时，可以从副本上读取到该数据，这是解决分布式系统数据丢失问题最为有效的手段。另外一类
  副本是服务副本，指多个节点提供同样的服务，每个节点都有能力接收来自外部请求并进行相应的处理。

  3.并发性
  	在一个计算机网络中，程序运行过程中的并发性操作是非常常见的行为。例如在一个分布式系统中的多个节点，可能会并发的操作一些共享的资源，诸如数据库或分布式
  存储等，如何准确高效的协调分布式并发操作也称为了分布式系统架构和设计中最大的挑战之一。

  4.缺乏全局时钟
  	一个典型的分布式系统是由一系列在空间上随意分布的多个进程组成，具有明显的分布性，这些进程之间通过交换消息来进行通信。因此，在分布式系统中，很难定义2个
  事件究竟谁先谁后，原因就是业务分布式系统缺乏一个全局的时钟序列控制。

  5.故障总会发生
  	组成分布式系统的所有计算机，都有可能发生任何形式的故障。一个被大量工程实践所验证过的黄金定理是：任何在设计阶段考虑的异常情况，一定会在系统实际运行中
  发生，并且，在系统实际运行过程中还会遇到很多在设计时未能考虑的异常事故。所以，除非需求指标允许，在系统设计时不能放过任何异常情况。


2.分布式环境的各种问题
	1.通信异常
		从集中式向分布式演变过程中，必然引入网络因素，而由于网络本身的不可靠性，因此引入额外的问题。分布式系统需要在各个节点之间进行网络通信，因此每次
	  网络通信都会伴随着网络不可用的风险。另外，即使分布式系统各节点之间的网络能正常进行，其延时也会远大于单机操作。通常我们认为在现代的计算机结构中，
	  单机内存访问的延时在纳秒级(通常是10ns左右)，而正常一次网络通信的延时在0.1~1ms 左右(相当于内存访问的 105~106倍)。如此巨大的延时差别，会影响
	  消息的收发过程，因此消息丢失和消息延迟变得非常普遍。

	2.网络分区
		当网络由于发生异常情况，导致分布式系统中部分节点之间的网络延时不断增大，最终导致组成分布式系统的所有节点中，只有部分节点之间能够正常通信，而另外
	  一些节点则不能---我们将这个现象称为网络分区，就是俗称的'脑裂'。当网络分区出现的时候，分布式系统会出现局部小集群，在极端情况下，这些局部小集群会独立
	  完成原本需要整个分布式系统才能完成的功能，包括对数据的事务处理，这就对分布式一致性提出了非常大的挑战。

	3.三态
		分布式系统的每一次请求与响应，存在特有的'三态'概念，即成功，失败与超时。在传统的单机系统中，应用程序在调用一个函数之后，能够得到一个非常明确的响应：
	  成功或者失败。而在分布式系统中，由于网络不可靠的，虽然在绝大部分情况下，网络通信也能接收到成功或失败的响应，但是当网络出现异常的情况下，就可能出现超时
	  现象，通常有以下2种情况：
	  1.由于网络原因，该请求并没有成功的发送到接收方，而是在发送的过程中就发生了消息丢失现象。
	  2.该请求成功的被接收方接收后，并进行了处理，但是在将相应反馈给发送方的过程中，发生了消息丢失的情况
	  当出现这样的超时现象时，网络通信的发起方是无法确定当前请求是否被成功处理的。

	4.节点故障
		节点故障则是分布式环境下另外一个比较常见的问题，指的是组成分布式系统的服务器节点出现宕机或者'僵死'现象。


3.从 ACID 到 CAP/BASE
	1.ACID
		事务(Transaction)是由一系列对系统中数据进行访问与更新的操作所组成的一个程序执行逻辑单元，狭义上的事务是特指数据库事务。一方面，当多个应用程序并发
	  访问数据库时，事务可以在这些应用程序之间提供一个隔离的方法，以防止彼此的操作互相干扰。另外一方面，事务为数据库操作序列提供了一个从失败中恢复到正常状态
	  的方法，同时提供了数据库即使在异常状态下仍然能保持数据一致性的方法。
	  	事务具有4个特指，分别是原子性，一致性，隔离性，和持久性，简称事务的ACID特性。
	  	1.原子性
	  		事务的原子性是指事务必须是一个原子的操作序列单元。事务中包含的各项操作在一次执行过程中，只允许出现下面2种状态之一：
	  		1.全部执行成功
	  		2.全部不执行
	  		任何一项操作失败都将导致整个事务失败，同时其他已经被执行的操作都将被撤销并回滚，只有所有的操作全部成功，整个事务才算成功。

	  	2.一致性
	  		事务的一致性是指事务的执行不能破坏数据库的完整性和一致性，一个事务在执行之前和之后，数据库都必须处于一致性状态。也就是说，事务执行的结果必须是使
	  	  数据库从一个一致性状态转变为另一个一致性状态。因此当数据库只包含成功事务提交的结果时，就能说数据库处于一致性状态了。而如果数据库系统在运行过程中发生
	  	  故障，有些事务尚未完成就被迫中断，这些未完成的事务对数据库所做的修改有一部分已经写入物理数据库，这时数据库就处于一种不正确的状态，或者说不一致的状态。

	  	3.隔离性
	  		事务的隔离性是指在并发环境中，并发的事务是互相隔离的，一个事务的执行不能被其他事务干扰，也就是说，不同的事务并发操作相同的数据时，每个事务都有各自完整
	  	  的数据空间，即一个事务内部的操作以及使用的数据对其他并发事务是隔离的，并发执行的各个事务之间不能互相干扰。
	  	    在标准的sql规范中，定义了4个事务隔离级别，不同的隔离级别对事务的处理是不同的。
	  	    1.未提交读
	  	    	未授权读也叫未提交读，该隔离级别允许脏读，其隔离级别是最低的。换句话说，如果一个事务正在处理某一数据，并对其进行了更新，但同时尚未完成事务，因此还
	  	      没有进行事务提交；而与此同时，允许另外一个事务也能够访问该数据。举例，事务A和事务B同时进行，事务A在整个执行阶段，会将某数据项的值从1开始，做一系列的
	  	      加法操作，直到变成10后进行事务提交，此时，事务B能够看到这个数据项在事务A操作过程中的所有中间值(1变成2，2变成3等)，而对这一系列中间值的读取就是未授权
	  	      的读取。

	  	    2.提交读
	  	    	授权读取也被称为已提交读，它和未授权读取非常相近，唯一的区别就是授权读取只允许获取已经被提交的数据，同样以上面的例子，事务A和事务B同时进行，事务A
	  	      进行与上述同样的操作，此时，事务B无法看到这个数据项在事务A操作过程中的中间值，只能看到最终的10。另外，如果说有一个事务C，和事务A进行非常相似的操作，
	  	      只是事务C将数据项从10加到20，此时事务B也同样可以读到20，即授权读取允许不可重复读。

	  	    3.可重复读
	  	    	可重复读，简单的说，就是保证在事务处理过程中，多次读取同一数据时，其值都和事务开始时刻是一致的。因此该事务级别禁止了不可重复读取和脏读取，但是有可能
	  	      出现幻影数据。所谓的幻影数据，就是指同样的事务操作，在前后2个时间段内执行对同一个数据项的读取，可能出现不一致的结果。在上面的例子，可重复读取隔离级别
	  	      能够保证事务B在第一次事务的操作过程中，始终对数据项读取到1，但是在下一次事务操作中，即使事务B(注意，事务名字虽然相同，但是指另外一次事务操作)采用同样
	  	      的操作方式，就可能读取到10或者20.

	  	    4.串行化
	  	    	串行化是最严格的事务隔离级别。它要求所有的事务都被串行化执行，即事务只能一个接一个的处理，不能并发执行。

	  	    事务的隔离级别越高，就越能保证数据的完整性和一致性，但同时对并发性能的影响也越大。通常，对于绝大多数的应用程序来说，可以优先考虑将数据库系统的隔离级别设置
	  	  为提交读，这能够在避免脏读取的同时保证较好的并发性能。尽管这种事务隔离级别会导致不可重复读，虚读和第二类丢失更新等并发问题，但较为科学的做法是在可能出现这类
	  	  问题的个别场合中，由应用程序主动采用悲观锁或乐观锁来进行事务控制。

	  	4.持久性
	  		事务的持久性也称为永久性，是指一个事务一旦提交，它对数据库中对应数据的状态变更就应该是永久性的。换句话说，一旦某个事务成功结束，那么它对数据库所做的更新就必须
	  	  被永久的保存下来---即使发生系统崩溃或机器宕机等故障，只要数据库能够重新启动，那么一定能够将其恢复到事务成功结束时的状态。

	2.分布式事务
		分布式事务是指事务的参与者，支持事务的服务器，资源服务器以及事务管理器分别位于分布式系统的不同节点之上。通常一个分布式事务中会涉及对多个数据源或业务系统的操作。
		一个分布式事务可以看做是由多个分布式的操作序列组成的，通常可以把这一系列分布式的操作序列称为子事务。因此，分布式事务也可以被定义为一种嵌套事务，同时也就具有了
	  ACID 事务特性。但由于在分布式事务中，各个子事务的执行是分布式的，因此要实现一种能够保证ACID特性的分布式事务处理系统就显得额外复杂。

	3.CAP 和 BASE 理论
		对于本地事务或者是集中式的事务处理系统，很显然我们可以采用已经被实践证明很成熟的ACID模型来保证数据的严格一致性。对于一个高访问高并发的互联网分布式系统来说，
	  如果我们期望实现一套严格满足ACID特性的分布式事务，很可能出现的情况是在系统的可用性和严格性之间出现冲突。因为当我们要求分布式系统具有严格一致性时，就可能需要
	  牺牲系统的可用性。

	  1.CAP 定理
	  	CAP 理论告诉我们，一个分布式系统不可能同时满足一致性(C:Consistency),可用性(A:Availability)和分区容错性(P:Partition tolerance)这3个基本需求，
	  最多同时满足2个。
	  	一致性：
	  		在分布式环境中，一致性是指数据在多个副本之间是否能够保持一致的特性。在一致性的需求下，当一个系统在数据一致的状态下执行更新操作后，应该保证系统的数据
	  	  仍然处于一致。
	  	    对于一个将数据副本分布在不同分布式节点上的系统来说，如果对第一个节点的数据进行了更新操作并且更新成功后，却没有使得第二个节点上的数据得到相应的更新，
	  	  于是在对第二个节点的数据进行读取操作时，获取的依然是老数据(脏数据)，这就是典型的分布式数据不一致情况。在分布式系统中，如果能够做到针对一个数据项的更新
	  	  操作执行成功后，所有的用户都可以读取到最新的值，那么这样的系统就认为具有强一致性。

	  	可用性：
	  		可用性是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。
	  		有限的时间是指，对于用户的一个请求，系统必须能够在指定的时间(即响应时间)内返回对应的处理结果。如果超过了这个时间范围，那么系统就被认为是不可用的。
	  	  另外，'有限时间内'是一个在系统设计之初就设定好的系统运行指标，通常不同的系统之间会有很大的不同。
	  	    用户对一个系统的请求响应时间的期望值不尽相同。但是，无论系统之间的差异有多大，唯一相同的一点就是对于用户请求，系统必须存在一个合理的响应时间，否则
	  	  用户便会对系统感到失望。
	  	    返回结果，是可用性的另外一个非常重要的指标，它要求系统在完成对用户请求的处理后，返回一个正常的响应结果。正常的响应结果通常能够明确的反应出对请求的
	  	  处理结果，即成功或者失败，而不是一个让用户感到困惑的返回结果。

	  	分区容错:	
	  		分区容错性约束了一个分布式系统需要具有如下特性：分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个
	  	  网络环境都发生了故障。
	  	    网络分区是指在分布式系统中，不同的节点分布在不同的子网络(机房或者异地网络等)中，由于一些特殊的原因导致这些子网络之间出现网络不连通的情况，但各个子网络
	  	  的内部网络是正常的，从而导致整个系统的网络环境被切分成了若干个孤立的区域。需要注意的是，组成一个分布式系统的每个节点的加入与退出都可以看作是一个特殊的
	  	  网络分区。

	  	CAP 定理应用：
	  		放弃P : 如果希望能够避免系统出现分区容错性的问题，一种较为简单的做法是将所有的数据(或者仅仅是那些与事务相关的数据)都放在一个分布式节点上。这样的做法
	  	  虽然无法100%第保证系统不会出错，但至少不会碰到由于网络分区带来的负面影响。但同时需要注意的是，放弃P的同时也意味着放弃了系统的可扩展性。

	  	    放弃A : 相对于放弃了 '分区容错性' 来说，放弃可用性则正好相反，其做法是一旦系统遇到网络分区或者其他故障，那么受影响的服务需要等待一定的时间，因此在此
	  	  期间系统无法对外提供正常的服务，即不可用。

	  	    放弃C : 这里所说的放弃一致性，并不是完全不需要数据的一致性，如果真的是这样的话，那么系统的数据都是没有意义的，整个系统也是没有价值的。
	  	  事实上，放弃一致性指的是放弃数据的强一致性，而保留数据的最终一致性。这样的系统无法保证数据实时的一致性，但是能够承认的是，数据最终会达到一致性的状态。
	  	  这就引入了一个时间窗口的概念，具体多久达到数据一致性取决于系统的设计，主要包括数据副本在不同节点之间的复制时间长短。

	  	从CAP定理我们可以看出来，一个分布式系统不可能同时满足一致性，可用性和分区容错性这三个需求。另外一方面，需要明确的一点是，对于一个分布式系统而言，分区容错
	  性可以说是一个最基本的要求。为什么这样说，很简单，因为既然是一个分布式系统，那么分布式系统中的组件必然需要被部署到不同的节点，否则也就无所谓分布式系统了，
	  因此必然出现子网络。而对于分布式系统而言，网络问题又是一个必定会出现的异常情况，因此分区容错性也就成为了一个分布式系统必然需要面对和解决的问题。因此系统架构
	  师往往需要把精力花在如何根据业务特点在C(一致性)和A(可用性)之间平衡。

	  2.BASE 理论
	  	BASE 是 Basically Available(基本可用)，Soft state(软状态)，和 Eventually consistent(最终一致性)三个短语的简写。BASE 是对 CAP 中的一致性和
	  可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于CAP定理逐步演化而来的，其核心思想是即使无法做到强一致性(Strong consistency),但
	  每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性(Eventual consistency)。

	    基本可用：
	    	是指分布式系统出现不可预知的故障的时候，允许损失一部分可用性---但注意，这不是等价于系统不可用。例子：
	    	1.响应时间上的损失：正常搜索引擎返回需要0.5s，出现故障的时候，返回需要1~2s
	    	2.功能上的损失：正常情况，电商网站进行购物，消费者能顺利的完成订单，大促的时候，一部分消费者被引导到一个降级的页面。

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

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

	    他认为最终一致性是一种特殊的弱一致性：系统能够保证在没有其他新的更新操作的情况下，数据最终一定能够达到一致的状态，因此所有的客户端对系统的数据访问都能够
	  获取到最新的值。同时，在没有发生故障的前提下，数据达到一致状态的时间延迟，取决于网络延迟，系统负载和数据复制方案设计等因素。
	    在实践过程中，最终一致性存在以下5类变种：
	    1.因果一致性
	    	因果一致性是指，如果进程a在更新完某个数据项后通知了进程b，那么进程b之后对该数据项的访问都应该能够获得到进程a更新后的最新值，并且如果进程b要对该
	      数据项进行更新操作的话，务必基于进程a更新后的最新值，即不能发生丢失更新的情况。与此同时，与进程a无因果关系的进程c的数据访问则没有此限制。

	    2.读已之所写
	    	读己之所写是指，进程a更新一个数据项后，它自己总是能够访问的到更新过的最新值，而不会看到旧值。也就是说，对于单个数据获取者来说，其读取到的数据，
	      一定不会比自己上次写入的值旧。因此，读己之所写页可以看做是一种特殊的因果一致性。

	    3.会话一致性
	    	会话一致性将对系统的数据的访问过程框定在了一个会话当中：系统能够保证在同一个有效的会话中实现'读己之写写'的一致性，也就是说，执行更新操作之后，
	      客户端能够在同一个会话中看到该数据项的最新值。

	    4.单调读一致性
	    	单调读一致性是指，如果一个进程从系统中读取出一个数据项的某个值后，那么系统对于该进程后续的任何数据访问都不应该返回更旧的值。

	    5.单调写一致性
	    	单调写一致性是指，一个系统需要能够保证来自同一个进程的写操作被顺序的执行。

	在实际系统实践中，可以将其中的若干个变种互相结合起来，以构建一个具有最终一致特性的分布式系统。事实上，最终一致性并不是只有那些大型分布式系统才涉及的特性，
  许多现代的关系型数据库都采用了最终一致性模型。在现代关系型数据库中，大多都会采用同步或异步方式来实现主备数据复制技术。在同步方式中，数据的复制过程通常是更新事务
  的一部分，因此在事务完成后，主备数据库的数据就会达到一致。而在异步方式中，备库的更新往往存在延时，这取决于事务日志在主备数据库之间传输的时间长短，如果传输时间
  过长或者在日志传输过长出现异常导致无法及时将事务应用到备库上，那么很显然，从备库中读取的数据将是旧的，因此出现了数据的不一致的情况。当然，无论是多次重试还是人为
  数据修订，关系型数据库还是能够保持最终数据一致。