在本周的时候, 印度的那个叫做 The Souled Store 的品牌, 因为搞了限量特卖并且促销活动达到了最高峰, 所以就把他们的支付基础能力给加强了。
这个情况是非常典型的: 大量的用户一下子都涌进来了, 网页页面显示也是正常的, 东西库存也都锁定成功了, 可是付款时间却超时了, 用户还在不停地重复点击, 最后导致结果根本不知道会变成什么样。
支付峰值和流量峰值并不是同一个意思。一笔支付需要经历业务系统、支付网关、银行渠道、资金清算、回调通知以及账务入账等多个环节, 光靠页面服务器是远远不够的。
在高并发的时候, 失败的情况经常聚在一起出现, 具体的表现包括渠道受到限流、网络连接超时、回调信息延迟到达、库存锁定之后时间到期失效、发生了重复扣款现象, 以及订单的状态无法保持同步。
你不能够说, 只要是看到的接口返回了成功, 就觉得成功率很高。你还得非常仔细地去盯着那些数据。你需要去跟踪一下支付发起率, 你要去了解渠道的成功率, 你必须关注用户的放弃率。同时, 结果确认耗时是多少也得看, 重复支付率有多高也需要统计, 还有那异常的订单率, 一样不能忽略。
为了应对洪峰, 我们需要做容量预估, 实行请求削峰，利用多通道路由来分流, 进行幂等控制, 采用异步通知加上主动查询的方式处理异常补偿与降级。
当高峰时段结束以后, 便进入对账这个阶段, 此时会碰到回调数据到达延迟的问题, 还会出现订单关闭之后才发生扣款的情况, 甚至会有重复进行扣款的状况产生, 同时退款工作存在积压现象, 还有不同渠道提供的账单彼此之间存在差异之处, 需要人们逐笔展开核对操作。
在统一支付中台以及支付中心这两者的共同作用下, 多渠道接入这一事务、交易监控这一任务、异常处理这一环节和结算对账这一过程, 都得到了统一的管理, 正是因为这样的统一安排, 才使得整个链路变得可观测, 同时让整个链路能够进行恢复, 北京锐融天下这家公司, 就在综合支付、支付中心以及结算中心这些领域方向内, 提供了具备此类性质的服务能力。
我们要把大促保障的终极目标看得更清楚一点, 它压根就不是说什么机器不能宕机这种话, 咱们真正要的、必须得是每一笔支付的结果都能被确认, 并且能够随时随地进行追踪, 最后保证钱能正确地打进账里去。
FAQ
1. 网站本身是正常的状态, 但是为什么会发生支付失败这种情况呢？
这是因为支付这条链路实际上远远比页面显示出来的内容要漫长得多, 而在其中经常会出现问题的地方往往是在渠道方和银行那个侧面那里。
2. 在超时之后是否需要进行再次付款？
这个是需要先去查询一下当前的订单所呈现的状态, 从而去避免产生重复扣款这种情形的发生的。
3. 大家经常会问到底什么是幂等性？
简单点说呢, 就是如果你把同一个请求重复地提交上去, 哪怕提交了很多次, 系统在最终的处理结果上也只会算作一次有效的扣款。
4. 启用多通道真的可以百分之百确保结果一定是成功的吗?
这个做法最多只是把成功的可能性往上调高一些, 但是必须要配套设立那种用来兜底和提供补偿的机制。
5. 为什么在大促活动结束后, 还会存在异常的订单?
这是因为回调信息出现迟到的情况, 同时系统的状态没有办法实现同步, 所以必须通过人工或者系统进行对账来形成闭环处理。
6. 如何压测？
模拟峰值加渠道抖动加网络延迟，验证降级与补偿。
