AllinToyou

这个屌丝很懒，什么也没留下！

热门标签

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

作者：AllinToyou | 2024-05-15 19:40:54

踩

高并发钱包设计

0?wx_fmt=gif

相关阅读：

300本计算机编程的经典书籍下载

重磅！苹果正式开源iOS内核源码！

互联网技术(java框架、分布式、集群)干货视频大全，不看后悔！(免费下载)

一、专题分享-高并发支付场景分析及设计

1.1 背景

大家好，我是20XX年加入永乐票务，之前一直负责公司票务系统的整体规划、实现、优化及改造。目前主要负责公司的基础平台、支付平台、消息平台、云平台、运维平台、风控平台（交易）、BI数据分析平台的研发管理工作。

公司介绍：2015年永乐科技成立，隶属于永乐文化集团，是以集团自身多年的演出经验与票务系统为基础，为剧院、场馆和景区等提供专业的行业解决方案的科技公司。

1.2 场景介绍

永乐科技架构全景图
640?wx_fmt=jpeg

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

预售阶段的统计访问量截图：
640?wx_fmt=jpeg
正式阶段的统计访问量截图：

1.3 问题描述

由于该项目同时抢票人数过多、导致公司原有业务系统、支付系统压力爆发式增长。所以在2015年6月，我们对整个业务系统、支付系统进行了全面的架构升级，目前技术框架采用 ++（springboot+mybatis+dubbo）++，技术框架如下：

640?wx_fmt=jpeg

场景1
xx演唱会抢票开始，小张顺利完成下单，迫不及待的点击支付按钮，发现没有反应，由于担心抢不到票，小张慌张的狂点支付按钮，提示支付系统繁忙或异常，小张囧了。

场景2
xx演唱会抢票开始前，小张预先充值电子钱包1000元，xx演唱会抢票开始，小张顺利抢到1张200元演出票，点击钱包支付按钮，发现没有反应，由于担心抢不到票，小张慌张的狂点钱包支付按钮3次，提示完成支付。随后小张到我的钱包余额中发现，红包余额为200元，小张囧了。

场景3
xx演唱会抢票开始，小张顺利完成下单，迫不及待的选择直连x行支付，点击支付按钮，发现账户余额不足，小张又换了一张卡支付成功(此处需要重新绑卡、验证等操作，相对时间较长)，随后小张到我的订单中，看到订单交易状态是已取消，支付状态是已支付，小张又囧了，心想我明明付款成功，订单为什么取消了呢，我还能不能有票。

场景4
xx演唱会抢票开始，小张顺利完成下单，迫不及待的点击支付按钮，成功跳转x宝完成支付。随后小张到我的订单中，看到订单状态是支付中，小张囧了，随后登录x宝平台，发现交易成功，小张又囧了。

场景5
xx演唱会抢票开始，小张顺利完成下单，迫不及待的选择x宝，点击支付按钮，发现没有反应，由于担心抢不到票，小张慌张的重新选择x信，点击支付按钮完成支付，随后小张到我的订单中，看到订单状态是支付中，小张囧了，随后登录x宝平台，完成支付，小张囧了，心想我付了2次款，心中顿时万马奔腾。

1.4 解决方案

++综合上述问题来看最主要的问题，来自服务之间的依赖、调用，需要重新规划服务、合理拆分服务。++

下图为服务治理整体思路

640?wx_fmt=jpeg

服务可用性方面（见下图），验证设计：符合特征规范、黑名单的用户过滤（利用redis做计数器）

640?wx_fmt=jpeg

限流设计（见下图），采用分布式限流：我们采用nginx+lua操作redis控制秒级并发数量（利用redis的原子性），排队规则先进先出的原则，采用redis消息队列；应用级限流：我们采用TPS/QPS阀值控制限流，防止大量请求冲垮系统。

640?wx_fmt=jpeg

令牌设计（见下图）：可配合限流分发令牌数量，我们分成两个阶段，第一阶段用户进入提交订单页面前，需交易系统根据用户信息向分控系统发起一次申请token的请求，分控系统将token保存到redis缓存中，为第二阶段支付使用。第二阶段交易系统带着申请到的token发起支付请求，支付系统会检查redis中是否存在该token，如果存在，表示第一次发起支付请求，删除缓存中token后开始支付逻辑处理；如果缓存中不存在，表示非法请求。

640?wx_fmt=jpeg

通道设计（见下图）：vip、大客户或者提前把资金存入电子钱包的用户加强权重，根据交易金额，优先进入支付通道。

640?wx_fmt=jpeg

缓存设计（见下图）：开启web服务器缓存，无状态页面静态化，查询结果分级缓存，定时覆盖静态页(可手动)，如有CDN则推送静态页到CDN上(会有延迟)。

640?wx_fmt=jpeg

数据库设计（见下图）：数据库的扩展方案、并发锁方案有很多，方案各有优缺点。

640?wx_fmt=jpeg

分布式事务（无论是拆子系统、微服务，首先考虑从功能上拆分，单一职责高内聚，尽量避免出现分布式事物问题）。分布式事务成熟的方案有很多，柔性事物（两阶段、三阶段、补偿、异步通知、最大努力通知等等）

举个例子：（见下图）

640?wx_fmt=jpeg

以上所有的操作需要满足幂等性，幂等性主要是用于防止重复提交的，因为事务操作的微服务是分布式部署的，即使有事务的支持，也无法保证传输过程中会不会因为网络或者其他问题引发的中断（如：数据方已经接受并提交了更新，但由于网络中断，提交方并未收到成功更新的消息，这种情况下程序一般会返回给用户未成功的信息，而如果用户错误的任务未成功，则会重新提交申请，导致事务重复提交）

640?wx_fmt=jpeg

二、Q & A

Q：这种短时间内访客不会无限制持续增长，而且卖的票也很集中，百万请求如果全部写入缓存不会占很多内存，再异步分批内存中读取来处理，可不可行？

A：待回应

Q：请教大神一个问题，限流阈值怎么去设置呢？具体限流有哪些纬度可以控制，可以分享一下嘛？

A1：如果是合法的访问，限流不如分流，异步处理中保存好各阶段的状态很关键（业务参数也属于状态一种），重复提交那种严格来讲不是限流，属于正常的状态控制

A2：限流还是订单数，主要是下单以及商品页的压力；重复提交那个不是限流，用的令牌机制，漏斗型的

A3：限流阈值一般是通过，滑动窗口估算出来的。如：服务压测的并发数是100，服务处理平均耗时是10毫秒，这样也可以算出一个阈值出来的，还有一种就是应用埋点的方式，通过对日志的分析，异步统计阈值。分流是很好的方案。座位也是分价位缓存在不同的redis中~

A4：这种肯定要异步。既然是异步那每一步其实可以独立来设计（当然不同步骤间肯定有业务关联），比如提交订单请求这步我可以独立出来就当做响应百万并发的上传服务（当然还有基本的状态更新）。一个业务子系统（或者流行语叫服务）只管与我业务相关的数据，只修改或生成与我相关的业务数据，甚至不需要关心上一步谁下一步是谁。当然还需要一个全局协调跟踪和驱动的系统，异步很类似工作流的概念（有些地方叫引擎）

A5：其实就是基于状态机的，就和火车部一样，出站就没我毛事了。