转自 金融 IT 保命丹：多端支付强一致性架构设计实践
在线下使用现金交易的时候，我们可能都会认为抹个零头、少几毛几块都是不大的问题，但在平台上，1 分钱计算错误都会酿成悲剧。相信从事金融相关系统的同学都有感触，在处理计算金额逻辑的时候，大家都会十分谨慎，会多次复查代码，准确性、一致性，是支付系统的首要指标。
作为互联网公司，“快”是核心必要指标。尤其我们作为以实时性需求的 o2o（Online To Offline）电商公司，整个订单的生命周期不到 1 小时，如果支付延迟几分钟，履约的质量就会下降，甚至会出现用户需求减少的情况。
所以架构的整体层面上，在保证了系统的安全稳定性的同时，我们要尽可能保证系统的高性能运转，解决互联网的“快”和金融行业的“稳”之间的矛盾。
下面，介绍一下本次分享的主要内容：
作为平台系统，应该具备：产品通用能力、个性化可配置。目前接入支付平台有几十条业务线，主要包括到家业务、骑士业务、快送业务等，根据不同的业务形态，我们提供了 5 种主要的支付产品：
- 收银台（具备多种支付能力）
- 直连支付（直接唤醒支付场景）
- 代扣服务（周期性扣款）
- 代付（好友代付等）
- 协议支付（便快捷支付、免密支付等）
支付系统核心功能主要是：支付和退款。
如在一些预售场景下，为业务线提供定金支付这种 2 阶段支付能力（如定金支付）；退款主要是全款、部分退款、以及提供人工退款服务。
除了核心功能，我们还提供支付营销能力，进一步提升支付的转化，如根据用户所属区域进行支付引流，支付券产品、免息产品、满减等。
在开发定金、和营销产品之前，支付系统被设计为一个订单，在产品形态上很单一，仅认为订单为固定金额，因此开发这两个需求的时候改动了比较大。
目前主流支付能力大概有多阶段支付、大额支付场景、组合支付、支付参与营销等能力，所以有开发支付系统需求的同学，在最开始最好提前预留一些设计。
我们目前基本接入了所有主流支付方式（微信支付、支付宝、京东支付、京东白条等），尤其是现在各类小程序当道，各业务线都需要支持在不同小程序中发展业务，但受到平台支付方式的限制，就需要我们接入更多的支付方式，例如百度支付、头条支付等，都需要接入。
当业务被嵌入到各种各样的流量渠道入口，我们也要根据不同的渠道支持不同的支付方式，如 App 支付、H5 支付、刷脸支付等。
2、支付能力的快速接入
我们接下来看一下支付能力的快速接入的一个流程：
设计流程的主要目标：屏蔽接入第三方支付平台的复杂度，为业务提供便捷接入的支付的能力。
整体交互逻辑是：用户下单之后，业务线生成生订单的同时请求支付系统，返回携带加密后的收银台连接，业务前端渲染收银台 H5 连接，之后的用户操作都直接与支付系统直接交互，不用再经过业务线。
左上图是我们经常使用的收银台（支付页面），包括订单的基本信息、随机减活动和微信的引流活动等。
右上图是我们支付平台和微信的交互逻辑，整体上还是比较复杂的。
3、配置化支付方式
下图我们目前的个性化配置，目前我们最小力度是支持按照不同渠道进行配置，比如我们最核心的商超业务渠道有几十个，根据不同的终端适当屏蔽掉一风控能力减弱的支付方式，或者在某些特别的终端按照业务的要求配置指定的支付方式，每种相同的支付方式，根据具体的业务线或具体的业务配置不同的商户号，不同的商户号在第三方平台的费率，收款账户都是不同的。
4、支付单的生命周期
下面是一笔支付单的生命周期：
我们的多端支付场景是指：
第一： 由于我们无法感知用户唤醒 sdk 后的操作。
所以我们不能限制用户的支付行为，一个订单可以从多个手机多个渠道使用相同或不同的支付方式、不同的人同时对一笔进行支付。
第二：支付、退款跨越多个端。
支付跨越多个机构，就会经过支付平台、第三支付平台、银行等。支付和退款是一个天然异步场景，这是不可抵抗的因素。
二、如何安全保证金额正确性
在我们的台账信息中会记录了 4 个金额字段：应收、实收、应退、实退。在收到支付通知的时候，我们会在收到支付通知的时候进行一次对账。
判断：应收+应退=实收+实退
保持了这个等式，我们就可以正确的计算每笔次金额的变动。
虽然我们使用了一个简单的公式来保障多端并发下金额修改的正确性，但是由于金额的频繁改动。我们是否可能出现逻辑上的 bug 呢？
如果给用户少退了，第一时间就可以得到用户的反馈，及时修正 bug，并补偿给用户；但如果给用户多退一些钱，很可能用户不会产生反馈，我们自己也没发现。
所以我们的系统底线保障是：确保不会产生多退款。
那么我们要通过什么手段，来保证实际收的钱应该大于或等于应该收的钱？这时，我们要尽可能通过不变量和不需要加工的数据来验证变量。
- 不变量：订单金额；
- 不需要加工的数据：业务申请的退款。业务一旦申请退款，校验通过就会插入数据库。这里是业务产生的退款，退款可能会有人工退款、多支付退款等，但是这些我们不用关心。
我们需要关心的是：订单金额-业务产生的退款，也就是我们至少收到多少钱，如果和实收相等，则认为没有问题。
那么我们如何保证实收就是正确的呢？
继续使用实收和支付平台对账，其实就可以进一步确保实收没问题，我们需要对账每一笔正向支付交易和逆向支付交易产生的金额记录，且对账至少需要 2 种机制来相互保障。
三、高可用架构的一些实践及思路
1、高可用的分类
高可用分为三部分：业务上的高可用、容灾上的高可用、架构上的高可用。
支付是一个不可抗拒的跨端异步场景，还要抵抗网络带来的不确定因素。对于一笔银行转账，大家在心里是有预期的，即使实时转账，大家也会等待一段时间。
但是对于在线支付，用户支付完以后，用户很理所当然的想到应该看到订单是已支付状态，而不是待支付状态，延迟增加到一定时长，客服就找到研发头上。
2、高可用-支持实时性保障
线上场景还有以下特征：
- 配送的时效性。一笔订单生命周期就不到 1 小时，所以在支付上我们不能延迟，不能像银行转账这么慢。
- 高并发。大家也知道银行等金融机构比较有钱，所以他们在做活动的时候，这些活动的力度不亚于一些商品秒杀场景。
- 营销限量。这是非常重要的一点，如果用户享受支付优惠，但是最终由于支付通知的延迟、服务器负载较高的情况下未能成功处理支付通知，那么用户就会要求索赔营销优惠了。
线下场景比线上场景更加复杂，有以下特征：
- 即时性。大家去的线下商店，基本都支持收银台在线支付，所以在排队的情况下，就需要商家及时完成顾客的支付请求。
- 网络环境不可控。在不同的位置，其网络信号就存在着不确定性。
- 群体性。线上主要是平台和支付平台的网络交互，但是线下还涉及到了商家，整个支付环节也没这么流畅。
我们需要做的就是尽可能快的让订单支付完成，或者在某种支付有问题的时候，第一时间下线这种支付方式。
我们过去的做法是通过暴力从数据库反查待支付的订单，但是对数据库压力还是比较大的，还要单独写个任务表，后来改写为基于事件通知机制。
我们使用 JMQ 队列作为事件管道，但由于不同场景触发的反向查询时机不同，所以我们不能对所有对待支付订单进行无差别对待，因此就受限于 JMQ 的特性。
目前不支持个性化延迟消费消息，所以我们的策略是申请多个队列，并按照不同的延迟 level，放入队列中。
上图是我们整体查询补偿的设计，反向查询主要由以下几种场景：
第一种是支付唤醒。由于用户需要输入密码，我们考虑到需要用户参与，进行多次间隔 3 秒到重试之后，如果还没支付结果则放到更大时间间隔到重试 leave 中。
第二种是协议支付、代扣类场景。这种支付方式用户无需输入密码，所以我们选择更低延迟到消费队列、或无延迟队列中。
第三种是订单取消（这是大家比较容易忽视的）。由于反向查询在一定的次数之后会放弃，不然会很占用资源；但如果一笔订单取消了，那么也有可能会因为支付延迟导致订单取消，所以我们就会最后查询一次。
第四种是支付通知（最重要的一种）。支付通知场景我们会同步进行查询结果，主要是为了防止伪造通知，但是增加了一次外网交互，超时的可能还是很大的，伪造通知是极端场景。所以在超时之后会暂时信任本次通知，继续交给反查队列，继续对这笔通知进行验证。
3、高可用-应用部署隔离
下图是我们高可用部署的一个架构：
我们根据 ToC 和 ToB 业务请求，对服务器部署上做了资源的倾斜。确保业务相互不影响。
ToC 一般是正向交易场景，RT 要求比较高；ToB 场景对时效基本没有要求，在某些业务场景下，会存在集中性的大批量退款申请、退款流程的事务也比较大，ToB 就针对一些任务 worker 比较消耗 cpu。
我们的目标是尽量避免非业务耗时导致的 RT 升高，而导致 RT 升高的因素有：池化资源不够（http 请求线程、rpc 处理线程、数据库线程、以及 http 连接等）、cpu 资源抢占、GC 导致的业务线程等待等。
4、高可用-多级本地缓存
再分享一个最近刚做的业务：商品支付的营销需求。
这个新兴业务需求整体的特点是：参与商品不到百万级的一个量级，但是调用量大，峰值调用量会超过 10 万 qps、RT 苛刻 5ms。
但也由于这是刚新起的业务，产生的业务价值收益有不确定性，所以没打算通过机器去抗量，所以我们把业务请求直接请求到 Redis。
但是 redis 需要较多的副本才能扛超高并发，避免大量无效请求。并且增加了内存基本的缓存，使用了布隆过滤器（Bloom Filter），仍然会把 cpu 打高，通过门店的过滤把 cpu 降到最低，所以我们最后会通过 caffeine 来做热点 sku 缓存。
上图是我们线上的一个效果图，Redis 的利用率已经达到了 97%，这完成是布隆过滤器来决定的，效果还是比较明显的。
5、高可用-监控
我们再来举一个例子：
某晚上，手机一阵震动，打开报警一看，报警很明显。红色框是垂直类-支付渠道层的报警，而且都是 apple Pay 导致的报警，那么基本大概率影响支付方式是 apple Pay。
绿色框是水平维度监控，显示了我们的影响功能：支付、查询。同理报警没有显示的业务线，就跟这些具体业务场景没关系。
所以，做一个平台的系统，监控是非常重要的，有句名言：“没有度量就没有管理”。
我们跑在线上生产环境中的每一个服务，也需要管理，我们需要管理它们的运行情况，所以就需要我们建立的完整指标反馈监控系统。
机器层面的监控包括：
- 机器维度：系统指标：cpu、负载、内存；
- 网络指标：tcp 连接数、丢包数、tcp 重传；
- 磁盘指标：磁盘使用率和磁盘繁忙度；
- 容器指标：关注线程数；
- 应用：软件异常。
应用层面的监控包括：
- 系统异常：基础组建异常（数据库、Redis）、RPC 异常
- 业务异常：业务异常的捕获主要是为了捕获业务线的一些非法出入参。
- 非预期逻辑：主要一些没想到的一些逻辑场景。通过自定义监控。
- Bug(Jex 接入)：上线一阵时间后。大家可以去搜搜 excpetion、error 关键词。总有意想不到的收获。
业务监控维度包括（作为平台类系统，最重要的是结合水平维度+垂直维度划分系统报警情况）：
- 水平维度：支付、退款、营销、通知
- 垂直维度：业务方、渠道平台
>>>>
Q&A
Q1：延迟队列使用什么框架实现的？
A1 ：使用京东的 JMQ 队列。按照队列进行消费延迟。RocketMQ 支持消息级别的延迟。
Q2 : 如何避免单重复支付呢？或者避免重复退款呢？
A2 ：支付是一个不可抗拒的多支付场景。在接收到支付通知的时候，要做对账，如果是多支付，就进行退款。
Q3 : 商品价格类型是用 float 还是 decimal？
A3 ：支付系统最好使用 bigDecimal，因为和支付平台交互单位都是元。其他交易系统尽可能使用 long 类型，分作为单位。
Q4 : 各个阶段对账，如果有差错，怎么处理？
A4 ：程序设计越复杂，bug 的可能性就会越多，所以要尽可能通过一些不变对量和不可修改的数据进行底线保障，至少需要 2 种金额校验相互保障。
Q5 : 如果应收 50，A 付款 30，B 付款 40 你这个情况咋退款呢？退款给谁呢？
A5 ：不会出现。支付金额至少是 50，即便多支付，也是 100 或者 150。
Q6 : sku 的缓存怎么做的，直播说到是基于 Redis 的，那数据库和缓存的同步呢？比如下单后扣减库存呢？或更新呢？
A6 ：我们前面有提到过，整体是基于 redis 的。但是 redis 需要较多的副本才能扛超高并发，避免了大量无效请求。增加了内存基本的缓存，使用了布隆过滤器，但是仍然会把 cpu 打高，通过门店的过滤把 cpu 降到最低，最后通过 caffeine 来做热点 sku 缓存。
Q7 : 持久化数据库用的哪个产品？
A7 ：MySQL。
作者介绍：
郑志成，京东到家高级工程师，2015 年加入京东到家。负责交易系统（提单、支付）以及基础系统（Api 网关、定位、地址）等开发工作,通过深入到业务，搭建合理的业务架构。目前主攻降低软件复杂性设计、构建高可用系统方向。
本文转载自：dbaplus 社群（ID：dbaplus）
原文链接：金融IT保命丹：多端支付强一致性架构设计实践
若有收获，就点个赞吧
0 人点赞
