支付系统的洪峰应对之法

导语： 随着科技和社会的进步，移动支付已经成为大众支付的第一选择，支付越来越便捷，公司在近几年也突飞猛进，随之诞生了一下巨型业务，加上各种节日，活动日的造势，支付量常常有10倍，20倍于日常量的突发支付量。在这个过程中，我们总结了一些经验。

1. 整体设计

1. 1 限流

整个支付流程下来，需要经历很多环节，如：加载商店页、加载订单页、下单、支付、发货等，其中如果涉及到活动的话，可能还有各种资格查询等。整个交易流程比较长，其中任何一个环节失败，都可能导致交易失败，最终所有已经完成的操作都浪费掉了。当洪峰流量来临时，各阶段均可能因超载而导致整个交易失败；更甚者，如果这种状况得不到有效的控制，用户反复重试，还会对系统造成进一步的伤害（风暴）。最终，大部分的人都不能交易成功。

通过扩容，是可以解决这里的问题的，但是任何方案都需要考虑成本因素。解决问题的阶段越早，成本越低。因此，在不大规模扩容的情况下，我们采用“及早拒绝”来解决一大部分问题。

及早拒绝：

为了避免进一步的伤害（风暴）导致整个支付系统瘫痪，我们采用了“入口竞争”的措施，海量用户通过竞争有限的机会，进入后续的支付环节，没有取得机会的用户被及时拒绝，保障已经取得机会的用户尽可能的完成整个支付流程。

友好反馈、频率控制：

对于没有获得机会的用户，我们会在1秒之内就给出拒绝的结果，并给出建议性的提示，将用户的页面冻结10秒，配上解冻倒计时，解冻后才能再次发起“竞争”购买的动作。

通过这些操作，用户可以迅速拿到结果，不用不知所措的傻等转菊花；并对自己的等待有一个预期，比如刷了几次都没有打开的话，用户可能会稍后再来，不用一直等。通过竞争和倒计时，也会增加以下用户抢购的紧迫感。

1.2 排队

在支付环节，用户已经通过竞争，进入了支付流程，后续的就需要尽力帮用户完成整个流程。我们引入了预下单的机制，让用户通过预下单进行排队，并引入一个查单cgi，用户可以通过查单cgi查询自己的排队进度。排队完成后，自动拉起支付密码输入框。以排队的体验代替竞争的体验，使用户有一个更好的预期，减少中途放弃的概率。

在发货环节，用户已经支付完成，待发放的物品，也通过排队进行发放，避免对后端发货系统的一个冲击。

1.3 有损服务

支付流程中，有涉及到用户体验的，如支付成功通知tips，各种提醒等体验性的流程。在洪峰情况下，可以选择性的关闭，保证支付系统核心功能的正常运转。

1.4 分离原则

主要涉及：业务分离、渠道分离、部署分离、快慢分离、用户分离等。尽可能的保证业务之间、渠道之间、不同的系统之间、用户之间的相关影响最小化。快慢系统分离，尽可能保证整体系统的高效运转。

2. 单系统设计

2.1 容量预估与资源监控

每个系统通过压测和现网演练，可以评估出一个容量，并针对cpu、内存、磁盘IO、网络IO等指标进行实时监控，并在负载告急之前能给出告警。

2.2 尽力而为

第一点的限流实际是整个支付系统的过载保护的一部分，这里再提一下单系统的过载保护。首先所有的系统，都具备保护自己的能力；同时所有的系统，也需具备一定的保护后端系统的能力。系统容量需要一定余量，并在70%左右的容量时进行预警，以提醒运维提前进行准备，在90%时，系统能够自己进行过载保护，确保系统不会被冲垮。

2.3 动态调节

基于监控，实现动态扩缩容，调节单个系统的容量。（目前还没完全自动化）

通过以上的设计计平在面对洪峰的情况下，顺利扛下了不断增长的业务需求。并在一次次实践检验后，我们会不断的完善和细化这方面的实践。