首先搞清楚这个场景的业务流程:
1.本地初始化订单支付记录
2.向第三方支付系统发起支付请求
3.等待支付系统响应支付结果
4.更新支付记录状态
5.通知订单支付结果这个业务流程会遇到瓶颈或者问题场景:
1.订单系统发送支付请求出现问题,是不是支持重发的问题
2.如何保证生成支付记录和 发送支付 两个操作的 原子性一致性
3.订单系统重复发送支付的问题
4.第三方的支付系统响应超时的问题针对以上场景的解决方案:
1. 支付请求发送问题及重发支持
解决方案:
重试机制:设计具有指数回退的重试机制。在支付请求发送失败时,有限制地进行重试。
状态检查与补偿:如果发现请求失败数次,记录该事实并可能触发流程以检查本地状态与第三方状态的补偿。
2. 保证支付记录生成和支付请求发送的原子性
解决方案:
事务消息模式:在一个数据库事务中,创建支付记录同时记录一个待发送的支付消息。
该消息会记录在本地消息表中,确保事务的一致性。
使用一个后台进程或服务将在事务提交后读取消息表并发送消息到消息队列。
3. 订单系统重复发送支付的防范
解决方案:
幂等性控制:每个支付请求携带一个唯一客户标识符(例如,orderId或支付ID)来确保请求的幂等性。
后端在接收到支付请求时检查是否已存在相同标识符的活动记录。
数据库中的支付记录应使用唯一约束来防止相同订单的重复处理。
4. 第三方支付系统响应超时
解决方案:
超时设置与处理逻辑:
在发起支付请求时设定合理的超时时间。
超时后,记录日志并设置订单支付状态为待查。
查询与补偿机制:
通过定时任务或独立流程查询第三方支付的实际状态。
接收第三方支付系统回调以获取最终支付结果。
订单支付时请求调用第三方系统的扣款接口,请问如何保证订单一致性?
最后编辑于 :
©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。
推荐阅读更多精彩内容
- 函数式接口概述 函数式接口:有且仅有一个抽象方法的接口(只有这样Java中的Lambda才能顺利推导)Java中的...