分布式日志（一）分布式事务管理

分布式日志系列第一篇，关于分布式事务的学习与理解

分布式事务管理

解决不同进程/微服务同一个事务过程的管理问题，使物理上无关但逻辑上相关事务能够保证一致性、可用性、分区容忍性（CAP）

○CAP理论

• C 即 一致性

  对于数据读取，每次要保证读取的数据是最新修改过的数据，允许调用失败。

• A 即 可用性

  对于服务访问必须得到回复，不允许调用失败，但允许不一致数据。

• P 即 分区容忍性

  允许部分服务出错，但是不能影响系统其他部分的可用性。相当于单体服务分割为微服务。

CAP三者不可兼得，该如何取舍：

1. CA: 优先保证一致性和可用性，放弃分区容错。 这也意味着放弃系统的扩展性，系统不再是分布式的，有违设计的初衷。
2. CP: 优先保证一致性和分区容错性，放弃可用性。在数据一致性要求比较高的场合(譬如:zookeeper,Hbase) 是比较常见的做法，一旦发生网络故障或者消息丢失，就会牺牲用户体验，等恢复之后用户才逐渐能访问。
3. AP: 优先保证可用性和分区容错性，放弃一致性。跟CP一样，放弃一致性不是说一致性就不保证了，而是逐渐的变得一致。

○2PC原理

对多个事务统一管理，即两段式提交。

1. 管理器向事务提交开始的请求，事务响应
2. 管理器像事务提交结束的请求，事务响应（成功或失败）

若其中一个事务开启失败、提交失败则对所有事务进行回滚操作。该原理决定了2PC模式是一种强一致性的模式，能够满足CP要求，但是两次提交会造成较高的代价，性能低下，可能造成单点故障问题导致服务不可用。

○XA方案

XA方案是以2PC原理为基础的一个分布式事务解决方案，该方案依赖于数据库提供本地资源管理器接口，即XA接口的实现，然后通过统一的事务管理器对事务进行管理。

具体过程与2PC原理相似。

○BASE理论

base理论是对2PC理论的改进，具体体现在允许暂时的不一致性从而保证高可用性，最终逐渐达到一致性，与2PC相比，改进后的理论更具有实用性，因为它不在对已完成的事务加锁，从而提高了并发性能。

○Seata-2pc方案

seata是阿里巴巴开源的分布式事务管理框架，基于Base理论。在XA方案的基础上进行了改良，提高了并发性能。

seata是由事务管理器、事务协调器和本地资源管理器构成。

对于事务协调器（TC）能够独立的运行在一个服务器上。在seata中事务管理器不在承担所有功能，也不再使用数据库提供的XA接口。对于每一个相关事务一次提交后即释放锁，因此可能存在读写不一致的问题。

• 事务协调器

  事务协调器执行事务管理器的通知（回滚或提交），记录全局事务与分支事务的关系。

• 事务管理器

  开启全局事务、注册分支事务，嵌入到应用程序当中。

○可靠消息最终一致性方案

通过消息传递来控制事务的进行。

1. 可靠性

   当一个事务成功执行时需要保证一条成功执行的消息发送到消息队列中。同理事务失败时不可发送消息，即消息与事务具有原子性。

2. 最终一致性

   另一个事务要保证收到消息并成功执行事务。

存在问题：最终一致性要求消息接收方事务必须执行成功，因为消息发送方事务无法进行回滚。

○RocketMQ实现

1. 消息预发送

   事务执行前先发送下一个事务执行的消息但不投递，得到ACK回复后开始事务。

2. 消息确认

   1. 事务成功

      事务执行成功后向消息队列发送确认消息，消息队列将消息投递

   2. 事务失败

      事务执行失败则要求消息队列丢弃预发送的消息

   3. 未收到确认

      由于其他不可控因素导致消息队列未收到进一步回复，需要对发起方的事务进行回查。

RockectMQ相当于一个事务的协调器。通过RocketMQLocalTransactionListener接口可用于实现事务的回查。