二：分布式系统事务

一：事务
--->是由一系列对系统中数据进行访问与更新的操作所组成的一个程序执行逻辑单元。保证数据在业务逻辑上是正确的。
--->事务的四大特征：原子性，一致性，隔离性，持久性。简称事务的ACID特性。
●原子性
        要么全部成功执行，要么全部失败。
●一致性
        事务的一致性，数据合乎逻辑。只能从一个一致性状态变到另一个一致性状态。不允许出现中间状态的数据。
●隔离性
        事务的隔离性是指在并发环境中。并发的事务是相互隔离的。一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对其他并发事务是隔离的，并发执行的各个事务之间不能互相干扰。
●持久性
        一旦某个事务成功结束，那么它对数据库所做的更新就必须永久保存下来。即使发生系统崩溃和机器宕机等故障，只要数据库能够重新启动，那么一定能够将其恢复到事务成功结束时的状态




二：分布式事务
--->分布式事务是指事务的参与者，支持事务的服务器，资源服务器以及事务管理器分别位于分布式系统的不同节点上。通常一个分布式事务中会涉及对多个数据源或业务系统的操作。
--->一个分布式事务可以看作是由多个分布式操作序列组成的。通常可以把这一系列分布式的操作序列称为子事务。因此，分布式事务也可以被定义为一种嵌套型的事务，同时也就具有了ACID的事务特性。但由于在分布式事务中，各个子事务的执行是分布式的，因此要实现一种能够保证ACID特性的分布式事务处理系统就显得格外复杂。
--->典型案例：跨行转帐。A银行到B银行转帐。 A银行在往B银行通过消息送加钱操作成功，A银行减钱事务失败。但B银行加钱成功。B银行账户的钱立马被取走。A银行事务回滚。但钱已经被取走了。这个分布式事务就出现问题了。


三：CAP和BASE理论
--->集中式事务和本地事务的处理系统，ACID模型来保证数据的严格一致性。
--->对于分布式事务，简单实现ACID特性，会在系统的可用性和严格的一致性之间出现冲突。
--->可用性对于消费者是不允许我们讨价还价的系统属性
--->一致性是消费者对于应用系统的刚需。
--->如何构建一个兼顾可用性和一致性的分布式系统成为了无数工程师探讨的难题。便有了CAP和BASE这样的分布式系统的经典理论。



三：CAP定理
 



--->分布式系统一致性。
（1）在分布式环境中，一致性是指数据在多个副本之间是否能够保持一致的特性。在一致性的需求下，当一个系统在数据一致的状态下执行更新操作后，应该保证系统的数据仍然处于一致的状态。
（2）对于一个将数据副本分布在不同分布式节点上的系统来说。如果对于第一个节点的数据进行更新操作，并且成功，但没有使得第二个节点上的数据得到相应的更新，于是对于第二个节点的数据进行读取操作时，获取的依然是老数据或者称之为脏数据。这就是典型的分布式数据不一致的情况。如果对于一个节点的数据进行更新，其他所有的节点也进行相应的更新，那么这样的系统就被认为具有强一致性.

--->分布式系统可用性
（1）可用性是指系统提供的服务必须一直处于可用状态，对于用户的每一个操作请求总是能够在有限时间内返回结果。这里我们重点看下“有限的时间内”和“返回结果”
（2）“有限时间内”是指，对一个用户的操作请求，系统必须能够在合理的时间长度内返回对应的处理结果。如果超过了这个时间范围，那么系统就被认为不可用。
（3）“返回结果”是可用性的另一个非常重要的指标，它要求系统在完成对用户请求的处理后，返回一个正常的响应结果。正常的响应结果通常能够明确地反映出对请求的处理结果，即成功或失败，而不是一个让用户感到困惑的返回结果。

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

 

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








四：BASE理论
---->BASE是Basically Available（基本可用），Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写。
---->BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结。是基于CAP定理逐步演化而来的。其核心思想是即使无法做到强一致性（Strong consistency）,但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）
---->BASE三要素
●基本可用
        《1》基本可用是指分布式系统在出现不可预知故障的时候，允许损失部门可用性——但请注意，这绝不等价于系统不可用。以下两个就是“基本可用”典型例子。
        《2》响应时间上的损失：正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障（比如系统部分机房发生断电或断网故障），查询结果的相应时间增加到1~2秒。
        《3》功能上的损失：正常情况下，在一个电子商务网站上进行购物，消费者几乎能够顺利完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。

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

●最终一致性
        《1》最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
        《2》最终一致性是一种特殊的弱一致性：系统能够保证在没有其他新的更新操作情况下，数据最终一定能够达到一致状态，因此所有客户端对系统的数据访问都能够获取到最新的值。同时，在没有发生故障的前提下，数据达到一致状态的时间延迟，取决于网络延迟，系统负载和数据复制方案设计等因素。



五：BASE理论的三要素中最终一致性的五个变种
 ●因果一致性
        --->因果一致性是指，如果进程A在更新完某个数据后通知了进程B，那么进程B之后对该数据的访问都应该能够获取到进程A更新后的最新值，即不能发生丢失更新的情况。与此同时，与进程A无因果关系的进程C的数据访问则没有这样的限制。

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

●会话一致性
        --->绘画一致性将对系统数据的访问过程框定在了一个会话当中，系统能保证在同一个有效的会话中实现“读已之所写”的一致性，也就是说，执行更新操作之后，客户端能够在同一个会话中始终读取到该数据项的最新值。


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


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