金融行业多端支付系统强一致性架构设计（下）

2 支付能力的快速接入

支付快速接入：

设计流程主要目标：屏蔽接入第三方支付平台的复杂度，为业务提供便捷接入的支付的能力。

整体交互逻辑：用户下单后，业务线生成生订单的同时请求支付系统，返回携带加密后的收银台链接，业务前端渲染收银台H5链接，之后用户操作都直接与支付系统直接交互，不再经过业务线。

支付渠道-接入微信支付

左上是收银台（支付页），包括订单基本信息、随机减活动和微信引流活动等。

右上是支付平台和微信交互逻辑。

3 配置化支付方式

最小粒度是支持按不同渠道配置，如最核心的商超业务渠道有几十个，根据不同终端适当屏蔽风控能力减弱的支付方式，或在某些特别终端按业务要求配置指定支付方式，每种相同的支付方式，根据具体的业务线或具体的业务配置不同的商户号，不同的商户号在第三方平台的费率，收款账户都不同。

4 支付单的生命周期

一笔支付单的生命周期：

多端支付场景

第一： 由于我们无法感知用户唤醒sdk后的操作。

所以不能限制用户的支付行为，一个订单可从多个手机多个渠道使用相同或不同支付方式、不同的人同时对一笔进行支付。

第二：支付、退款跨越多个端。

支付跨越多机构，就会经过支付平台、第三支付平台、银行等。支付和退款是天然异步场景，这是不可抗因素。

5 如何安全保证金额正确性

交易金额的强一致性保障设计

台账信息记录4个金额字段：应收、实收、应退、实退。收到支付通知时，会在收到支付通知的时候进行一次对账。

判断：应收+应退=实收+实退

保持该等式，即可正确计算每笔次金额变动。虽然使用一个简单公式来保障多端并发下金额修改的正确性，但由于金额频繁改动，是否可能出现逻辑bug？

若给用户少退了，第一时间即可得到用户的反馈，及时修正bug，并补偿给用户；但如果给用户多退一些钱，很可能用户不会产生反馈，我们自己也没发现。

所以系统底线保障是：

确保不会产生多退款

实收的钱应≥应收的钱。

通过不变量和不需要加工的数据来验证变量

要通过啥手段，保证实收≥应收？尽可能通过不变量和无需加工的数据来验证变量：

• 不变量：订单金额
• 无需加工的数据：业务申请的退款。业务一旦申请退款，校验通过就会插入DB。这里是业务产生的退款，退款可能细分人工退款、多支付退款等，但这些都不用关心。

我们要关心：订单金额-业务产生的退款，即至少收到多少钱，若和实收相等，则认为没问题。

如何保证实收就是正确的？

继续使用实收和支付平台对账，就可进一步确保实收没问题，需对账每一笔正向支付交易和逆向支付交易产生的金额记录，且对账至少需要2种机制来相互保障。

6 高可用架构实践及思路

引用:软件在本质上是复杂的，软件本身的复杂性在于除了要解决问题域，还要解决非功能性需求和软件域特有问题：安全性、可用性、可维护性、可扩展性、性能、一致性、容错性、稳定性、可重用性、幂等、兼容等等。

6.1 分类

三部分：

6.2 实时性保障

支付是一个不可抗拒的跨端异步场景，还要抵抗网络带来的不确定因素。一笔银行转账，大家在心里有预期，即使实时转账，大家也会自觉等待一段时间。

但对在线支付，用户支付完后，用户很理所当然的想到应该看到订单是已支付状态，而非待支付状态，延迟增加到一定时长，客服就找到研发。

线上场景特征

• 配送时效性。一笔订单生命周期就不到1小时，所以在支付上我们不能延迟，不能像银行转账这么慢
• 高并发。银行等金融机构有钱，活动力度不亚于一些商品秒杀场景
• 营销限量。若用户享受支付优惠，但最终由于支付通知的延迟、服务器负载较高的情况下未能成功处理支付通知，那么用户就会要求索赔营销优惠

线下

比线上更复杂：

• 即时性。大家去的线下商店，都支持收银台在线支付，所以在排队的情况下，就需要商家及时完成顾客支付请求
• 网络环境不可控。不同位置，网络信号存在不确定性
• 群体性。线上主要是平台和支付平台的网络交互，但线下还涉及商家，整个支付环节也没这么流畅

尽可能快的让订单支付完成或在某种支付有问题时，第一时间下线这种支付方式。

过去做法是通过暴力从DB反查待支付订单，但对DB压力较大，还得单独写个任务表，后改写为

基于事件通知机制

使用MQ作为事件管道，但由于不同场景触发的反向查询时机不同，不能对所有对待支付订单进行无差别对待，因此就受限MQ特性。目前不支持个性化延迟消费消息，对此策略是申请多个队列，并按不同延迟level入队。

查询补偿设计

反向查询主要场景

① 支付唤醒

由于用户需要输入密码，我们考虑到需要用户参与，进行多次间隔3秒到重试之后，如果还没支付结果则放到更大时间间隔到重试leave中。

② 协议支付、代扣类

用户无需输入密码，所以我们选择更低延迟到消费队列、或无延迟队列。

③ 订单取消

由于反向查询在一定的次数之后会放弃，不然会很占用资源；但如果一笔订单取消了，那么也有可能会因为支付延迟导致订单取消，所以我们就会最后查询一次。

④ 支付通知

同步进行查询结果，主要为防止伪造通知，但增加了一次外网交互，超时可能性很大，伪造通知是极端场景。所以在超时之后会暂时信任本次通知，继续交给反查队列，继续对这笔通知进行验证。

6.3 应用部署隔离

高可用部署的一个架构，划分维度 2C，2B：

根据2C和2B业务请求，对服务器部署上做资源倾斜。确保业务互不影响。

2C一般正向交易场景，RT要求高；2B场景对时效基本没要求，某些业务场景下，会存在集中性大批量退款申请、退款流程的事务也比较大，ToB就针对一些任务worker更消耗CPU。

目标是尽量避免非业务耗时导致的RT升高，而导致RT升高因素有：

• 池化资源不够（http请求线程、rpc处理线程、数据库线程、以及http连接等）
• CPU资源抢占
• GC 导致的业务线程等待
• ...

6.4 多级本地缓存

商品支付的营销需求。参与商品不到百万级，但调用量大，峰值调用量超10万QPS、RT苛刻5ms。

但也由于这是刚新起的业务，产生的业务价值收益有不确定性，所以没打算通过机器去抗量，所以我们把业务请求直接请求到Redis。

但是redis需要较多副本才能扛超高并发，避免大量无效请求。并且增加内存基本的缓存，使用布隆过滤器（Bloom Filter），仍然会把cpu打高，通过门店的过滤把cpu降到最低，所以我们最后会通过caffeine来做热点sku缓存。

Redis的利用率已达97%，这完成是布隆过滤器来决定的，效果明显！

6.5 监控

某晚，手机一阵震动，打开报警一看，报警很明显。红色框是垂直类-支付渠道层的报警，而且都是apple Pay导致的报警，大概率影响支付方式apple Pay。

绿色框是水平维度监控，显示我们的影响功能：支付、查询。同理报警没有显示的业务线，就跟这些具体业务场景没关系。

所以，做平台，监控非常重要的，：“没有度量就没有管理”。

跑在线上生产环境中的每一个服务，也需要管理，我们需要管理它们的运行情况，所以就需要我们建立的完整指标反馈监控系统。

① 机器层面的监控

• 机器维度：系统指标：cpu、负载、内存
• 网络指标：tcp连接数、丢包数、tcp重传
• 磁盘指标：磁盘使用率和磁盘繁忙度
• 容器指标：关注线程数
• 应用：软件异常

② 应用层面的监控

• 系统异常：基础组建异常（数据库、Redis）、RPC异常
• 业务异常：业务异常的捕获主要是为了捕获业务线的一些非法出入参。
• 非预期逻辑：主要一些没想到的一些逻辑场景。通过自定义监控。
• Bug(Jex接入)：上线一阵时间后。大家可以去搜搜excpetion、error关键词。总有意想不到的收获。

③ 业务监控维度

作为平台类系统，最重要的是结合水平维度+垂直维度划分系统报警情况：

• 水平维度：支付、退款、营销、通知
• 垂直维度：业务方、渠道平台

FAQ

延迟队列使用什么框架实现的？

京东的JMQ按照队列进行消费延迟。RocketMQ支持消息级的延迟。

如何避免单重复支付呢？或者避免重复退款呢？

支付是一个不可抗拒的多支付场景。在接收到支付通知的时候，要做对账，如果是多支付，就进行退款。

商品价格类型是用float还是decimal？

支付系统最好使用bigDecimal，因为和支付平台交互单位都是元。其他交易系统尽可能使用long类型，分作为单位。

个阶段对账，如果有差错，怎么处理？

程序设计越复杂，bug的可能性就会越多，所以要尽可能通过一些不变对量和不可修改的数据进行底线保障，至少需要2种金额校验相互保障。

如果应收50，A付款30，B付款40 你这个情况咋退款呢？退款给谁呢？

不会出现。支付金额至少是50，即便多支付，也是100 或者150。

sku的缓存怎么做的，说到是基于Redis的，那数据库和缓存的同步呢？比如下单后扣减库存呢？或更新呢？

整体是基于redis的。但是redis需要较多的副本才能扛超高并发，避免了大量无效请求。增加了内存基本的缓存，使用了布隆过滤器，但是仍然会把cpu打高，通过门店的过滤把cpu降到最低，最后通过caffeine来做热点sku缓存。

关注我，紧跟本系列专栏文章，咱们下篇再续！

作者简介：魔都国企技术专家兼架构，多家大厂后端一线研发经验，各大技术社区头部专家博主，编程严选网创始人。具有丰富的引领团队经验，深厚业务架构和解决方案的积累。

负责交易平台及数据中台等开发设计，通过深入业务，构建合理业务架构。目前主攻降低软件复杂性设计、构建高可用系统方向。

参考：

• 编程严选网