标签：事务 56 系统 重试 淘东 支付 电商 第三方 分布式

引言

在上一篇博客《淘东电商项目（55） -支付系统核心表设计》，主要讲解支付系统的数据表结构设计。

本文主要讲解支付系统的分布式事务的问题，以及解决方案。

本文目录结构：
l____引言
l____ 1. 支付流程
l____ 2. 分布式事务的几个问题

1. 支付流程

下面我贴出一个简单的支付流程：

以上是用户提交订单到支付系统的大致流程，当然里面涉及到最重要的一个问题就是分布式事务的问题，下面来讲解下。

2. 分布式事务的几个问题

① 在网络延迟情况下，回调接口出现重试时，如何保证接口幂等性问题？（举例：第三方系统异步回调成功支付结果给支付系统）

• 答：使用全局id的方式，如果再次请求时，根据全局id查询数据库，如果发现已经修改了数据，确认已接收到消息（ 重试机制是间隔性）。

②在网络延迟情况下，第三方系统没有及时的将支付结果通知给商户端，存在支付状态不一致时，如何解决?

• 答：一般第三方系统会提供查询结构，可以调用第三方系统主动查询支付状态。

③商户系统回调接口中，如果存在代码问题，或者是商户系统宕机，导致第三方支付系统一直在重试？ 最后放弃重试 如何解决呢?

• 答：方法一:“手动补偿机制+日志记录 主动调用第三方接口查询”；方法二：“写一个定时Job，每天定时检查数据”。

④支付金额与商品金额如果不一致时，如何处理?

• 答：在异步回调中，使用预支付金额与回调真实支付金额进行比对，如果不一致的话，说明该交易信息存在异常。可以使用日志+对账核查。

⑤支付服务如何与其他系统保证分布式事务问题?

• 答：采用第三方支付流程实现补偿和重试机制遵循最终一致性 Base理论和CAP理论。

⑥与内部系统中出现分布式事务问题

• 答：可以使用框架LCN、 MQ 、TCCC。

标签：事务,56,系统,重试,淘东,支付,电商,第三方,分布式
来源： https://blog.51cto.com/u_15294985/3007930

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。