高并发支付场景分析及设计
相关阅读：
300本计算机编程的经典书籍下载
重磅！苹果正式开源iOS内核源码！
互联网技术(java框架、分布式、集群)干货视频大全，不看后悔！(免费下载)
一、专题分享-高并发支付场景分析及设计
1.1 背景
大家好，我是20XX年加入永乐票务，之前一直负责公司票务系统的整体规划、实现、优化及改造。目前主要负责公司的基础平台、支付平台、消息平台、云平台、运维平台、风控平台（交易）、BI数据分析平台的研发管理工作。
公司介绍：2015年永乐科技成立，隶属于永乐文化集团，是以集团自身多年的演出经验与票务系统为基础，为剧院、场馆和景区等提供专业的行业解决方案的科技公司。
1.2 场景介绍
永乐科技架构全景图
李宇春每一年的“WhyMe”演唱会抢票大战不仅致使票务网站系统瘫痪，更是创下开票69秒全场售空的华语乐坛歌手开票纪录。“WhyMe”第十年成都演唱会，不管是对于李宇春本人还是所有喜爱李宇春的歌迷来说，都是不可错过的“十年之约”。此次李宇春“WhyMe”十年成都演唱会，由微票儿（内场，7000个座位）与永乐（外区，32000个座位）两家票务网站同步正式开票。为保障正式开票的顺利进行，两家票务网站同时模拟抢票，因在线人数众多，网站瞬间瘫痪，导致微票儿170台云服务器其中的36台宕机。微票儿更是为此紧急追加150台服务器保障正式开票的顺利进行。据票务网站官方发布数据显示，正式开票后，两家票务网站同时在线抢票人数高达188万人，微票儿（内场，108万人在线）永乐（外区80万人在线）。
预售阶段的统计访问量截图：
正式阶段的统计访问量截图：
1.3 问题描述
由于该项目同时抢票人数过多、导致公司原有业务系统、支付系统压力爆发式增长。所以在2015年6月，我们对整个业务系统、支付系统进行了全面的架构升级，目前技术框架采用 ++（springboot+mybatis+dubbo）++，技术框架如下：
场景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 解决方案
++综合上述问题来看最主要的问题，来自服务之间的依赖、调用，需要重新规划服务、合理拆分服务。++
下图为服务治理整体思路
服务可用性方面（见下图），验证设计：符合特征规范、黑名单的用户过滤（利用redis做计数器）
限流设计（见下图），采用分布式限流：我们采用nginx+lua操作redis控制秒级并发数量（利用redis的原子性），排队规则先进先出的原则，采用redis消息队列；应用级限流：我们采用TPS/QPS阀值控制限流，防止大量请求冲垮系统。
令牌设计（见下图）：可配合限流分发令牌数量，我们分成两个阶段，第一阶段用户进入提交订单页面前，需交易系统根据用户信息向分控系统发起一次申请token的请求，分控系统将token保存到redis缓存中，为第二阶段支付使用。 第二阶段交易系统带着申请到的token发起支付请求，支付系统会检查redis中是否存在该token，如果存在，表示第一次发起支付请求，删除缓存中token后开始支付逻辑处理；如果缓存中不存在，表示非法请求。
通道设计（见下图）：vip、大客户或者提前把资金存入电子钱包的用户加强权重，根据交易金额，优先进入支付通道。
缓存设计（见下图）：开启web服务器缓存，无状态页面静态化，查询结果分级缓存，定时覆盖静态页(可手动)，如有CDN则推送静态页到CDN上(会有延迟)。
数据库设计（见下图）：数据库的扩展方案、并发锁方案有很多，方案各有优缺点。
分布式事务（无论是拆子系统、微服务，首先考虑从功能上拆分，单一职责高内聚，尽量避免出现分布式事物问题）。分布式事务成熟的方案有很多，柔性事物（两阶段、三阶段、补偿、异步通知、最大努力通知等等）
举个例子：（见下图）
以上所有的操作需要满足幂等性，幂等性主要是用于防止重复提交的，因为事务操作的微服务是分布式部署的，即使有事务的支持，也无法保证传输过程中会不会因为网络或者其他问题引发的中断（如：数据方已经接受并提交了更新，但由于网络中断，提交方并未收到成功更新的消息，这种情况下程序一般会返回给用户未成功的信息，而如果用户错误的任务未成功，则会重新提交申请，导致事务重复提交）
二、Q & A
Q：这种短时间内访客不会无限制持续增长，而且卖的票也很集中，百万请求如果全部写入缓存不会占很多内存，再异步分批内存中读取来处理，可不可行？
A：待回应
Q：请教大神一个问题，限流阈值怎么去设置呢？具体限流有哪些纬度可以控制，可以分享一下嘛？
A1：如果是合法的访问，限流不如分流，异步处理中保存好各阶段的状态很关键（业务参数也属于状态一种），重复提交那种严格来讲不是限流，属于正常的状态控制
A2：限流还是订单数，主要是下单以及商品页的压力；重复提交那个不是限流，用的令牌机制，漏斗型的
A3：限流阈值一般是通过，滑动窗口估算出来的。如：服务压测的并发数是100，服务处理平均耗时是10毫秒，这样也可以算出一个阈值出来的，还有一种就是应用埋点的方式，通过对日志的分析，异步统计阈值。分流是很好的方案。座位也是分价位 缓存在不同的redis中~
A4：这种肯定要异步。既然是异步那每一步其实可以独立来设计（当然不同步骤间肯定有业务关联），比如提交订单请求这步我可以独立出来 就当做响应百万并发的上传服务（当然还有基本的状态更新）。一个业务子系统（或者流行语叫服务）只管与我业务相关的数据，只修改或生成与我相关的业务数据，甚至不需要关心上一步谁下一步是谁。当然还需要一个全局协调跟踪和驱动的系统，异步很类似工作流的概念（有些地方叫引擎）
A5：其实就是基于状态机的，就和火车部一样，出站就没我毛事了。
三、自由讨论
3.1 直销银行与II类账户
Q：各位最近有碰到电子账户被监管的情况吗？绑卡要验证5要素，但目前直销银行走的通道都是4要素，不合规,我这里是有几个银行被监管盯上了,盯上了的要整顿。
A1：电子账户要绑卡，只能绑一类账户，加了这么个验证；目前的第三方支付渠道绑卡，都没这个要素；说是央行有个验证通道，但很不稳定，基本没法用
A2：问题是现在账户类型还没有可靠的渠道可以区分吧？央行的是批量的，也不所有的银行都支持，所以目前基本没啥用。
A3：我们有用户绑二类账户，能入金，但是无法出金，同名账户也不能；二类账户是不能转账的，代付到二类卡是失败的，二类账户是可以出金的，即可以消费
A9：以下摘自百科：
A10：二三类电子账户我们都改完了，但是目前没有应用场景，不知道能做什么。当然我们小行做什么都慢悠悠的。
A11：于鲁义：个人银行账户分类政策解读及二类账户的应用
3.2 pingpong国内合作支付公司
Q：咱们这有知道pingpong在国内合作的支付公司是哪家的么？
A：待回应
3.3 聚合/三方收单商户交易合法判定
Q：做聚合收单或者三方收单，对于商户这块什么情况下可以判定交易合法有没有些标准？规则？
A：待回应
3.4 交易贷
Q：有朋友做交易贷的吗？类似京东白条或者花呗
A：待回应
3.5 基于USSD的手机银行业务
Q：群里的大神们有没有接触过基于ussd的手机银行业务啊，求助？
A：待回应
3.6 担保支付模式
Q：下图中那种模式比较好？
A1：选3，资金进入担保过渡户，支付宝不就是这么干的么，且平台有资金沉淀
A2：找钢网是没有牌照的 你搞第三种是会跪下的
3.7 研发团队考核方案
看完本文有收获？请转发分享给更多人
欢迎关注“互联网架构师”，我们分享最有价值的互联网技术干货文章，助力您成为有思想的全栈架构师，我们只聊互联网、只聊架构，不聊其他！打造最有价值的架构师圈子和社区。
本公众号覆盖中国主要首席架构师、高级架构师、CTO、技术总监、技术负责人等人 群。分享最有价值的架构思想和内容。打造中国互联网圈最有价值的架构师圈子。
长按下方的二维码可以快速关注我们
如想加群讨论学习，请点击右下角的“加群学习”菜单入群