分布式事务

分布式对应的是单体架构(单个数据库)，但是随着业务的复杂度提高，逐渐演变出了分布式服务(多个服务)，互相协作，每个服务负责不同的业务，架构如下图：
这种分布式系统环境下由不同的服务之间通过网络远程协作完成事务称之为分布式事务。
简言之：分布式事务就是为了保证不同数据库（微服务）的数据一致性 (跨JVM进程产生分布式事务)

CAP 原则又叫 CAP 定理，同时又被称作布鲁尔定理（Brewer's theorem），指的是在一个分布式系统中，不可能同时满足以下三点。
1、一致性(Consistency)：指强一致性，在写操作完成后开始的任何读操作都必须返回该值，或者后续写操作的结果(更新数据后，其他的服务器能实时同步数据)
                       在一致性系统中，一旦客户端将值写入任何一台服务器并获得响应，那么之后client从其他任何服务器读取的都是刚写入的数据
2、可用性(Availability)：每次向未崩溃的节点发送请求，总能保证收到响应数据（允许不是最新数据）(对数据更新具备高可用性)
3、分区容忍性(Partition tolerance)：即使出现单个组件无法可用，操作依然可以完成(分布式系统要能容忍这种情况，除非整个网络环境都发生了故障。)
分布式系统中，必须满足 CAP 中的 P ，所以只能在 C/A 之间作出取舍。
显然，任何横向扩展策略都要依赖于数据分区(如果选择了CA，舍弃了P，说白了就是一个单体架构)。因此，设计人员必须在一致性与可用性之间做出选择。
在分布式事务的最终解决方案中一般选择牺牲一致性来获取可用性和分区容错性。
一致性可以分为三种：
1、强一致性：系统中的某个数据被成功更新后，后续任何对该数据的读取操作都将得到更新后的值。
2、弱一致性：系统中的某个数据被更新后，后续对该数据的读取操作可能得到更新后的值，也可能是更改前的值。
3、最终一致性：是弱一致性的特殊形式，存储系统保证在没有新的更新的条件下，最终所有的访问都是最后更新的值。
              不保证在任意时刻任意节点上的同一份数据都是相同的，但是随着时间的迁移，不同节点上的同一份数据总是在向趋同的方向变化。
              简单说，就是在一段时间后，节点间的数据会最终达到一致状态。

BASE 理论是对 CAP 中的一致性和可用性进行一个权衡的结果。
BASE 理论的核心思想是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。
BA(Basic Available) 基本可用：整个系统在某些不可抗力的情况下，仍然能够保证"可用性"，即一定时间内仍然能够返回一个明确的结果。这里是属于基本可用。
基本可用和高可用的区别：
1、"一定时间" 可以适当延长，当举行大促（比如秒杀）时，响应时间可以适当延长
2、给部分用户直接返回一个降级页面，从而缓解服务器压力。但要注意，返回降级页面仍然是返回明确结果。
S(Soft State)柔性状态：是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，
                      即允许系统不同节点的数据副本之间进行数据同步的过程存在延时。
E(Eventual Consisstency)最终一致性：同一数据的不同副本的状态，可以不需要实时一致，但一定要保证经过一定时间后仍然是一致的。                      

2PC/3PC：依赖于数据库，能够很好的提供强一致性和强事务性，但相对来说延迟比较高，
         比较适合传统的单体应用，在同一个方法中存在跨库操作的情况，不适合高并发和高性能要求的场景。
TCC：适用于执行时间确定且较短，实时性要求高，对数据一致性要求高。
     比如互联网金融企业最核心的三个服务：交易、支付、账务。
本地消息表/MQ 事务：都适用于事务中参与方支持操作幂等，对一致性要求不高，业务上能容忍数据不一致到一个人工检查周期，
                   事务涉及的参与方、参与环节较少，业务上有对账/校验系统兜底。
Saga 事务：由于 Saga 事务不能保证隔离性，需要在业务层控制并发，适合于业务场景事务并发操作同一资源较少的情况。
           Saga 相比缺少预提交动作，导致补偿动作的实现比较麻烦，例如业务是发送短信，补偿动作则得再发送一次短信说明撤销，用户体验比较差。
           Saga 事务较适用于补偿动作容易处理的场景。