共计 5652 个字符，预计需要花费 15 分钟才能阅读完成。
最近学习了一下微服务下数据一致性的特点，总结了下目前的保障微服务下数据一致性的几种实现形式如下，以备后查。此篇文章旨在给大家一个基于微服务的数据一致性实现的大略介绍，并未深刻开展，具体的实现形式自己也在持续学习中，如有谬误，欢送大家拍砖。
1. 传统利用的事务管理
1.1 本地事务
再介绍微服务下的数据一致性之前，先简略地介绍一下事务的背景。传统单机利用应用一个 RDBMS 作为数据源。利用开启事务，进行 CRUD，提交或回滚事务，通通产生在本地事务中，由资源管理器（RM）间接提供事务反对。数据的一致性在一个本地事务中失去保障。
1.2 分布式事务
1.2.1 两阶段提交（2PC）
当利用逐步扩大，呈现一个利用应用多个数据源的状况，这个时候本地事务曾经无奈满足数据一致性的要求。因为多个数据源的同时拜访，事务须要跨多个数据源治理，分布式事务应运而生。其中最风行的就是两阶段提交（2PC），分布式事务由事务管理器（TM）对立治理。
两阶段提交分为筹备阶段和提交阶段。
两阶段提交 -commit
两阶段提交 -rollback
然而两阶段提交也不能齐全保证数据一致性问题，并且有同步阻塞的问题，所以其优化版本三阶段提交（3PC）被创造了进去。
1.2.2 三阶段提交（3PC）
三阶段提交
然而 3PC 也只能保障绝大多数状况下的数据一致性。
具体分布式事务 2PC 和 3PC 的具体介绍请见 对于分布式事务、两阶段提交协定、三阶提交协定
。分布式事务不是本文的重点，故不开展。
2. 微服务下的事务管理
那么，分布式事务 2PC 或者 3PC 是否适宜于微服务下的事务管理呢？答案是否定的，起因有三点：
- 因为微服务间无奈间接进行数据拜访，微服务间相互调用通常通过 RPC（dubbo）或 Http API（SpringCloud）进行，所以曾经无奈应用 TM 对立治理微服务的 RM。
- 不同的微服务应用的数据源类型可能齐全不同，如果微服务应用了 NoSQL 之类不反对事务的数据库，则事务基本无从谈起。
- 即便微服务应用的数据源都反对事务，那么如果应用一个大事务将许多微服务的事务管理起来，这个大事务维持的工夫，将比本地事务长几个数量级。如此长时间的事务及跨服务的事务，将为产生很多锁及数据不可用，重大影响零碎性能。
由此可见，传统的分布式事务曾经无奈满足微服务架构下的事务管理需要。那么，既然无奈满足传统的 ACID 事务，在微服务下的事务管理必然要遵循新的法令--BASE 实践。
BASE 实践由 eBay 的架构师 Dan
Pritchett 提出，BASE 实践是对 CAP 实践的延长，核心思想是即便无奈做到强一致性，利用应该能够采纳适合的形式达到最终一致性。BASE 是指根本可用（Basically
Available）、软状态（Soft State）、最终一致性（Eventual Consistency）。
根本可用：指分布式系统在呈现故障的时候，容许损失局部可用性，即保障外围可用。
软状态
：容许零碎存在中间状态，而该中间状态不会影响零碎整体可用性。分布式存储中个别一份数据至多会有三个正本，容许不同节点间正本同步的延时就是软状态的体现。
最终一致性：最终一致性是指零碎中的所有数据正本通过肯定工夫后，最终可能达到统一的状态。弱一致性和强一致性相同，最终一致性是弱一致性的一种非凡状况。
BASE 中的 最终一致性：是对于微服务下的事务管理的基本要求，既基于微服务的事务管理无奈达到强一致性，但必须保障最重一致性。那么，有哪些办法能够保障微服务下的事务管理的最终一致性呢，依照实现原理分次要有两类，事件告诉型和弥补型，其中事件告诉型又可分为牢靠事件告诉模式及最大致力告诉模式，而弥补型又可分为 TCC 模式、和业务弥补模式两种。这四种模式都能够达到微服务下的数据最终一致性。
3. 实现微服务下数据一致性的形式
3.1 牢靠事件告诉模式
3.1.1 同步事件
牢靠事件告诉模式的设计理念比拟容易了解，即是主服务实现后将后果通过事件（经常是音讯队列）传递给从服务，从服务在承受到音讯后进行生产，实现业务，从而达到主服务与从服务间的音讯一致性。首先能想到的也是最简略的就是同步事件告诉，业务解决与音讯发送同步执行，实现逻辑见下方代码及时序图。
public void trans() {
try {
// 1. 操作数据库
bool result = dao.update(data);// 操作数据库失败，会抛出异样
// 2. 如果数据库操作胜利则发送音讯
if(result){mq.send(data);// 如果办法执行失败，会抛出异样
}
} catch (Exception e) {roolback();// 如果产生异样，就回滚
}
}
下面的逻辑看上去浑然一体，如果数据库操作失败则间接退出，不发送音讯；如果发送音讯失败，则数据库回滚；如果数据库操作胜利且音讯发送胜利，则业务胜利，音讯发送给上游生产。而后认真思考后，同步音讯告诉其实有两点有余的中央。
- 在微服务的架构下，有可能呈现网络 IO 问题或者服务器宕机的问题，如果这些问题呈现在时序图的第 7 步，使得音讯投递后无奈失常告诉主服务（网络问题），或无奈持续提交事务（宕机），那么主服务将会认为音讯投递失败，会滚主服务业务，然而实际上音讯曾经被从服务生产，那么就会造成主服务和从服务的数据不统一。具体场景可见上面两张时序图。
- 事件服务（在这里就是音讯服务）与业务过于耦合，如果音讯服务不可用，会导致业务不可用。应该将事件服务与业务解耦，独立进去异步执行，或者在业务执行后先尝试发送一次音讯，如果音讯发送失败，则降级为异步发送。
3.1.2 异步事件
3.1.2.1 本地事件服务
为了解决 3.1.1 中形容的同步事件的问题，异步事件告诉模式被倒退了进去，既业务服务和事件服务解耦，事件异步进行，由独自的事件服务保障事件的牢靠投递。
异步事件告诉-本地事件服务
当业务执行时，在同一个本地事务中将事件写入本地事件表，同时投递该事件，如果事件投递胜利，则将该事件从事件表中删除。如果投递失败，则应用事件服务定时地异步对立解决投递失败的事件，进行从新投递，直到事件被正确投递，并将事件从事件表中删除。这种形式最大可能地保障了事件投递的实效性，并且当第一次投递失败后，也能应用异步事件服务保障事件至多被投递一次。
然而，这种应用本地事件服务保障牢靠事件告诉的形式也有它的不足之处，那便是业务仍旧与事件服务有肯定耦合（第一次同步投递时），更为严重的是，本地事务须要负责额定的事件表的操作，为数据库带来了压力，在高并发的场景，因为每一个业务操作就要产生相应的事件表操作，简直将数据库的可用吞吐量砍了一半，这无疑是无奈承受的。正是因为这样的起因，牢靠事件告诉模式进一步地倒退-内部事件服务呈现在了人们的眼中。
3.1.2.2 内部事件服务
内部事件服务在本地事件服务的根底上更进了一步，将事件服务独立出主业务服务，主业务服务不在对事件服务有任何强依赖。
异步事件告诉-内部事件服务
业务服务在提交前，向事件服务发送事件，事件服务只记录事件，并不发送。业务服务在提交或回滚后告诉事件服务，事件服务发送事件或者删除事件。不必放心业务零碎在提交或者会滚后宕机而无奈发送确认事件给事件服务，因为事件服务会定时获取所有仍未发送的事件并且向业务零碎查问，依据业务零碎的返回来决定发送或者删除该事件。
内部事件尽管可能将业务零碎和事件零碎解耦，然而也带来了额定的工作量：内部事件服务比起本地事件服务来说多了两次网络通信开销（提交前、提交/回滚后），同时也须要业务零碎提供独自的查问接口给事件零碎用来判断未发送事件的状态。
3.1.2.3 牢靠事件告诉模式的注意事项
牢靠事件模式须要留神的有两点，1. 事件的正确发送；2. 事件的反复生产。
通过异步音讯服务能够确保事件的正确发送，然而事件是有可能反复发送的，那么就须要生产端保障同一条事件不会反复被生产，简而言之就是保障事件生产的 幂等性
。
如果事件自身是具备幂等性的状态型事件，如订单状态的告诉（已下单、已领取、已发货等），则须要判断事件的程序。个别通过工夫戳来判断，既生产过了新的音讯后，当承受到老的音讯间接抛弃不予生产。如果无奈提供全局工夫戳，则应思考应用全局对立的序列号。
对于不具备幂等性的事件，个别是动作行为事件，如扣款 100，贷款 200，则应该将事件 id 及事件后果长久化，在生产事件前查问事件 id，若曾经生产则间接返回执行后果；若是新音讯，则执行，并存储执行后果。
3.2 最大致力告诉模式
相比牢靠事件告诉模式，最大致力告诉模式就容易了解多了。最大致力告诉型的特点是，业务服务在提交事务后，进行无限次数（设置最大次数限度）的音讯发送，比方发送三次音讯，若三次音讯发送都失败，则不予持续发送。
所以有可能导致音讯的失落。同时，主业务方须要提供查问接口给从业务服务，用来复原失落音讯。最大致力告诉型对于时效性保障比拟差（既可能会呈现较长时间的软状态），所以对于数据一致性的时效性要求比拟高的零碎无奈应用。这种模式通常应用在不同业务平台服务或者对于第三方业务服务的告诉，如银行告诉、商户告诉等，这里不再开展。
3.3 业务弥补模式
接下来介绍两种弥补模式，弥补模式比起事件告诉模式最大的不同是，弥补模式的上游服务依赖于上游服务的运行后果，而事件告诉模式上游服务不依赖于上游服务的运行后果。首先介绍业务弥补模式，业务弥补模式是一种纯弥补模式，其设计理念为，业务在调用的时候失常提交，当一个服务失败的时候，所有其依赖的上游服务都进行业务弥补操作。
举个例子，小明从杭州登程，去往美国纽约出差，当初他须要定从杭州去往上海的火车票，以及从上海飞往纽约的飞机票。如果小明胜利购买了火车票之后发现那天的飞机票曾经售空了，那么与其在上海再多待一天，小明还不如勾销去上海的火车票，抉择飞往北京再转折纽约，所以小明就勾销了去上海的火车票。这个例子中购买杭州到上海的火车票是服务 a，购买上海到纽约的飞机票是服务 b，业务弥补模式就是在服务 b 失败的时候，对服务 a 进行弥补操作，在例子中就是勾销杭州到上海的火车票。
弥补模式要求每个服务都提供弥补借口，且这种弥补一般来说是 不齐全弥补，既即便进行了弥补操作，那条勾销的火车票记录还是始终存在数据库中能够被追踪（个别是有置信的状态字段“已勾销”作为标记），毕竟曾经提交的线上数据个别是不能进行物理删除的。
业务弥补模式最大的毛病是软状态的工夫比拟长，既数据一致性的时效性很低，多个服务经常可能处于数据不统一的状况。
3.4 TCC/Try Confirm Cancel 模式
TCC 模式是一种优化了的业务弥补模式，它能够做到 齐全弥补 ，既进行弥补后不留下弥补的纪录，就如同什么事件都没有产生过一样。同时，TCC 的软状态工夫很短，起因是因为 TCC 是一种两阶段型模式（曾经忘了两阶段概念的能够回顾一下 1.2.1），只有在所有的服务的第一阶段（try）都胜利的时候才进行第二阶段确认（Confirm）操作，否则进行弥补(Cancel) 操作，而在 try 阶段是不会进行真正的业务解决的。
TCC 模式
TCC 模式的具体流程为两个阶段：
- Try，业务服务实现所有的业务查看，预留必须的业务资源
- 如果 Try 在所有服务中都胜利，那么执行 Confirm 操作，Confirm 操作不做任何的业务查看（因为 try 中曾经做过），只是用 Try 阶段预留的业务资源进行业务解决；否则进行 Cancel 操作，Cancel 操作开释 Try 阶段预留的业务资源。
这么说可能比拟含糊，上面我举一个具体的例子，小明在线从招商银行转账 100 元到广发银行。这个操作可看作两个服务，服务 a 从小明的招行账户转出 100 元，服务 b 从小明的广发银行帐户汇入 100 元。
服务 a（小明从招行转出 100 元）:
try: update cmb_account set balance=balance-100, freeze=freeze+100 where
acc_id=1 and balance>100;
confirm: update cmb_account set freeze=freeze-100 where acc_id=1;
cancel: update cmb_account set balance=balance+100, freeze=freeze-100 where
acc_id=1;服务 b（小明往广发银行汇入 100 元）:
try: update cgb_account set freeze=freeze+100 where acc_id=1;
confirm: update cgb_account set balance=balance+100, freeze=freeze-100 where
acc_id=1;
cancel: update cgb_account set freeze=freeze-100 where acc_id=1;具体阐明：
a 的 try 阶段，服务做了两件事，1：业务查看，这里是查看小明的帐户里的钱是否多余 100 元；2: 预留资源，将 100 元从余额中划入冻结资金。
a 的 confirm 阶段，这里不再进行业务查看，因为 try 阶段曾经做过了，同时因为转账曾经胜利，将冻结资金扣除。
a 的 cancel 阶段，开释预留资源，既 100 元冻结资金，并复原到余额。
b 的 try 阶段进行，预留资源，将 100 元解冻。
b 的 confirm 阶段，应用 try 阶段预留的资源，将 100 元冻结资金划入余额。
b 的 cancel 阶段，开释 try 阶段的预留资源，将 100 元从冻结资金中减去。
从下面的简略例子能够看出，TCC 模式比纯业务弥补模式更加简单，所以在实现上每个服务都须要实现 Cofirm 和 Cancel 两个接口。
3.5 总结
上面的表格对这四种罕用的模式进行了比拟：
| 类型 | 名称 | 数据一致性的实时性 | 开发成本 | 上游服务是否依赖上游服务后果 |
|---|---|---|---|---|
| 告诉型 | 最大致力 | 低 | 低 | 不依赖 |
| 告诉型 | 牢靠事件 | 高 | 高 | 不依赖 |
| 弥补型 | 业务弥补 | 低 | 低 | 依赖 |
| 弥补型 | TCC | 高 | 高 | 依赖 |
起源：https://www.jianshu.com/p/b26…
欢送关注公众号【码农开花】一起学习成长