1.系统介绍
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.业务术语
1.4.模块说明
统一账号服务
用户的登录账号、密码、角色、权限、资源等系统级信息的管理，不包含用户业务信息。
用户中心
提供用户业务信息的管理，如会员信息、实名认证信息、绑定银行卡信息等，“用户中心”的每个用户与“统一账号服务”中的账号关联。
交易中心
提供发标、投标等业务。
还款服务
提供还款计划的生成、执行、记录与归档。
银行存管系统(模拟)
模拟银行存管系统，进行资金的存管，划转。
2.注册账号案例分析
2.1.业务流程
采用用户、账号分离设计(这样设计的好处是，当用户的业务信息发生变化时，不会影响的认证、授权等系统机制)，因此需要保证用户信息与账号信息的一致性。
用户向用户中心发起注册请求，用户中心保存用户业务信息，然后通知统一账号服务新建该用户所对应登录账号。
2.2.解决方案分析
针对注册业务，如果用户与账号信息不一致，则会导致严重问题，因此该业务对一致性要求较为严格，即当用户服务和账号服务任意一方出现问题都需要回滚事务。
根据上述需求进行解决方案分析：
- 1、采用可靠消息一致性方案
可靠消息一致性要求只要消息发出，事务参与者接到消息就要将事务执行成功，不存在回滚的要求，所以不适用。 - 2、采用最大努力通知方案
最大努力通知表示发起通知方执行完本地事务后将结果通知给事务参与者，即使事务参与者执行业务处理失败发起通知方也不会回滚事务，所以不适用。 - 3、采用Seata实现2PC
在用户中心发起全局事务，统一账户服务为事务参与者，用户中心和统一账户服务只要有一方出现问题则全局事务回滚，符合要求。
实现方法如下：
- 1、用户中心添加用户信息，开启全局事务
- 2、统一账号服务添加账号信息，作为事务参与者
- 3、其中一方执行失败Seata对SQL进行逆操作删除用户信息和账号信息，实现回滚。
- 4、采用Hmily实现TCC
TCC也可以实现用户中心和统一账户服务只要有一方出现问题则全局事务回滚，符合要求。
实现方法如下：
-
1、用户中心
try：添加用户，状态为不可用
confirm：更新用户状态为可用
cancel：删除用户 -
2、统一账号服务
try：添加账号，状态为不可用
confirm：更新账号状态为可用
cancel：删除账号
3.存管开户
3.1.业务流程
根据政策要求，P2P业务必须让银行存管资金，用户的资金在银行存管系统的账户中，而不在P2P平台中，因此用户要在银行存管系统开户。
用户向用户中心提交开户资料，用户中心生成开户请求号并重定向至银行存管系统开户页面。用户设置存管密码并确认开户后，银行存管立即返回“请求已受理”。在某一时刻，银行存管系统处理完该开户请求后，将调用回调地址通知处理结果，若通知失败，则按一定策略重试通知。同时，银行存管系统应提供开户结果查询的接口，供用户中心校对结果。
3.2.解决方案分析
P2P平台的用户中心与银行存管系统之间属于跨系统交互，银行存管系统属于外部系统，用户中心无法干预银行存管系统，所以用户中心只能在收到银行存管系统的业务处理结果通知后积极处理，开户后的使用情况完全由用户中心来控制。
根据上述需求进行解决方案分析：
- 1、采用Seata实现2PC
需要侵入银行存管系统的数据库，由于它的外部系统，所以不适用。 - 2、采用Hmily实现TCC
TCC侵入性更强，所以不适用。 - 3、基于MQ的可靠消息一致性
如果让银行存管系统监听 MQ则不合适 ，因为它的外部系统。
如果银行存管系统将消息发给MQ用户中心监听MQ是可以的，但是由于相对银行存管系统来说用户中心属于外部系统，银行存管系统是不会让外部系统直接监听自己的MQ的，基于MQ的通信协议也不方便外部系统间的交互，所以本方案不合适。 - 4、最大努力通知方案
银行存管系统内部使用MQ，银行存管系统处理完业务后将处理结果发给MQ，由银行存管的通知程序专门发送通知，并且采用互联网协议通知给第三方系统（用户中心）。
下图中发起通知即银行存管系统：
4.满标审核
4.1.业务流程
在借款人标的募集够所有的资金后，P2P运营管理员审批该标的，触发放款，并开启还款流程。
管理员对某标的满标审批通过，交易中心修改标的状态为“还款中”，同时要通知还款服务生成还款计划。
4.2.解决方案分析
生成还款计划是一个执行时长较长的业务，不建议阻塞主业务流程，此业务对一致性要求较低。
根据上述需求进行解决方案分析：
- 1、采用Seata实现2PC
Seata在事务执行过程会进行数据库资源锁定，由于事务执行时长较长会将资源锁定较长时间，所以不适用。 - 2、采用Hmily实现TCC
本需求对业务一致性要求较低，因为生成还款计划的时长较长，所以不要求交易中心修改标的状态为“还款中”就立即生成还款计划 ，所以本方案不适用。 - 3、基于MQ的可靠消息一致性
满标审批通过后由交易中心修改标的状态为“还款中”并且向还款服务发送消息，还款服务接收到消息开始生成还款计划，基本于MQ的可靠消息一致性方案适用此场景 。 - 4、最大努力通知方案
满标审批通过后由交易中心向还款服务发送通知要求生成还款计划，还款服务并且对外提供还款计划生成结果校对接口供其它服务查询，最大努力 通知方案也适用本场景 。