分布式事务学习

本地事务

本地事务，即单机数据库事务，具备AD(Undo,Redo)CI(Lock)原则：

• 原子性：要么全部完成，要么全部不做。
• 一致性：A=500，B=500，A转给B 50，最终A B的和一定是1000。
• 隔离性：事务之间互不影响,以下是四种不同的事务隔离级别，隔离级别的提高代表执行效率的降低：
  • Read Uncommited
  • Read Commited(SqlServer默认级别)
  • Repeatable Read (Mysql默认级别)
  • Serialiable
• 持久性：事务一旦提交，数据完全保存在数据库中，即使停电宕机也如此。

分布式事务

一个简单的例子：

一个请求，需要多个服务共同完成一件事情，其中一个出现问题，即回滚到请求之前的状态。

以上为例，本地事务可以分别保证三个单体服务的事务，但不能保证所有服务共同协作的事务。

二阶段提交

一阶段：在请求到达服务之前，拦截器先将请求提交到事务协调器，由事务协调器预提交请求到服务，确定服务正常。

二阶段：如果服务正常，正常执行请求服务，如果服务异常，进行回滚操作。

缺点：资源占用大，效率低，不能百分百保证事务(一阶段没问题，二阶段出问题)。

二阶段、三阶段理论：https://www.cnblogs.com/balfish/p/8658691.html

三阶段提交

三阶段提交理论是二阶段提交理论的一个进阶版本，将二阶段提交的第一阶段细化为2个阶段，分别是CanCommit与预提交，并引入了超时机制，避免协调者或参与者出现单点故障时，阻塞其他参与者或协调者。

TCC二阶段模型

过程和二阶段提交类似，感觉上是事务逻辑写在了业务代码中，而二阶段提交的协调者更像是中间件的存在，和业务代码耦合低，所以TCC模型会增加开发成本。

Sagas

事件/编排：

多个服务通过事件协作保证数据一致性，服务1完成业务，发布事件，其他服务监听并处理事件，当不再发布事件或最后一个服务执行完事件，说明分布式事务执行完成。

正在执行业务代码的服务发生故障，不会公布新事件 或 服务发布事件，但所有监听事件的服务均宕机     =》 如果有超时机制，应该会整体回滚，如果没有超时机制，其他服务会阻塞吗？

命令/协调：

存在一个协调者，事先读取配置获取当前请求的一个业务流，根据业务流顺序执行每个服务的业务代码，某个服务出问题再反向回滚。

和二阶段提交类似，不过这个只有一个阶段，那为什么二阶段提交需要两个阶段？一个阶段事务出现问题不是照样可以整体回滚吗？难道是没有一个配置list所以不知道对哪些服务做回滚？

二阶段提交第二阶段多服务并发执行，如何保证业务流顺序？

Rocket MQ

支持事务，基于二阶段提交模型，好处是业务系统与消息系统的解耦。

本地消息表

系统与系统之前，通过MQ进行交互，并通过消息表持久化消息数据，达到允许重试与状态标记的目的。