分布式事务
目录
3.3 Eventually consistent（最终一致性）
1 前言
现在大多数的系统都是分布式的系统，单体事务的ACID难以满足。因为对于我们一套自己的分布式系统来说，它肯定有许多小的服务（订单服务，商品服务，库存服务等等），而对于再大一些业务场景而言，可能每一个服务都对应了各自的数据库，而各自数据库之间是没有感知的。不能够统筹协作起来。
说到分布式事务之前，就不得不提到本地的事务， 大家都知道本地事务有ACID特性，那么它们是如何保证ACID特性的呢，可以看之前写的一篇博客：
mysql事务及其实现原理--MVCC--二阶段提交_IT盛夏的果实的博客-CSDN博客
2 CAP定理
一致性（Consistency）：指强一致性，在写操作完成后开始的任何读操作都必须返回该值，或者后续写操作的结果。
在一致性系统中，一旦客户端将值写入任何一台服务器并获得响应，那么之后的client从其他任何服务器读取的就是刚写入的数据。
一致性保证了不管向哪台服务器写入数据，其他服务器能实时同步数据
可用性（Availability）： 可用性是指，每次向未崩溃的节点发送请求，总能保证收到响应数据（允许不是最新数据）
分区容忍性（Partition tolerance）：分布式系统在遇到任何网络分区故障的时候，依然能够对外提供满足一致性和可用的服务，也就是说，服务器A和B发送给对方的消息都是可以放弃的，导致无法同步成功，分布式系统要能容忍这种情况。
那么可以试想一下：CAP定理中能够全部同时满足吗？
可以用反正法结合上面的CAP定义来推理下：
如果要同时满足CAP的话，那么需要
C（一致性）：当节点A更新的时候，节点B也要同步更新
A（可用性）：两个节点必须同时保证可用
P（分区容错性）：当节点A，B出现网络分区必须保证对外可用
如果保证一致性：那么节点间数据进行同步，同步期间数据锁定，导致期间的读取失败或超时，破坏了可用性。
如果保证可用性：如果保证可用性，则不允许节点间同步期间锁定，又破坏了一致性。
所以说CAP原则中，不能同时满足三者，要么满足CP,要么满足AP，不能够同时满足。那么能不能满足CA呢？其实也不是不行，只不过很少有人这样选，因为它只适合单体架构。
- 怎样才能同时满足CA?
除非是单体架构
- 什么时候满足CP?
对一致性要求比较高的场景。例如像我们的zookeeper，在服务节点间数据同步，服务对外不可用。
- 什么时候满足AP?
对可用性要求比较高的场景。例如Eureka，必须保证注册中心随时可用，不然拉取不到服务就可能出现问题。
CAP定理告诉我们只能在C、A、P中选择两个条件。而对于系统业务而言，我们往往选择牺牲一致性来换取系统的可用性和分区容错性。不过这里的牺牲一致性并不是完全的放弃一致性，而是牺牲强一致性换取弱一致性（像zookeeper就保证了CP，springcloud就保证了AP）。
一致性拓展：
强一致性：系统中的某个数据更新之后，后续任何对该数据的读操作都将得到更新后的值，对于关系型数据库而言，要求更新过的数据能够被后续的访问都能看到，这就是强一致性。
如果一个集群提供了强一致性，只要集群内部某一台服务的数据发生了改变，那么就需要等待集群内其他服务器的数据同步完成之后，才能正常的对外提供服务。这样保证了强一致性，就损耗了性能。
弱一致性：系统中的某个数据被更改后，后续对该数据的读取操作可能得到更新后的值，也可能是更改前的值。
如果数据更新后，能够容忍后续的访问只能访问到部分或者全部访问不到，则是弱一致性。
最终一致性：是弱一致性的特殊形式，存储系统保证在没有新的更新条件下，最终所有的访问都是更新后的值。
不保证在任意时刻节点上的同一份数据都是相同的，但是随着时间的迁移，不同节点上的同一份数据总是在向趋同的方向变化。（简单来说，就是在一段时间后，节点间的数据最终会达到一致状态）
弱一致性与最终一致性区别：弱一致性即是过了不一致的时间窗口，后续的读取也不一定能保持一致，而最终一致过了不一致的窗口，后续的读取一定一致。
3 Base理论
BASE：全称：Basically Available(基本可用)，Soft state（软状态）,和 Eventually consistent（最终一致性）三个短语的缩写，来自 ebay 的架构师提出。Base 理论是对 CAP 中一致性和可用性权衡的结果，其来源于对大型互联网分布式实践的总结，是基于 CAP 定理逐步演化而来的。其核心思想是：既是无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。
3.1 Basically Available(基本可用)
-
响应时间上的损失：正常情况下的搜索引擎 0.5 秒即返回给用户结果，而基本可用的搜索引擎可以在 1 秒作用返回结果。
-
功能上的损失：在一个电商网站上，正常情况下，用户可以顺利完成每一笔订单，但是到了大促期间，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。
3.2 Soft state（软状态）
允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。
3.3 Eventually consistent（最终一致性）
上面说软状态，然后不可能一直是软状态，必须有个时间期限。在期限过后，应当保证所有副本保持数据一致性。从而达到数据的最终一致性。这个时间期限取决于网络延时，系统负载，数据复制方案设计等等因素。
4 分布式事务解决方案
在分布式系统里，每个节点都可以知道自己操作成功或者失败，却无法知道其他节点操作成功的成功后者失败，当一个事务跨多个节点时，为了保持事务的原子性与一致性，而引入一个协调着来掌控所有参与者的操作结果，并指示它们是否把操作结果进行提交或者回滚。
4.1 二阶段提交（2PC）
二阶段提交是常用的分布式事务解决方案，即将事务的提交过程分为两个阶段（准备阶段，提交阶段）来进行处理。
参与的角色：
协调着：事务的发起者
参与者：事务的执行者
1） 第一阶段（投票阶段）
1 协调者向所有参与者发送事务内容，询问是否可以提交事务
2 各参与者执行事务操作，将undo和redo信息记录事务日志中
3 如果参与者执行成功，给协调者反馈同意，否则反馈终止。
举例：大学期间推选班干部（竞选班长，团支书，生活委员）（参与者），辅导员（协调者）问所有竞选的人准备好没有。各个参与者依次准备看是否具备上台演讲拉票的条件，如果都具备，给协调者反馈
2）第二阶段（提交执行阶段）
当协调者从所有参与者节点或得相应消息为同意时：
1 协调者节点向所有参与者节点发出正式提交的请求
2 参与者节点正式完成操作 并释放在整个事务期间占用的资源
3 参与者节点向协调者发送ack完成消息
4 协调者节点收到所有参与者节点反馈的ack完成消息后，完成事务
举例：辅导云知道所有的参选者都准备好后，向所有参与者发出上台演讲的请求，演讲完成后，向辅导员说我讲完啦，当协调者收到所有的参与者发来的完成消息，完成此次事务。
但是如果任意一个参与者在第一阶段反应的响应消息为中止，或者协调者节点在第一阶段的询问超时时间无法获取所有参与者的响应消息时，则协调者发送回滚操作，取消事务。
优点：
尽量保证了数据的强一致性，适合对数据强一致性要求很高的关键领域
缺点：实现复杂，牺牲了可用性，对性能影响较大，不适合高并发性能场景。
1） 性能问题：执行过程中，所有参与节点都是事务阻塞型的，当参与者占用资源时，其他第三方节点访问公共资源不得不处于阻塞状态
2）可靠性问题：参与者发生故障，协调者需要给每个参与者额外指出超时时机，超时后整个事务失败。协调者发生故障，参与者会一直阻塞下去。需要额外的备机进行容错。
3）数据一致性问题：二阶段无法解决的问题：协调者在发出commit消息后宕机，而接受到这条消息的参与者同时也宕机了。那么即是选举了新的协调者，这条事务状态也是不正确的，没人知道事务是否已经被提交。
4.2 三阶段提交
三阶段提交协议，是二阶段提交协议的改进版本，三阶段提交有两个改进版
- 在协调者和参与者之间都引入超时机制
- 在第一阶段和第二阶段中插入一个准备阶段 。保证在最后提交阶段之前各参与节点的状态是一致的。
也就是说，除了引入了超时机制，3PC将2PC的准备阶段再次一分为2，这样三阶段就有CanCommit、PreCommit、DoCommit三个阶段
阶段一：CanCommit
协调者向参与者发送commit请求，参与者如果可以提交就返回yes，否则就返回no
1 事务询问 ：协调者向所有参与者发出包含事务内容的canCommit请求，询问是否可以提交事务，并等待所有的参与者答复
2 响应反馈 参与者收到commit请求后，如果认为可以执行事务操作，则反馈yes并进入预备状态，否则反馈no
阶段二：PreCommit
协调者根据参与者的反应情况来进行是否可以进行事务的PreCommit操作。根据响应情况，有一下两种肯能。
假如所有的参与者均反馈yes，协调者预执行事务
1 发送预提交请求：协调者向参与者发送PreCommit请求，并进入准备阶段
2 事务预提交：参与者接收到PreCommit请求后，会执行事务操作，将undo和redo信息记录事务日志中（但不提交事务）
3 响应反馈：如果参与者成功执行了事务对象，则返回ACK响应，同时开始等待最终指令
假如有一个参与者向协调者发送了no，或者等待超时之后，协调者都没有接到参与者的响应，那么就执行事务的中断
阶段三：doCommit
所有参照者均反馈doCommit请求，执行真正的事务提交
1 发送提交请求 协调者接收到参与者发送的ack响应，那么他将从预提交状态进入到提交状态，并向所有的参与者发送doCommit请求。
2 事务提交 参与者接收到doCommit请求后，执行真正的事务提交，并释放在整个事务期间占用的资源
3 响应反馈 参与者节点向协调者发送ack完成消息
4 完成事务 协调者节点收到所有参与者的ack完成消息后，完成事务
注意：在doCommit阶段，如果参与者无法接收到协调者的doCommit或者rebort请求，会在等待超时之后，继续进行事务的提交
优点：相比于二阶段提交，三阶段提交降低了阻塞范围，在等待超时之后协调者或者参与者会中断事务。避免了协调者单点问题。阶段3中协调者出现问题时，参与者会继续提交问题
缺点：数据不一致的问题依然存在，当在参与者接收到preCommit请求之后等待do commit指令时，此时如果协调者请求中断事务，而协调者无法参与正常通信，会导致参与者继续提交事务，造成数据不一致。
4.3 TCC
TCC（事务补偿）是一种应用层面侵入业务的两阶段提交。是目前最火的一种柔性事务方案。其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿操作。
1 第一阶段
Try（尝试）：主要是对业务系统做检测及资源预留（加锁，锁住资源）
2 第二阶段
本阶段根据第一阶段的结果。决定是confirm还是cancel
Confirm（确认）：执行真正的业务（执行业务，释放锁）
Cancel（取消）：是预留资源的取消（出问题，释放锁）
优点：
性能提升：具体业务来实现控制资源锁的粒度变小，不会锁定整个资源
数据最终一致性：基于Confirm和Cancel的幂等性，保证事务最终完成或者取消，保证了数据的一致性
可靠性：解决了X协议的协调者单点故障的问题，由主业务方发起并控制整个业务活动，业务活动管理也变得多点，引入集群
缺点：
TCC的Try、Confirm和Cancel操作功能要按具体业务来实现，业务耦合度较高，提高了开发成本
浙公网安备 33010602011771号