微服务：事务管理

几乎所有的信息管理系统都会涉及到事务，事务的目的是为了保证数据的一致性，这里说的一致性是数据库状态的一致性。

说到数据库状态的一致性，相信大家都会想到 ACID ：

原子性（Atomic）：在一个事件的多个数据库操作中，要么同时成功，要么同时失败，例如：转账业务；
隔离性（Isolation）：不同的业务之间处理数据相互独立，互不影响
持久性（Durability）：正常提交的数据能够被持久化，不丢失数据，比如 mysql 天然就能持久化，redis 、 rabbitmq 也能通过设置进行持久化；
一致性（Consistency）：最终的数据正确，所以说是通过 AID 这些手段来保证了 C 。

在单体架构中，通常是一套程序对应一个数据库，事务基于数据库本身的能力,如果你在 .NET Core 中使用 dapper 或 sqlsugar ，可以很容易进行事务的处理，可以参考下面文档：

https://dapper-tutorial.net/transaction
https://www.donet5.com/Home/Doc?typeId=1183

但是，在微服务架构，分布式的场景中，事务的处理就会变得复杂，会存在多个节点，多个节点的同步、可用性等都是需要考虑的问题，在分布式中有一个著名的 CAP 理论：

C：数据一致性（Consisitency）：分布式中存在多个节点，对某个指定的客户端来说，从任一节点读取数据保证能够获取到最新的写操作结果；
A：可用性（Acailability），非故障的节点在合理的时间内返回合理的响应（不是错误和超时的响应）
P：分区容错性（Partition Tolerance），节点之间的数据传递是基于网络的，由于网络本身不是 100% 可靠，极端情况下会出现网络不可用的情况，进而将网络两端的节点分隔开来，这就是所谓的「网络分区」现象。在出现网络分区时，两部分的数据是不一致的，如果要保证数据的一致性，就必须要让没有及时同步数据的节点变为不可用，这就牺牲了可用性，否则就会牺牲一致性，所以在 P 一定存在的情况下，需要在 C 和 A 中间做取舍。

我们在 CAP、ACID 中讨论的一致性称为「强一致性」（Strong Consistency），而把牺牲了 C 的 AP 系统，但又要保证最终的结果的一致性，称为「弱一致性」，也叫最终一致性。最终一致性的概念由 eBay 的系统架构师丹 · 普利切特（Dan Pritchett）在 2008 年发表于 ACM 的论文「Base: An Acid Alternative」中提出的。

本文主要说下保证一致性的几种方式：TCC、SAGA 和消息队列。

TCC

TCC 是 Try-Confirm-Cancel 的缩写，分为了三个阶段：

Try：一个请求涉及到多个服务，多个服务会同时进行 Try，这个阶段为尝试执行阶段，在这个阶段中会进行数据的校验、检查，保障一致性，并准备资源，都成功会进入到 Confirm 阶段；
Confirm：确认执行阶段，不进行任何业务检查，多个服务的 Try 都执行成功了，多个服务都进入到 Confirm 阶段，在这个阶段直接使用 Try 阶段准备的资源来完成业务处理。注意，Confirm 阶段可能会重复执行，因此需要满足幂等性。
Cancel：如果在 Try 阶段有一个服务没有成功，那么所有的服务都进入到 Cancel 阶段，在该阶段，释放 Try 阶段预留的业务资源。注意，Cancel 阶段也可能会重复执行，因此也需要满足幂等性。

在 .NET Core 中可以参考：

https://github.com/simpleway2016/JMS

在 Java 中可以使用 seata：

https://github.com/seata/seata
https://seata.io/zh-cn/

因为在 TCC 中的第一步 Try 需要预留资源，进行检查和校验，但在某些场景下，资源不是我们所能控制的，比如支付中，余额是银行管理的，我们通常没有权限。所以这时就不太适合 TCC ，可以考虑用 SAGA 来代替 TCC。