一、专题分享-高并发支付场景分析及设计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：我们有用户绑二类账户，能入金，但是无法出金，同名账户也不能；二类账户是不能转账的，代付到二类卡是失败的，二类账户是可以出金的，即可以消费

A4：正常情况下，直销银行的电子账户属于II类账户；但是那天去华夏开直销银行，大堂经理说不算II类账户，让我扫一个二维码下一个客户端激活一下，感觉不算面核吧；当面核实主要是要核实本人操作，证件信息，联网核查信息与申请开户人相符，然后留存影像或者复印件，不然就不算当面核实吧

A5：目前我们做理财，二类账户可以绑卡购买投资，但是提现不了，建行账户；我们接的是第三方支付机构，不是直接对接银行的。目前遇到这样情况的蛮多，也无法识别是二类账户。就如刚才大家说的，有些本来绑定也是二类户都可以收和付。也有一些银行是限制拦截了。

A6：据我了解建行是可以的，因为我提现过，不过有一个一万块的限制，应该是给商户做了不同限制

A7：二类账户可以和绑定卡进行资金无限额交互的，这是监管允许的，可能因为账户状态异常被设为只收不付，不收不付；这个要看银行的具体执行

A8：二类户可以提现转账，没有这个限制，绑定户只是没有金额限制

A9：以下摘自百科：

II类户可以办理存款、购买投资理财产品等金融产品、限额消费和缴费、限额向非绑定账户转出资金业务。经银行柜面、自助设备加以银行工作人员现场面对面确认身份的，II类户还可以办理存取现金、非绑定账户资金转入业务，可以配发银行卡实体卡片。其中，II类户非绑定账户转入资金、存入现金日累计限额合计为1万元，年累计限额合计为20万元；消费和缴费、向非绑定账户转出资金、取出现金日累计限额合计为1万元，年累计限额合计为20万元。

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：找钢网是没有牌照的 你搞第三种是会跪下的

A3：不会，要看它这是用在什么体系；找钢肯定也是接三方，前两种模式就是原有的P2P模式，第三种是早年的P2P资金池子模式

A4：参考《商户委托收款协议》，其实按照没牌照来说，无论他123哪种都不行，无论是不是过渡户，即使结算到商户的虚拟账户，还不是一样资金池，本质钱是在他账上；标准的平台电商模式呗；违规这个，还是看他资金流，信息流上面没什么，那你看各大电商的模式， 饿了么、美团外卖，资金还是先到虚拟账户，商户再提现；资金池是银行资金过公司账，不是过系统账，所以才说是资金流的事，系统怎么挂账不碍事

A5：资金可以找第三方托管，分成可以谈，找商户和他们签署委托收款协议

• 感觉和p2p托管类型一样，不过现在第三方也要让银行托管账户了，可以问问汇付
• 托管相对直接进公司账户肯定要好些，但从电子商务法草案来看还是有些违规
• 资金存放在合作第三方支付的备付金账户，账户名义是第三方支付公司的，联合存管那套；确切的说，资金应该是存放在第三方支付备付金账户下对应的企业机构号账户里
• 资金放三方支付备付金账户，沉淀资金不会有收入啊，活期存款估计都不会有（不会有，央行取消了这部分利息

  ），但如果是平台托管到银行就可以有收入，估计最次都能有个协议存款收入

• 没全部取消利息收入
• 支付宝好像可以买理财产品，但是有风险

3.7 研发团队考核方案

Q：研发团队考核有啥比较好的方案没？

A1：这个话题有点大。 适合自己公司情况的方案就是好方案 。目前多数公司采用的还是KPI评估，每个月/季度制定个KPI，到月底/季末期评估下哪些工作做好，哪些没做好。 当然，这个人为因素多，在互联网公司也是不太靠谱的，因为计划老变。 最好的方案是找到技术强，有责任心的人，以身作则的人，拉动整个团队。

A2：想纯靠制度和管理提高开发效率和质量很难？关键还是要选对人？

A3：考核领导比啥都强

A4：okr比较适合产品技术

A5：有些业务处理，正常的流程可能只占到50%甚至30%的工作量（代码），剩下的都是处理异常的。以这种特殊的场景来考察，看看一个人要经过多少个回合才能把问题完美解决，对产品和开发都适用。其他的看相互依赖时的协作精神。最后看文档能力、抽象设计水平。