共计 3769 个字符，预计需要花费 10 分钟才能阅读完成。
全文 4104 字，预计浏览工夫 12 分钟。
一、背景
随着微服务架构的衰亡，越来越多的公司都对本身的业务架构进行了微服务化。在微服务架构中，随着服务的逐步拆分，数据库的私有化已成为业界不成文的规定。因而随同着微服务拆分所带来的数据一致性的问题也愈发重大，如何解决该问题成为微服务架构落地过程中一个十分重要的问题。由此咱们引出分布式事务这一概念，用来解决上述背景带来的问题。在介绍分布式事务之前先让咱们回顾一下什么是事务。
二、事务
事务是数据库操作的最小工作单元，是作为单个逻辑工作单元执行的一系列操作；这些操作作为一个整体一起向零碎提交，要么都执行、要么都不执行；事务具备 ACID 四大属性。
A（Atomic）：原子性，形成事务的所有操作，要么都执行实现，要么全副不执行，不可能呈现局部胜利局部失败的状况。
C（Consistency）：一致性，在事务执行前后，数据库的一致性束缚没有被毁坏。比方：数据库束缚账户余额必须大于 0，所以设置为无符号数，在此束缚下，A 只有 100 元，但要转出 200 元，此时数据库会放弃对束缚的一致性，触发执行回滚。
I（Isolation）：隔离性，数据库中的事务个别都是并发的，隔离性是指并发的两个事务的执行互不烦扰，一个事务不能看到其余事务的运行过程的中间状态。通过配置事务隔离级别能够比防止脏读、反复读问题。
D（Durability）：持久性，事务实现之后，该事务对数据的更改会长久到数据库，且不会被回滚。
理解完了事务的基本概念，接着让咱们看看什么是分布式事务。
三、分布式事务
在分布式系统中，一个利用零碎拆分为独立部署的多个服务，因而须要服务与服务之间近程合作能力实现事务操作，这种分布式系统环境下由不同的服务之间通过网络近程合作实现的事务称为分布式事务。
从架构角度登程，分布式事务根本波及到两大类。
第一类：一个事务申请只波及单体服务，然而会操作多张数据库表，多个数据库表操作实现才示意最终实现。
第二类：一个事务波及多个服务，同时每个服务可能连贯着一个或者多个数据库，须要协同多个独立的服务拜访多个数据存储最终能力实现。
咱们常见的分布式事务来保证数据的一致性的办法分为两类：强一致性、最终一致性。
采纳强一致性的分布式事务的计划：通常采纳两段式提交协定 2PC、三段式提交协定 3PC。在微服务架构中，该种形式不太适宜，起因如下：
因为微服务间无奈间接进行数据拜访，微服务间相互调用通常通过 RPC 或 Http API 进行，所以曾经无奈应用 TM 对立治理微服务的 RM
不同的微服务应用的数据源类型可能齐全不同，如果微服务应用了 NoSQL 之类不原生反对事务的数据库，业务的事务很难实现
即便微服务应用的数据源都反对事务，那么如果应用一个大事务将许多微服务的事务管理起来，这个大事务维持的工夫，将比本地事务长几个数量级。如此长时间的事务及跨服务的事务，将为产生很多锁及数据不可用，重大影响零碎性能
因而咱们个别采纳最终一致性来保障分布式系统的一致性。
常见的最终一致性的分布式事务解决方案有：事件告诉模式（本地异步事件服务模式、内部事件服务模式、MQ 事务音讯模式、最大致力告诉模式）、事务弥补模式（Saga、TCC）。咱们通过调研上述解决方案总结出了以下个性：
上面咱们通过一个业务场景来理解一下什么是分布式事务，并且咱们翻新行业是用什么计划来解决数据一致性问题的。
四、业务场景
假如有一个积分签到零碎，外面有一个签到兑换积分从而兑换物品的性能场景。
咱们要做的事件如下：
- 用户签到胜利、减少用户积分
- 用户创立兑换物品订单，订单状态为已领取
- 扣除用户积分
- 扣减物品库存
- 创立物流出库单
针对以上的业务场景，咱们应该如何实现分布式事务来满足业务须要。上面次要讲事务弥补模式来实现分布式事务。
4.1 TCC 模式
TCC 是将整体业务逻辑的每一个事务提交分成了 Try，Confirm，Cancel 三个操作。
- Try：实现业务的筹备工作
- Confirm：实现业务的提交工作
- Cancel：实现业务的回滚工作
针对上述业务场景，依照业务背景要做的事件，实现一个 TCC 的分布式事务。
如果要实现一个 TCC 的分布式事务，首先要做的是理解业务的主流程以及各个接口提供的业务含意，不间接实现这个业务操作，而是实现一个 Try(预处理) 操作。
例如：给用户增加积分，咱们不间接增加积分，先预处理增加积分。扣物品库存咱们也不间接扣库存，先解冻将扣掉的库存。具体如下图
如果 Try 的逻辑都胜利，TCC 开始执行业务的 Confirm 操作，实现整个事务流程。增加用户积分扣库存等操作。如果 Try 的逻辑局部胜利，有局部有问题，那么开始执行 Cancel 操作，撤销之前执行的所有操作。
总体对于 TCC 模式来说，要做一个分布式事务，业务中的一个接口须要实现 3 个逻辑的革新，Try-Confirm-Cancel。
- 服务调用链路顺次执行 Try 逻辑
- 如果都失常的话，执行 Confirm 逻辑，实现整个业务流程
- 如果局部服务的 Try 逻辑有问题，会执行 Cancel 逻辑，撤销之前执行的所有操作
TCC 模式对于业务的侵入性比拟强，流程比拟繁琐。各个业务侧都须要反对降级。对于咱们翻新行业来说，老本有点大，咱们抉择了另一种模式来实现分布式事务——Saga 模式。
4.2 Saga 模式
Saga 是一种纯业务弥补模式，其设计理念为，业务在调用的时候失常提交，当一个服务失败的时候，所有其依赖的上游服务都进行业务弥补操作。
Saga 的基本概念：
- saga：长事务，long live transaction
- 每个本地事务有对应的弥补事务
- 执行状况
- 失常：T1 -> T2 -> T3 -> … -> Tn
- 异样：T1 -> T2 -> T3（异样）-> C3 -> C2 -> C1
Saga 两种复原策略：
- backward recovery，向后复原，弥补所有已实现的事务（回滚操作）
- forward recovery，向前复原，重试失败的事务，假如每个子事务最终都会胜利（重试操作）
Saga 事务的优缺点：
- 长处：模型比 TCC 更简略，只需业务方提供事务执行接口 transaction、事务勾销弥补接口 cancel
- 毛病：间接执行事务执行接口 transaction，可能有副作用（无论是否回滚，都会执行事务接口的逻辑，举例：A 账号向 B 账号转账，T1 事务对 A 用户扣款，T2 事务对 B 用户加款，T1 执行胜利，同时产生了一条扣款记录，T2 执行失败须要回滚 T2 和 T1，在这个过程中的副作用是 A 账号能感知到金额变动和扣款记录）
针对上述业务背景，咱们对于业务侧只须要反对事务提交的接口（T）和失败弥补的接口（C）即可。具体流程如下图：
对于 Saga 事务来说只有实现跟未实现两种状态。无论是事务全副执行胜利，还是全副弥补胜利都视为实现状态。出现异常导致流程中断为未实现状态。咱们针对于业务提交的流程的 Http Code 状态来辨别是执行向前复原（重试），还是向后弥补（回滚）。对于没有弥补 C 的业务，咱们将采取向前复原，直到胜利。对于异常情况，应用离线弥补的形式对未实现的 Saga 事务进行重做，如长时间无奈实现将触发报警，人工解决。
咱们行创基于上述 saga 模型研发了 Saga 的事务协调器，具体执行流程如下：
业务方应用须要实现对应事务的执行办法和弥补办法，采纳上报分布式事务的形式进行操作，事务上报的数据属性简介：
- Name：本次流程的名称
- OID：申请流程 ID，必须惟一
- Process：每个子流程的属性简介（类型为 list，依照程序执行）
- Transaction：执行事务的流程
- Call：服务调用的形式，HTTP 调用时传 GET、POST 等
- ServiceName：服务名称
- ServiceMethod：调用服务的办法名称，HTTP 传申请的 URL
- Body：POST body，string 类型
- Query：Get Query，map[string]interfase{}
- oid：订单 ID，必传，必须惟一，用于幂等性校验等
- Compensate：执行失败的弥补流程
- Call：服务调用的形式，HTTP 调用时传 GET、POST 等
- ServiceName：服务名称
- ServiceMethod：调用服务的办法名称，HTTP 传申请的 URL
- Body：POST body，string 类型
- Query：Get Query，map[string]interfase{}
- oid：订单 ID，必传，必须惟一，用于幂等性校验等
业务方按上述规定上报数据，该事务会最终保证数据一致性，要么全副胜利，要么都失败回滚。
咱们翻新行业采纳 Saga 模型来实现分布式事务，来解决日常微服务拆分带来的数据一致性的问题，满足了咱们日常的产品性能的须要，解决了辣手的问题。
五、总结
针对分布式事务的解决方案都有各自的特点，没有一个最优的计划，须要结合实际的利用场景抉择适合的模式。
- 2PC 和 3PC 是一种强一致性事务，不过还是有数据不统一，阻塞等危险，而且只能用在数据库层面。
- Saga、TCC 是一种补偿性事务的思维，对业务入侵较大，须要业务方实现对应的办法。
- 本地音讯、事务音讯和最大致力告诉其实都是最终一致性事务，因而实用于一些对工夫不敏感的业务。
举荐浏览：
云原生时代的搜寻服务算力治理
浅谈小程序开源业务架构建设之路
百度小程序包流式下载安装优化
前端工程化之 FaaS SSR 计划
日志中台不重不丢实现浅谈
百度 ToB 垂类账号权限平台的设计与实际