分布式事务系统的设计（一）

作者: linking12 | 来源:发表于2017-06-09 18:37 被阅读701次

分布式事务与分布式锁
分布式事务
分布式事务
微服务分布式事务--破局
第二章架构设计之技术实践篇(下)
分布式事务系统的设计（一）
微服务架构及分布式事务解决方案
电商
【转载】分布式一致性解决方案总览
分布式事务系统的设计（二）

1 分布式事务定义

分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。以上是百度百科的解释，简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。

2 分布式事务产生的背景

2.1数据库的分库分表

当数据库单表一年产生的数据超过1000W，那么就要考虑分库分表，具体分库分表的原理在此不做解释，以后有空详细说，简单的说就是原来的一个数据库变成了多个数据库。这时候，如果一个操作既访问01库，又访问02库，而且要保证数据的一致性，那么就要用到分布式事务。

image.png

2.2应用SOA化

所谓的SOA化，就是业务的服务化。比如原来单机支撑了整个电商网站，现在对整个网站进行拆解，分离出了订单中心、用户中心、库存中心。对于订单中心，有专门的数据库存储订单信息，用户中心也有专门的数据库存储用户信息，库存中心也会有专门的数据库存储库存信息。这时候如果要同时对订单和库存进行操作，那么就会涉及到订单数据库和库存数据库，为了保证数据一致性，就需要用到分布式事务。

image.png

3 解决分布式事务所面临的问题

原子性
整个事务中的所有操作，要么全部完成，要么全部不完成，不可能停滞在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。
隔离性
对于并发提交的事务，数据库需要提供并发控制，保证数据库从一个事务的开始状态转换到该事务的结束状态的过程中，中间状态不被其他事务可见，就像事务串行执行一样。
持久性
在事务完成以后，即使发生掉电、系统宕机等错误，该事务对数据库所作的更改仍需持久的保存在数据库中。
一致性
从事务开始到事务结束，数据库的完整性约束（包括外建约束、级连关系、触发器等）不应该因为任何原因被破坏。

4 典型分布式事务场景

4.1 支付

一笔支付，是对买家账户进行扣款，同时对卖家账户进行加钱，这些操作必须在一个事务里执行，要么全部成功，要么全部失败。而对于买家账户属于买家中心，对应的是买家数据库，而卖家账户属于卖家中心，对应的是卖家数据库，对不同数据库的操作必然需要引入分布式事务。

4.2 下单减库存

在消费者点击购买按钮后，交易后台会进行库存检查、下单、减库存、更新订单状态等一连串的服务调用，每一个操作对应一个独立的服务，服务一般会有独立的数据库，因此产生分布式事务问题。

5 常用解决方案

5.1 基于XA协议的两阶段提交

image.png

优点：

XA接口标准化、使用简单，使用成本也很低；
缺点：
性能不理想，很难满足互联网大并发需求。开销大，分布式事务RT相较于单机事务有数量级的差距；分布式事务对相关资源的加锁机制增加了并发冲突，影响到系统吞吐和可伸缩性；
XA要求资源管理必须实现XA接口，对资源管理器提出了要求，限制了业务方的产品选型；
在Mysql数据库中支持的不太理想，mysql的XA实现，没有记录prepare阶段日志，主备切换回导致主库与备库数据不一致。许多nosql也没有支持XA，这让XA的应用场景变得非常狭隘。

5.2 消息事务+最终一致性

5.2.1 业务与消息耦合

在执行服务A时，同时记录消息数据，这个消息数据和服务A的业务数据保存到同一个数据库实例中。

进程1:
Begin local trx：
服务A DML；
push messageQ “call 服务B”;
Commit／Rollback；

进程2:
for eash message in queue
begin local trx:
服务B DML；
commit/rollback;
if trx.success:
pop message;
end if；
end for;

进程1中，由于消息队列和服务A共用数据库资源，可以把消息和服务在单机事务中执行；进程2中，如果服务B执行失败，重新消费消息重试即可；进程2中，如果服务B执行成功、删除消息失败，如果服务B能够实现幂等然后可以重试（可以改造服务B，执行B的事务中，同步插入一行记录描述B是否执行，重试时检查下即可消除对幂等的要求）。

优点：满足业务最终一致要求的同时，有高性能；
缺点：消息系统和资源管理器需要共用数据库资源，不利于业务分层；系统延迟高，没有隔离性；一旦消息产生，后续业务不允许失败，一旦中间某个阶段出现无法继续的情况，即需要人工介入；系统开发成本高，开发人员需要关注分布式事务对业务的影响以及各种状态转换，测试困难，一般来说，开发成本会是不考虑事务的许多倍。

5.2.2 业务与消息解耦

上述方案中，消息资源和业务共用数据库资源，无法解决调用多于2个服务的业务场景，无法应对业务执行顺序发生变更的需求。因此，考虑将业务资源和消息资源解耦。

进程1:
push half message；
Begin local trx：
服务A DML；
Commit／Rollback；
If trx.success
Commit half message;
End if;

进程2:
for eash message in queue
begin local trx:
服务B DML；
commit/rollback;
if trx.success:
pop message;
end if；
end for;

进程1中，首先发送半消息，该消息还不能被消费，然后执行服务A，服务A执行成功后，使半消息生效，否则删除半消息。进程2的执行逻辑与上面相同。
如果服务A执行成功后、使半消息生效前，进程1crash，消息系统会看到一条半消息，但是不知道服务A是否执行成功，所以要求业务实现回调接口，用于检查服务A是否执行成功。

优点：满足业务最终一致的同时，实现高性能；消息数据独立存储，消除业务系统与消息系统间的耦合；
缺点：一次消息发送需要两次请求；业务处理服务需要实现消息状态回查接口；系统延迟高，没有隔离性；一旦消息产生，后续业务不允许失败，一旦中间某个阶段出现无法继续的情况，即需要人工接入；系统开发成本高，开发人员需要关注分布式事务对业务的影响以及各种状态转换，测试困难，一般来说，开发成本会是不考虑事务的许多倍。

6 分布式事务系统解决方案

6.1整体架构

系统分为三种角色：

客户端
客户端通过事务协调器开启／提交分布式事务，通过资源管理器执行业务
资源管理器
资源管理器（主要是数据库系统、消息系统等）负责具体的资源操作，记录必要的事务日志并将执行状态汇报给事务协调器
事务协调器
事务协调器负责分布式事务的推进，为客户端发起的分布式事务请求分配全局唯一的事务ID，并记录资源管理器提交的事务分支的状态，最终负责全局事务的提交或回滚

分布式事务系统通过两阶段提交方式进行分布式事务推进。
1）客户端向事务协调器注册全局事务作为一阶段的开启的标记；
2）分布式事务内的每一次资源（DB或消息）操作，均通过资源管理器进行，资源管理器向事务协调器注册一个事务分支；
3）客户端通知事务协调器进行全局提交／全局回滚作为一阶段完成的标记