《微服务架构设计模式》读书笔记---第四章：使用Saga管理事务

没有事务处理就不可能保持数据的一致性。跨越多个服务的操作，对于事务管理提出了更高的要求。

微服务架构下的事务管理

我们熟知的一些编程框架和函数提供了API，用于显示的开始、提交或回滚事务。例如，Spring框架提供了注解的方式，采用@Transactional来让方法调用，自动的在事务范围内完成。

在单体应用中，只访问一个数据库，事务管理是简单明了的。
但是对于，微服务框架下，每个服务都有自己的数据库，在这种情况下。就需要跟尾高级的事务管理机制来管理事务。

在多个服务、数据库和消息代理间维护数据一致性的传统方式是，分布式事务。它采用两阶段提交（two phase commit， 2PC）来保证食物中所有参与方同时完成提交，或者失败时同时回滚。

弊端：

分布式事务，的事实标准X/Open XA。实现分布式事务，要求数据库，消息代理，数据库驱动，消息API，都支持XA标准。一些NoSQL数据库（MongoDB），和流行的消息代理（RabbitMQ，Apache Kafka），不支持分布式事务。
分布式事务，本质是同步进程间通信。会降低可用性。

Saga是一种在微服务架构中维护数据一致性的机制。

Saga由一连串的本地事务组成，每个本地事务负责更新自己的私有数据库，这些操作仍旧依赖于我们所熟知的ACID事务框架和函数库。

Saga使用补偿是无来回滚所作出的改变。
传统ACID模式的一个重要特性是，如果业务逻辑检测到违反业务规则，可以轻松回滚事务。
而Saga使用补偿事务，进行回滚。

Saga包含三种类型的事务：

协同式，把Saga的决策和执行顺序逻辑分布在Saga的每个参与方忠，他们通过交换时间的方式来进行沟通。

协同式的参与方，使用发布/订阅进行交互。这就需要考虑通信的可靠性。

好处：

弊端：

编排式，把Saga的决策和执行顺序逻辑集中在一个Saga编排器类中。Saga编排器，发出命令式消息给各个Saga参与方，指示他们完成具体的工作，这个类的唯一职责就是告诉Saga的参与方该做什么事情。
编排器与参与方的交互方式，也是用命令/异步相应的方式。

好处：

弊端：
在编排器中存在集中的过多的业务逻辑的风险。其实就是编排器成为关键节点。

首先理解ACID。

原子性（Atomicity）。原子性是指事务是一个不可分割的工作单位，事务中的操作要么都发生，要么都不发生。
一致性（Consistency）。事务前后数据的完整性必须保持一致。
隔离性（Isolation）。事务的隔离性是多个用户并发访问数据库时，数据库为每一个用户开启的事务，不能被其他事务的操作数据所干扰，多个并发事务之间要相互隔离。
持久性（Durability）。持久性是指一个事务一旦被提交，它对数据库中数据的改变就是永久性的，接下来即使数据库发生故障也不应该对其有任何影响。

使用Saga，缺乏ACID事务中的隔离属性。这是因为，一旦事务提交，每个Saga的本地事务所做的更新都会立即被其他Saga看到。
只会导致以下情况：

有一些对策可以处理缺乏隔离的Saga设计。

语义锁。应用层程序级的锁。方式是，可补偿是无在起创建或者更新记录的时候，设置标志位。这个标志标识该记录尚未提交，且可能会发生更改，用以防止其他事务处理该记录。例如约定Order的状态为*_PENDING，表示一个Saga正在处理该记录。
而对于被阻塞的Saga，1.可以给用户返回错误，让其重试，或者2.等待记录被其他Saga释放。
交换式更新。
悲观视图。重新排序Saga的步骤，以最大限度的降低由于脏读而导致的业务风险。
重读值。Saga在更新之前，重新读取记录，验证是否未更改。
版本文件。记录了对数据执行的操作，以便可以对他们进行重新排序。Saga参与方，记录收到的操作，根据收到的操作，再重新排序。
业务风险评级。低风险使用Saga，高风险使用分布式事务。