赞
踩
支付中心系统对内为各个业务线提供统一的支付、退款等服务,对外对接三方支付或银行服务实现资金的流转。如下图:
大部分公司基本都是这样的架构,主要有以下几方面的优点:
上图展示了用户支付的主要流程,分为三个步骤:
下面详细说下这三个步骤:
用户在订单确认页点击“去支付“按钮,调用收银台支付下单接口。
收银台将订单信息缓存并入库,然后将订单标识拼装到收银台URL上返回给订单系统。
订单系统接收到收银台地址跳转到收银台页面。
上图展示了两个业务线(景区业务线,酒店业务线)唤起的收银台页面,大概可以分为三个区域:
页面上部分显示的是支付剩余时间和应付金额;
中间部分是订单信息,根据收银台定义的数据格式,业务线动态传递过来的;
剩余部分展示的是支付渠道,支付渠道也是业务线根据自己的需求在支付后台管理系统配置的,想要哪些支付方式以及它们的顺序都可以自定义。
如果用户长时间没有支付,一般都会有一个超时时间(如上图商户收银台的支付剩余时间),到达这个超时时间支付单会自动关闭。实现此需求有很多方式,比如:
轮询 DB
定时轮询DB,取出达到超时时间且在支付中的数据,然后执行关闭逻辑。
缺点:1. 存在延迟,取决于定时任务的频率。2. 影响数据库性能。
JDK 延时队列(DelayQueue)和时间轮算法. 这两种的算法的实现方式自行搜索。
共同的缺点是 1. 数据易丢失,由于数据存储在内存中,服务重启后数据全部消失。2. 有内存限制,如果数据量过大,会出现OOM异常。
RocketMQ 延时队列
RocketMQ 支持消息延时发送,社区版不支持任意等级的延迟,目前默认支持18个延时等级:
1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h
比如支付单30分钟过期,在支付单创建成功后发送延迟消息(延时等级为 16),消费者在30分钟后会拉取到该消息然后执行关闭逻辑。
RocketMQ 延时队列,无论在数据安全性和及时性都有明显的优势,但是目前社区版没有支持任意级别的延迟。
目前我们使用的是 RocketMQ 延时队列实现的订单关闭。
三方支付系统支付成功后99.9%的情况下都会回调通知我们,但也难免有意外,比如三方延迟回调或者三方系统宕机,为了保证支付结果的实时性,三方支付也要求我们不能完全依赖于回调接口,所以我们需要定时的调用主动查询接口来查询三方的支付结果。这里我们也是使用的 RocketMQ 延时队列实现的:
有三个重要参数,这些参数可以放到配置中心或者配置库中,
// 初始延迟级别,对应RocketMQ延时等级,比如3对应的延时时间就是10s
private Integer queryInitLevel
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。