高并发支付场景分析及设计

1、高并发支付场景分析及设计、专题分享 -高并发支付场景分析及设计 1.1 背景大家好，我是 20XX 年加入永乐票务，之前一直负责公司票务系 统的整体规划、实现、优化及改造。目前主要负责公司的基 础平台、支付平台、消息平台、云平台、运维平台、风控平 台（交易）、 BI 数据分析平台的研发管理工作。公司介绍：2015 年永乐科技成立， 隶属于永乐文化集团， 是以集团自身 多年的演出经验与票务系统为基础，为剧院、场馆和景区等 提供专业的行业解决方案的科技公司。 1.2 场景介绍永乐科 技架构全景图 李宇春每一年的 “WhyMe ”演唱会抢票大战不仅致使票务网 站系统瘫痪，更是创下开票 69 秒全场售

2、空的华语乐坛歌手 开票纪录。“ WhyMe ”第十年成都演唱会，不管是对于李宇春本人还是所有喜爱李宇春的歌迷来说，都是不可错过的 微票儿（内场， 7000 个座位）与永乐（外区， 32000 个座位） 两家票务网站同步正式开票。为保障正式开票的顺利进行， 两家票务网站同时模拟抢票，因在线人数众多，网站瞬间瘫 痪，导致微票儿 170 台云服务器其中的 36 台宕机。微票儿 更是为此紧急追加 150 台服务器保障正式开票的顺利进行。十年之约” 。此次李宇春“ WhyMe ”年成都演唱会，由据票务网站官方发布数据显示，正式开票后，两家票务网站同时在线抢票人数高达 188 万人，微票儿（内场， 108

3、 万人 在线）永乐（外区 80 万人在线）。预售阶段的统计访问量截 图：正式阶段的统计访问量截图：1.3 问题描述由于该项目同时抢票人数过多、导致公司原有业务系统、支付系统压力爆发式增长。所以在 2015 年 6 月，我们对整个业务系统、支付系统进行了全面的架构升级，目前技术框架采用 +springboot+mybatis+dubbo ) +，技术xx 演唱会抢票开始，小张顺利完成下单， 迫不及待的点击支付按钮，发现没有反应，由于担心抢不到票，小张慌张的狂点支付按钮，提示支付系统繁忙或异常，小张囧了。场景 演唱会抢票开始，小张顺利抢到 1张 200 元演出票，点击钱 包支付按钮，发现没有反应，

4、由于担心抢不到票，小张慌张 的狂点钱包支付按钮 3 次，提示完成支付。随后小张到我的 钱包余额中发现，红包余额为 200 元，小张囧了。场景xx 演唱会抢票开始前，小张预先充值电子钱包1000 元， xxxx 演唱会抢票开始， 小张顺利完成下单， 迫不及待的选择直 连 x 行支付，点击支付按钮，发现账户余额不足，小张又换 了一张卡支付成功 （此处需要重新绑卡、 验证等操作， 相对时 间较长 ），随后小张到我的订单中， 看到订单交易状态是已取 消，支付状态是已支付， 小张又囧了， 心想我明明付款成功， 订单为什么取消了呢，我还能不能有票。场景 4 xxx 演唱会抢票开始， 小张顺利完成下单， 迫

5、不及待的点击支 付按钮，成功跳转 x 宝完成支付。随后小张到我的订单中，看到订单状态是支付中，小张囧了，随后登录x 宝平台，发 现交易成功，小张又囧了。场景 5 xx 演唱会抢票开始，小张顺利完成下单，迫不及待的选择 宝，点击支付按钮，发现没有反应，由于担心抢不到票，小张慌张的重新选择 x 信，点击支付按钮完成支付，随后小张到我的订单中，看到订单状态是支付中，小张囧了，随后登录 x 宝平台，完成支付，小张囧了，心想我付了 2 次款，心 中顿时万马奔腾。 1.4 解决方案 + 综合上述问题来看最主要 的问题，来自服务之间的依赖、调用，需要重新规划服务、 合理拆分服务。 + 下图为服务治理整体思路

6、服务可用性方面见下图），验证设计：符合特征规范、黑名单的用户过滤利用 redis 做计数器）限流设计（见下图） ，采用分布式限 流：我们采用 nginx+lua 操作 redis 控制秒级并发数量（利用redis 的原子性），排队规则先进先出的原则，采用 redis 消息 队列；应用级限流： 我们采用 TPS/QPS 阀值控制限流， 防止 大量请求冲垮系统。令牌设计（见下图） ：可配合限流分发 令牌数量，我们分成两个阶段，第一阶段用户进入提交订单 页面前，需交易系统根据用户信息向分控系统发起一次申请token 的请求，分控系统将 token 保存到 redis 缓存中，为第二阶段支付使用。 第

7、二阶段交易系统带着申请到的token 发起支付请求，支付系统会检查 redis 中是否存在该 token ，如果存在，表示第一次发起支付请求，删除缓存中token 后开始支付逻辑处理；如果缓存中不存在，表示非法请求。通道 设计（见下图） ： vip 、大客户或者提前把资金存入电子钱包 的用户加强权重，根据交易金额，优先进入支付通道。缓存 设计（见下图） ：开启 web 服务器缓存，无状态页面静态化， 查询结果分级缓存， 定时覆盖静态页 （可手动 ），如有 CDN 则 推送静态页到 CDN 上 （会有延迟 ）。数据库设计（见下图）数据库的扩展方案、并发锁方案有很多，方案各有优缺点。分布式事务（无

8、论是拆子系统、微服务，首先考虑从功能上 拆分，单一职责高内聚，尽量避免出现分布式事物问题） 分布式事务成熟的方案有很多， 柔性事物 （两阶段、 三阶段、 补偿、异步通知、最大努力通知等等）举个例子： 以上所有的操作需要满足幂等性，幂等性主要是用于防止重 复提交的，因为事务操作的微服务是分布式部署的，即使有 事务的支持，也无法保证传输过程中会不会因为网络或者其 他问题引发的中断（如：数据方已经接受并提交了更新，但 由于网络中断，提交方并未收到成功更新的消息，这种情况程序一般会返回给用户未成功的信息，而如果用户错误的 任务未成功，则会重新提交申请，导致事务重复提交）Q & AQ ：这种短时

9、间内访客不会无限制持续增长， 而且 卖的票也很集中，百万请求如果全部写入缓存不会占很多内存，再异步分批内存中读取来处理，可不可行？ A ：待回应Q：请教大神一个问题，限流阈值怎么去设置呢？具体限流 有哪些纬度可以控制， 可以分享一下嘛？ A1 ：如果是合法的 访问，限流不如分流，异步处理中保存好各阶段的状态很关 键（业务参数也属于状态一种） ，重复提交那种严格来讲不 是限流，属于正常的状态控制 A2 ：限流还是订单数，主要 是下单以及商品页的压力；重复提交那个不是限流，用的令 牌机制，漏斗型的 A3 ：限流阈值一般是通过，滑动窗口估算出来的。如：服务压测的并发数是100，服务处理平均耗时是 1

10、0 毫秒，这样也可以算出一个阈值出来的，还有一种 就是应用埋点的方式，通过对日志的分析，异步统计阈值。分流是很好的方案。座位也是分价位 缓存在不同的 redis 中A4 ：这种肯定要异步。既然是异步那每一步其实可以独立 来设计（当然不同步骤间肯定有业务关联） ，比如提交订单请求这步我可以独立出来 就当做响应百万并发的上传服务当然还有基本的状态更新）。一个业务子系统（或者流行语叫服务）只管与我业务相关的数据，只修改或生成与我相 关的业务数据，甚至不需要关心上一步谁下一步是谁。当然 还需要一个全局协调跟踪和驱动的系统，异步很类似工作流 的概念（有些地方叫引擎） A5 ：其实就是基于状态机的，就 和

11、火车部一样，出站就没我毛事了。三、自由讨论 3.1 直销 银行与II类账户Q:各位最近有碰到电子账户被监管的情况吗？绑卡要验证 5 要素，但目前直销银行走的通道都是 4 要 素，不合规 ,我这里是有几个银行被监管盯上了 ,盯上了的要整顿。 A1 ：电子账户要绑卡，只能绑一类账户，加了这么个 验证；目前的第三方支付渠道绑卡，都没这个要素；说是央 行有个验证通道，但很不稳定，基本没法用 A2 :问题是现在账户类型还没有可靠的渠道可以区分吧？央行的是批量的，也不所有的银行都支持，所以目前基本没啥用。A3 :我们有用户绑二类账户，能入金，但是无法出金，同名账户也A10:不能；二类账户是不能转账的，代付到二类卡是失败的， 类账户是可以出金的， 即可以消费 A9 :以下摘自百科:二三类电子账户我们都改完了，但是目前没有应用场景，不知道能做什么。当然我们小行做什么都慢悠悠的。A11 :于鲁义:个人银行账户分类政策解读及二类账户的应用3.2pingpong 国内合作支付公司 Q :咱们这有知道 pingpong 在国内合作的支付公司是哪家的么？A :待回应3.3聚合/三方收 单商户交易合法判定 Q :做聚合收单或者三方收单，对于商 户这块什么情况下可以判定交易合法有没有些标准？规 则？ A :待回应3.4交易贷Q:有朋友做交易贷的