携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第7天，点击查看活动详情
一、系统介绍
1、P2P介绍
P2P金融又叫P2P信贷。其中P2P是 peer-to-peer 或 person-to-person 的简写，意思是：个人对个人。P2P金融指个人与个人间的小额借贷交易，一般需要借助电子商务专业网络平台帮助借贷双方确立借贷关系并完成相关交易手续。借款者可自行发布借款信息，包括金额、利息、还款方式和时间，实现自助式借款;投资者根据借款人发布的信息，自行决定出借金额，实现自助式借贷。
目前，国家对P2P行业的监控与规范性控制越来越严格，出台了很多政策来对其专项整治。并主张采用“银行存管模式”来规避P2P平台挪用借投人资金的风险，通过银行开发的“银行存管系统”管理投资者的资金，每位P2P平台用户在银行的存管系统内都会有一个独立账号，平台来管理交易，做到资金和交易分开，让P2P平台不能接触到资金，就可以一定程度避免资金被挪用的风险。
什么是银行存管模式？
银行存管模式涉及到2套账户体系，P2P平台和银行各一套账户体系。投资人在P2P平台注册后，会同时跳转到银行再开一个电子账户，2个账户间有一一对应的关系。当投资人投资时，资金进入的是平台在银行为投资人开设的二级账户中，每一笔交易，是由银行在投资人与借款人间的交易划转，P2P平台仅能看到信息的流动。
2、总体业务流程
3、业务术语
| 术语 | 描述 |
|---|---|
| 银行存管模式 | 此种模式下，涉及到2套账户体系，P2P平台和银行各一套账户体系。投资人在P2P平台注册后，会同时跳转到银行再开一个电子账户，2个账户间有一一对应的关系。当投资人投资时，资金进入的是平台在银行为投资人开设的二级账户中，每一笔交易，是由银行在投资人与借款人间的交易划转，P2P平台仅能看到信息的流动。 |
| 标的 | P2P业内，习惯把借款人发布的投资项目称为“标的”。 |
| 发标 | 借款人在P2P平台中创建并发布“标的”过程。 |
| 投标 | 投资人在认可相关借款人之后进行的一种借贷行为，对自己中意的借款标的进行投资操作，一个借款标可由单个投资人或多个投资人承接。 |
| 满标 | 单笔借款标筹集齐所有借款资金即为满标，计息时间是以标满当日开始计息，投资人较多的平台多数会当天满标。 |
4、模块说明
统一账号服务：用户的登录账号、密码、角色、权限、资源等系统级信息的管理，不包含用户业务信息。
用户中心：提供用户业务信息的管理，如会员信息、实名认证信息、绑定银行卡信息等，“用户中心”的每个用户与“统一账号服务”中的账号关联。
交易中心：提供发标、投标等业务。
还款服务：提供还款计划的生成、执行、记录与归档。
银行存管系统(模拟)：模拟银行存管系统，进行资金的存管，划转。
二、注册账号案例分析
1、业务流程
采用用户、账号分离设计(这样设计的好处是，当用户的业务信息发生变化时，不会影响的认证、授权等系统机制)，因此需要保证用户信息与账号信息的一致性。
用户向用户中心发起注册请求，用户中心保存用户业务信息，然后通知统一账号服务新建该用户所对应登录账号。
2、解决方案分析
针对注册业务，如果用户与账号信息不一致，则会导致严重问题，因此该业务对一致性要求较为严格，即当用户服务和账号服务任意一方出现问题都需要回滚事务。
根据上述需求进行解决方案分析：
-
采用可靠消息一致性方案
可靠消息一致性要求只要消息发出，事务参与者接到消息就要将事务执行成功，不存在回滚的要求，所以不适用。
-
采用最大努力通知方案
最大努力通知表示发起通知方执行完本地事务后将结果通知给事务参与者，即使事务参与者执行业务处理失败发起通知方也不会回滚事务，所以不适用。
-
采用Seata实现2PC
在用户中心发起全局事务，统一账户服务为事务参与者，用户中心和统一账户服务只要有一方出现问题则全局事务回滚，符合要求。
实现方法如下：
-
用户中心添加用户信息，开启全局事务
-
统一账号服务添加账号信息，作为事务参与者
-
其中一方执行失败Seata对SQL进行逆操作删除用户信息和账号信息，实现回滚。
-
采用Hmily实现TCC
TCC也可以实现用户中心和统一账户服务只要有一方出现问题则全局事务回滚，符合要求。
实现方法如下：
-
用户中心
try：添加用户，状态为不可用
confirm：更新用户状态为可用
cancel：删除用户
-
统一账号服务
try：添加账号，状态为不可用
confirm：更新账号状态为可用
cancel：删除账号
三、存管开户
1、业务流程
根据政策要求，P2P业务必须让银行存管资金，用户的资金在银行存管系统的账户中，而不在P2P平台中，因此用户要在银行存管系统开户。
用户向用户中心提交开户资料，用户中心生成开户请求号并重定向至银行存管系统开户页面。用户设置存管密码并确认开户后，银行存管立即返回“请求已受理”。在某一时刻，银行存管系统处理完该开户请求后，将调用回调地址通知处理结果，若通知失败，则按一定策略重试通知。同时，银行存管系统应提供开户结果查询的接口，供用户中心校对结果。
2、解决方案分析
P2P平台的用户中心与银行存管系统之间属于跨系统交互，银行存管系统属于外部系统，用户中心无法干预银行存管系统，所以用户中心只能在收到银行存管系统的业务处理结果通知后积极处理，开户后的使用情况完全由用户中心来控制。
根据上述需求进行解决方案分析：
-
采用Seata实现2PC
需要侵入银行存管系统的数据库，由于它的外部系统，所以不适用。
-
采用Hmily实现TCC
TCC侵入性更强，所以不适用。
-
基于MQ的可靠消息一致性
如果让银行存管系统监听MQ，则不合适 ，因为它属于外部系统。
如果银行存管系统将消息发给MQ，用户中心监听MQ是可以的，但是由于相对银行存管系统来说用户中心属于外部系统，银行存管系统是不会让外部系统直接监听自己的MQ的，基于MQ的通信协议也不方便外部系统间的交互，所以本方案不合适。
-
最大努力通知方案
银行存管系统内部使用MQ，银行存管系统处理完业务后将处理结果发给MQ，由银行存管的通知程序专门发送通知，并且采用互联网协议通知给第三方系统（用户中心）。
下图中发起通知即银行存管系统：
四、满标审核
1、业务流程
在借款人标的募集够所有的资金后，P2P运营管理员审批该标的，触发放款，并开启还款流程。
管理员对某标的满标审批通过，交易中心修改标的状态为“还款中”，同时要通知还款服务生成还款计划。
2、解决方案分析
生成还款计划是一个执行时长较长的业务，不建议阻塞主业务流程，此业务对一致性要求较低。
根据上述需求进行解决方案分析：
-
采用Seata实现2PC
Seata在事务执行过程会进行数据库资源锁定，由于事务执行时长较长会将资源锁定较长时间，所以不适用。
-
采用Hmily实现TCC
本需求对业务一致性要求较低，因为生成还款计划的时长较长，所以不要求交易中心修改标的状态为“还款中”就立即生成还款计划 ，所以本方案不适用。
-
基于MQ的可靠消息一致性
满标审批通过后由交易中心修改标的状态为“还款中”并且向还款服务发送消息，还款服务接收到消息开始生成还款计划，基本于MQ的可靠消息一致性方案适用此场景 。
-
最大努力通知方案
满标审批通过后由交易中心向还款服务发送通知要求生成还款计划，还款服务并且对外提供还款计划生成结果校对接口供其它服务查询，最大努力通知方案也适用本场景 。
五、总结
| 2PC | TCC | 可靠消息 | 最大努力通知 | |
|---|---|---|---|---|
| 一致性 | 强一致性 | 最终一致 | 最终一致 | 最终一致 |
| 吞吐量 | 低 | 中 | 高 | 高 |
| 实现复杂度 | 易 | 难 | 中 | 易 |
在条件允许的情况下，我们尽可能选择本地事务单数据源，因为它减少了网络交互带来的性能损耗，且避免了数据弱一致性带来的种种问题。若某系统频繁且不合理的使用分布式事务，应首先从整体设计角度观察服务的拆分是否合理，是否高内聚低耦合？是否粒度太小？分布式事务一直是业界难题，因为网络的不确定性，而且我们习惯于拿分布式事务与单机事务ACID做对比。
无论是数据库层的XA、还是应用层TCC、可靠消息、最大努力通知等方案，都没有完美解决分布式事务问题，它们不过是各自在性能、一致性、可用性等方面做取舍，寻求某些场景偏好下的权衡。
