LCN分布式事务学习0-分布式事务理论基础
1. 事务概述
1.1 事务的定义
将一个活动涉及到的所有操作纳入到一个不可分割的执行单元，只要其中任一操作执行失败，都将导致整个执行单元回滚。
简单地说，事务提供一种“要么什么都不做，要么做全套（All or Nothing）”机制。
事务具备ACID的特性，即原子性、一致性、隔离性和持久性。
1.2 事务分类
一般而言，常将事务分为如下几种类型的事务：
- 本地事务
- 垮库事务
- 分布式事务
1.2.1 本地事务
即单一进程单一数据源事务。
就是在一个程序中，只操作一个数据的事务，即我们常说的本地事务。当一个系统业务简单、并发量、数据量较小时，可采用这种方式解决数据一致性问题。
1.2.2 跨库事务
即单一进程多数据源事务。
当数据量和并发进一步增大时，虽然可以通过将应用程序集群化，但因为都是操作同一个数据库，而数据库的并发量和数据量达到一定程度后，数据库的性能会急速下降，从而成为整个系统的短板。这时可能就需要进行分库分表，如果进行分库分表，那么就相当于一个进程需要操作多个数据源，为了解决数据一致性问题，就需要跨数据源的事务。
1.2.3 分布式事务
即多进程多数据源事务。
当业务越来越复杂时，传统的单一服务架构模式将会变得越来越沉重，模块与模块间的耦合度越来越高，不利于系统的开发和维护，因此出现了当前比较流行的微服务架构模式。
当系统从单一模式重构成微服务模式时，将会出现一个业务单元需要多个微服务共同完成，也就会出现多个微服务操作各自数据源的情况，从而产生分布式事务问题。
2. 分布式事务
分布式事务指事务的发起者、事务的参与者以及事务管理器分别位于不同节点上，但又要求实现数据一致性的事务。
简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。
本质上来说，分布式事务就是为了保证不同数据库的数据一致性。
假设一个电商下单操作，需要同时创建订单、扣减库存、增加积分这几个操作，只有当这几个操作都成功了，则算下单操作成功。具体如下图所示：
在本地事务中，主要为ACID四大特性（原子性、一致性、隔离性、持久性），而在分布式系统中，主要为CAP和BASE理论。
2.1 CAP理论
- 一致性（C）：在分布式系统完成某个写操作后的任何读操作，都应该获取到该写操作写入的那个最新的值。即数据的强一致性。
- 可用性（A）：即服务一致可用，且读写是正常的响应时间。从性能角度提出的要求，可以理解为高性能。
- 分区容忍性（P）：即部分节点宕机或网络不可用时，系统还能对外提供满足一致性或可用性的服务，是分布式系统的基本要求。即系统的高可用，一般需要通过副本机制实现。
2.1.1 从数据存储角度理解CAP
CP：
- 数据强一致（N1 N2 N3都写成功才算成功）
- 数据有多个副本（N1 N2 N3）
结论：一旦某个节点（如N1）宕机，则系统不可用（因为强一致性要求导致系统写失败）。
AP：
- 可用性（N1 N2 N3只要写成功一个就算成功，剩下的节点异步写入）
- 数据有多个副本（N1 N2 N3）
结论：在异步写入到其他节点前，数据是不一致的。
CA：
- 数据强一致（写入N个节点成功才算成功）
- 可用性（N个节点中只要写成功一个就算成功，剩下的节点异步写入）
结论：N=1即单机版。
redis集群的CAP分析：
假设redis由1主3从构成，集群中只有一个主，数据只要写入主节点就算成功，可以理解为单机。但是，但是，但是，redis在主挂掉后，会从从节点中选举一个切换成主节点（从变主），并且主从切换的时候，服务是不可用的，因此redis是CP，而通过自动主从切换来实现A（可用性），从而保证最终的CAP。
kafka集群和redis集群实现原理一样，因此也是CP的，也是通过自动主从切换来实现A（可用性），从而保证最终的CAP。
2.1.2 从微服务角度理解CAP
假设一个下单功能，需要操作订单系统、库存系统、积分系统三个微服务系统，每个微服务系统自身满足CAP原理。
CP：
- 数据强一致性（三个子系统成功才算成功）
- 多副本（这里应该理解成多个子系统）
结论：假设某个子系统不可用，则整个下单操作就不可用。
AP：
- 调用订单系统成功即下单成功（再异步调用库存和积分系统）
- 多副本（这里应该理解成多个子系统）
结论：在异步调用库存和积分系统之前，数据不一致，即只能查询到订单，但没有扣减库存，没有增加积分。
2.2 总结
分布式系统一般需要满足AP，在通过异步复制数据（微服务需要异步系统调用）的方式来满足数据的最终一致性。
2 BASE理论
BASE理论是对CAP理论的延伸，思想是即使无法做到强一致性（CAP的一致性就是强一致性），但可以采用适当的采取弱一致性，即最终一致性。
BASE是指基本可用（Basically Available）、软状态（ Soft State）、最终一致性（ Eventual Consistency）。
2.2.1 基本可用
基本可用是指分布式系统在出现故障的时候，允许损失部分可用性（例如响应时间、功能上的可用性），允许损失部分可用性。需要注意的是，基本可用绝不等价于系统不可用。
响应时间上的损失：正常情况下搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了1~2秒。
功能上的损失：购物网站在购物高峰（如双十一）时，为了保护系统的稳定性，部分消费者可能会被引导到一个降级页面。
2.2.2 软状态
软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据会有多个副本，允许不同副本同步的延时就是软状态的体现。mysql replication的异步复制也是一种体现。
2.2.3 最终一致性
最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。
3. 分布式事务解决方案
还是以上图为例，假设一个下单操作，需要新增订单成功、扣减库存成功、新增积分成功才算成功。对于两阶段提交和TCC而言，一般都有事务协调者、事务发起者（可以理解成下单服务）和事务参与者（可以理解成订单系统、库存系统、积分系统）3个角色。
3.1 两阶段提交
3.1.1 执行流程
执行一个下单操作时，告诉事务协调者，开启一个分布式事务。
第一阶段如下：
- 各个子系统执行相关业务逻辑代码后，将执行结果告诉协调者，数据未入库；
第二阶段如下：
- 当所有的子事务都执行完时，事务发起者告诉事务协调者，所有子事务都执行完成，事务协调者根据各个子事务执行的结果，广播给各个子事务，是该执行commit还是rollback操作。
3.1.2 优点
- 比较容易实现
- 对原来的业务代码入侵性较小
3.1.3 缺点
- 可能会破坏数据一致性。假设在第一阶段时，还有库存，但最终commit时，库存已经被其他线程更新成0了，这时库存就会被更新成负数。假设在更新库存数据时，数据库连接超时，从而导致扣减库存失败，但新增订单和新增积分却成功了。
3.1.4 开源框架
- LCN
3.2 TCC方案Try-Confirm-Cancel
3.2.1 执行流程
执行一个下单操作时，告诉事务协调者，开启一个分布式事务。
try阶段如下：
- 各个子系统，调用try接口，将数据库的数据锁定，并将执行结果告诉事务协调者，数据入库，但状态为预处理状态。
当所有的子事务都执行完时，事务发起者告诉事务协调者，所有子事务都执行完成，事务协调者根据各个子事务执行的结果，广播给各个子事务，是该执行commit还是rollback操作
confirm阶段如下：
- 各个子事务收到事务协调者的commit消息后，调用confirm接口，更新数据未最终状态。
cancel阶段：
- 各个子事务收到事务协调者的rollback消息后，调用cancel接口，执行回滚操作。
3.2.2 优点
- 在一定程度上保证了数据的一致性问题，至少不会出现库存为负的情况。
3.2.3 缺点
- 开发难道较大，以前只每个服务只需要一个接口（执行业务逻辑），现在需要三个接口，预处理接口、确认接口、回滚接口。
3.2.4 开源框架
- LCN
- seata：阿里巴巴的开源框架
3.3 基于消息中间件的最终一致性方案
3.3.1 执行流程
- 1. 订单服务将数据发送给MQ，此时MQ的数据状态为新增，如果失败，则异常结束。
- 2. 订单服务执行自身逻辑，并将数据持久化，如果失败，则异常结束。
- 3. 订单服务向MQ发送数据确认，此时MQ的数据状态为已确认。如果失败，可以异常结束回滚订单数据库，也可以不回滚订单数据。
下游服务从MQ中获取数据状态为已确认的数据，进行相应业务逻辑的处理。
如果订单服务向MQ发送确认数据失败，且不回滚订单数据，则下游服务还需要从MQ中获取状态为新增的数据，并向订单服务确认该数据是否有效，如果有效，则执行相关业务逻辑，如果无效，则什么都不做。
下游服务可以从MQ主动拉取数据，也可以让MQ主动推送数据到下游服务。
3.3.2 优点
- 系统解耦，各个子系统之间的耦合性降到最低。
3.3.3 缺点
- 数据一致性变弱，只能保证最终一致，对于一致性要求较高的系统不适应。
3.4 总结
两阶段提交和TCC只满足CP，需要通过其他手段来实现可用性；MQ方式只满足AP，也需要通过其他手段来实现最终一致性。