分布式事务的场景分析（六）

前边我们已经学习了四种分布式事务解决方案，2PC、TCC、可靠消息最终一致性、最大努力通知，每种解决方案我们通过案例开发进行学习，本章节我们结合互联网金融项目中的业务场景，来进行分布式事务解决方案可行性分析。

一系统介绍

1.1 P2P介绍

　　P2P 金融又叫 P2P 信贷。其中 P2P 是 peer-to-peer 或 person-to-person 的简写，意思是：个人对个人。P2P 金融指个人与个人间的小额借贷交易，一般需要借助电子商务专业网络平台帮助借贷双方确立借贷关系并完成相关交易手续。借款者可自行发布借款信息，包括金额、利息、还款方式和时间，实现自助式借款；投资者根据借款人发布的信息，自行决定出借金额，实现自助式借贷。

　　目前，国家对 P2P 行业的监控与规范性控制越来越严格，出台了很多政策来对其专项整治。并主张采用“银行存管模式”来规避 P2P 平台挪用借投人资金的风险，通过银行开发的“银行存管系统”管理投资者的资金，每位 P2P 平台用户在银行的存管系统内都会有一个独立账号，平台来管理交易，做到资金和交易分开，让 P2P 平台不能接触到资金，就可以一定程度避免资金被挪用的风险。

什么是银行存管模式？

　　银行存管模式涉及到 2 套账户体系，P2P 平台和银行各一套账户体系。投资人在 P2P 平台注册后，会同时跳转到银行再开一个电子账户，2 个账户间有一一对应的关系。当投资人投资时，资金进入的是平台在银行为投资人开设的二级账户中，每一笔交易，是由银行在投资人与借款人间的交易划转，P2P平台仅能看到信息的流动。

1.2 总体业务流程

1.3 业务术语

术语	描述
银行存管模式	此种模式下，涉及到2套账户体系，P2P平台和银行各一套账户体系。投资人在P2P平台注册后，会同时跳转到银行再开一个电子账户，2个账户间有一一对应的关系。当投资人投资时，资金进入的是平台在银行为投资人开设的二级账户中，每一笔交易，是由银行在投资人与借款人间的交易划转，P2P 平台仅能看到信息的流动。
标的	P2P业内，习惯把借款人发布的投资项目称为“标的”。
发标	借款人在P2P平台中创建并发布“标的”过程。
投标	投资人在认可相关借款人之后进行的一种借贷行为，对自己中意的借款标的进行投资操作，一个借款标可由单个投资人或多个投资人承接。
满标	单笔借款标筹集齐所有借款资金即为满标，计息时间是以标满当日开始计息，投资人较多的平台多数会当天满标。

1.4 模块说明

统一账号服务

用户的登录账号、密码、角色、权限、资源等系统级信息的管理，不包含用户业务信息；

用户中心

提供用户业务信息的管理，如会员信息、实名认证信息、绑定银行卡信息等，“用户中心”的每个用户与“统一账号服务”中的账号关联；

交易中心

提供发标、投标等业务；

还款服务

提供还款计划的生成、执行、记录与归档；

银行存管系统 (模拟)

模拟银行存管系统，进行资金的存管，划转。

二注册账号案例分析

2.1 业务流程

采用用户、账号分离设计(这样设计的好处是，当用户的业务信息发生变化时，不会影响的认证、授权等系统机制)，因此需要保证用户信息与账号信息的一致性。

用户向用户中心发起注册请求，用户中心保存用户业务信息，然后通知统一账号服务新建该用户所对应登录账号。

2.2 解决方案分析

针对注册业务，如果用户与账号信息不一致，则会导致严重问题，因此该业务对一致性要求较为严格，即当用户服务和账号服务任意一方出现问题都需要回滚事务。

根据上述需求进行解决方案分析：

1、采用可靠消息最终一致性方案【不适用】

可靠消息一致性要求只要消息发出，事务参与者接到消息就要将事务执行成功，不存在回滚的要求，所以不适用。

2、采用最大努力通知方案【不适用】

最大努力通知表示发起通知方执行完本地事务后，将结果通知给事务参与者，即使事务参与者执行业务处理失败发起通知方也不会回滚事务，所以不适用。

3、采用 Seata 实现 2PC【适用】

在用户中心发起全局事务，统一账户服务为事务参与者，用户中心和统一账户服务只要有一方出现问题则全局事务回滚，符合要求。

实现方法如下：

　　a）用户中心添加用户信息，开启全局事务；

　　b）统一账号服务添加账号信息，作为事务参与者；

　　c）其中一方执行失败 Seata 根据 undo_log 日志对 SQL 进行逆操作删除用户信息和账号信息，实现回滚。

4、采用 Hmily 实现 TCC【适用】

TCC 也可以实现用户中心和统一账户服务只要有一方出现问题则实现回滚策略，方法如下：

a）用户中心

　　try：添加用户，状态为不可用

　　conﬁrm：更新用户状态为可用

　　cancel：删除用户

b）统一账号服务

　　try：添加账号，状态为不可用

　　conﬁrm：更新账号状态为可用

　　cancel：删除账号

三存管开户

3.1 业务流程

根据政策要求，P2P 业务必须让银行存管资金，用户的资金在银行存管系统的账户中，而不在 P2P 平台中，因此用户要在银行存管系统开户。

　　用户向用户中心提交开户资料，用户中心生成开户请求号并重定向至银行存管系统开户页面。用户设置存管密码并确认开户后，银行存管立即返回“请求已受理”。在某一时刻，银行存管系统处理完该开户请求后，将调用回调地址通知处理结果，若通知失败，则按一定策略重试通知。同时，银行存管系统应提供开户结果查询的接口，供用户中心校对结果。

3.2 解决方案分析

　　P2P 平台的用户中心与银行存管系统之间属于跨系统交互，银行存管系统属于外部系统，用户中心无法干预银行存管系统，所以用户中心只能在收到银行存管系统的业务处理结果通知后，积极处理，开户后的使用情况完全由用户中心来控制。

根据上述需求进行解决方案分析：

1、采用 Seata 实现 2PC【不适用】

需要侵入银行存管系统的数据库，需要侵入银行系统编码实现，由于它的外部系统，所以不适用。

2、采用 Hmily 实现TCC【不适用】

TCC 侵入性更强，需要在银行系统中编码 Try、Confirm、Cancel 三个方法，所以不适用。

3、基于 MQ 的可靠消息一致性【不适用】

如果让银行存管系统监听 MQ 则不合适，因为用户中心是外部系统。

如果银行存管系统将消息发给 MQ，用户中心监听 MQ 是可以的，但是由于相对银行存管系统来说用户中心属于外部系统，银行存管系统是不会让外部系统直接监听自己的 MQ 的，基于 MQ 的通信协议也不方便外部系统间的交互，所以本方案不合适。

4、最大努力通知方案【适用】

银行存管系统内部使用 MQ，银行存管系统处理完业务后将处理结果发给 MQ，由银行存管的通知程序专门发送通知，并且采用互联网协议通知给第三方系统（用户中心）。

下图中发起通知即银行存管系统：

四满标审核

4.1 业务流程

在借款人标的募集够所有的资金后，P2P 运营管理员审批该标的，触发放款，并开启还款流程。

管理员对某标的满标审批通过，交易中心修改标的状态为“还款中”，同时要通知还款服务生成还款计划。

4.2 解决方案分析

生成还款计划是一个执行时长较长的业务，不建议阻塞主业务流程，此业务对一致性要求较低。根据上述需求进行解决方案分析：

1、采用 Seata 实现 2PC【不适用】

Seata 在事务执行过程会进行数据库资源锁定，由于事务执行时长较长会将资源锁定较长时间，所以不适用。

2、采用 Hmily 实现 TCC【不适用】

本需求对业务一致性要求较低，因为生成还款计划的时长较长，所以不要求交易中心修改标的状态为“还款中”就立即生成还款计划，所以本方案不适用。

3、基于 MQ 的可靠消息一致性【适用】

满标审批通过后由交易中心修改标的状态为“还款中”并且向还款服务发送消息，还款服务接收到消息开始生成还款计划，基于 MQ 的可靠消息一致性方案适用此场景。