高并發(fā)支付場景分析及設(shè)計

1、高并發(fā)支付場景分析及設(shè)計一、專題分享 -高并發(fā)支付場景分析及設(shè)計 1.1 背景大家 好，我是 20XX 年加入永樂票務(wù)，之前一直負責公司票務(wù)系 統(tǒng)的整體規(guī)劃、實現(xiàn)、優(yōu)化及改造。目前主要負責公司的基 礎(chǔ)平臺、支付平臺、消息平臺、云平臺、運維平臺、風控平 臺（交易）、 BI 數(shù)據(jù)分析平臺的研發(fā)管理工作。公司介紹： 2015 年永樂科技成立， 隸屬于永樂文化集團， 是以集團自身 多年的演出經(jīng)驗與票務(wù)系統(tǒng)為基礎(chǔ)，為劇院、場館和景區(qū)等 提供專業(yè)的行業(yè)解決方案的科技公司。 1.2 場景介紹永樂科 技架構(gòu)全景圖 李宇春每一年的 “WhyMe ”演唱會搶票大戰(zhàn)不僅致使票務(wù)網(wǎng) 站系統(tǒng)癱瘓，更是創(chuàng)下開票 69 秒

2、全場售空的華語樂壇歌手 開票紀錄?！?WhyMe ”第十年成都演唱會，不管是對于李宇 春本人還是所有喜愛李宇春的歌迷來說，都是不可錯過的“十年之約” 。此次李宇春“ WhyMe ”十年成都演唱會，由 微票兒（內(nèi)場， 7000 個座位）與永樂（外區(qū)， 32000 個座位） 兩家票務(wù)網(wǎng)站同步正式開票。為保障正式開票的順利進行， 兩家票務(wù)網(wǎng)站同時模擬搶票，因在線人數(shù)眾多，網(wǎng)站瞬間癱 瘓，導致微票兒 170 臺云服務(wù)器其中的 36 臺宕機。微票兒 更是為此緊急追加 150 臺服務(wù)器保障正式開票的順利進行。 據(jù)票務(wù)網(wǎng)站官方發(fā)布數(shù)據(jù)顯示，正式開票后，兩家票務(wù)網(wǎng)站 同時在線搶票人數(shù)高達 188萬人，微票兒（

3、內(nèi)場， 108 萬人 在線）永樂（外區(qū) 80 萬人在線）。預售階段的統(tǒng)計訪問量截 圖：正式階段的統(tǒng)計訪問量截圖：1.3 問題描述由于該項目同時搶票人數(shù)過多、導致公司原有 業(yè)務(wù)系統(tǒng)、支付系統(tǒng)壓力爆發(fā)式增長。所以在 2015 年 6 月， 我們對整個業(yè)務(wù)系統(tǒng)、支付系統(tǒng)進行了全面的架構(gòu)升級，目 前技術(shù)框架采用 +（ springboot+mybatis+dubbo ） +，技術(shù) 框架如下：場景 1xx 演唱會搶票開始， 小張順利完成下單， 迫不及待的點擊支 付按鈕，發(fā)現(xiàn)沒有反應(yīng)，由于擔心搶不到票，小張慌張的狂 點支付按鈕，提示支付系統(tǒng)繁忙或異常，小張囧了。場景 2 xx 演唱會搶票開始前，小張預先充

4、值電子錢包 1000 元， xx 演唱會搶票開始，小張順利搶到 1張 200元演出票，點擊錢 包支付按鈕，發(fā)現(xiàn)沒有反應(yīng)，由于擔心搶不到票，小張慌張 的狂點錢包支付按鈕 3 次，提示完成支付。隨后小張到我的 錢包余額中發(fā)現(xiàn)，紅包余額為 200 元，小張囧了。場景 3 xx 演唱會搶票開始， 小張順利完成下單， 迫不及待的選擇直 連x行支付，點擊支付按鈕，發(fā)現(xiàn)賬戶余額不足，小張又換 了一張卡支付成功 （此處需要重新綁卡、 驗證等操作， 相對時 間較長 ），隨后小張到我的訂單中， 看到訂單交易狀態(tài)是已取 消，支付狀態(tài)是已支付， 小張又囧了， 心想我明明付款成功， 訂單為什么取消了呢，我還能不能有票。

5、場景 4xx 演唱會搶票開始， 小張順利完成下單， 迫不及待的點擊支 付按鈕，成功跳轉(zhuǎn) x 寶完成支付。隨后小張到我的訂單中， 看到訂單狀態(tài)是支付中，小張囧了，隨后登錄 x 寶平臺，發(fā) 現(xiàn)交易成功，小張又囧了。場景 5xx 演唱會搶票開始，小張順利完成下單，迫不及待的選擇 x 寶，點擊支付按鈕，發(fā)現(xiàn)沒有反應(yīng)，由于擔心搶不到票，小 張慌張的重新選擇 x 信，點擊支付按鈕完成支付，隨后小張 到我的訂單中，看到訂單狀態(tài)是支付中，小張囧了，隨后登 錄x寶平臺，完成支付，小張囧了，心想我付了2次款，心中頓時萬馬奔騰。 1.4 解決方案 + 綜合上述問題來看最主要 的問題，來自服務(wù)之間的依賴、調(diào)用，需要重

6、新規(guī)劃服務(wù)、 合理拆分服務(wù)。 + 下圖為服務(wù)治理整體思路服務(wù)可用性方面 （見下圖），驗證設(shè)計：符合特征規(guī)范、黑名單的用戶過濾 （利用 redis 做計數(shù)器）限流設(shè)計（見下圖） ，采用分布式限 流：我們采用 nginx+lua 操作 redis 控制秒級并發(fā)數(shù)量（利用 redis 的原子性），排隊規(guī)則先進先出的原則，采用 redis 消息 隊列；應(yīng)用級限流： 我們采用 TPS/QPS 閥值控制限流， 防止 大量請求沖垮系統(tǒng)。令牌設(shè)計（見下圖） ：可配合限流分發(fā) 令牌數(shù)量，我們分成兩個階段，第一階段用戶進入提交訂單 頁面前，需交易系統(tǒng)根據(jù)用戶信息向分控系統(tǒng)發(fā)起一次申請 token 的請求，分控系統(tǒng)

7、將 token 保存到 redis 緩存中，為第 二階段支付使用。 第二階段交易系統(tǒng)帶著申請到的 token 發(fā) 起支付請求，支付系統(tǒng)會檢查 redis 中是否存在該 token ，如 果存在，表示第一次發(fā)起支付請求，刪除緩存中 token 后開 始支付邏輯處理；如果緩存中不存在，表示非法請求。通道 設(shè)計（見下圖） ：vip 、大客戶或者提前把資金存入電子錢包 的用戶加強權(quán)重，根據(jù)交易金額，優(yōu)先進入支付通道。緩存 設(shè)計（見下圖） ：開啟 web 服務(wù)器緩存，無狀態(tài)頁面靜態(tài)化， 查詢結(jié)果分級緩存， 定時覆蓋靜態(tài)頁 （可手動 ），如有 CDN 則 推送靜態(tài)頁到 CDN 上 （會有延遲 ）。數(shù)據(jù)庫設(shè)

8、計（見下圖） ： 數(shù)據(jù)庫的擴展方案、并發(fā)鎖方案有很多，方案各有優(yōu)缺點。 分布式事務(wù)（無論是拆子系統(tǒng)、微服務(wù)，首先考慮從功能上 拆分，單一職責高內(nèi)聚，盡量避免出現(xiàn)分布式事物問題） 。 分布式事務(wù)成熟的方案有很多， 柔性事物（兩階段、 三階段、 補償、異步通知、最大努力通知等等）舉個例子： （見下圖） 以上所有的操作需要滿足冪等性，冪等性主要是用于防止重 復提交的，因為事務(wù)操作的微服務(wù)是分布式部署的，即使有 事務(wù)的支持，也無法保證傳輸過程中會不會因為網(wǎng)絡(luò)或者其 他問題引發(fā)的中斷（如：數(shù)據(jù)方已經(jīng)接受并提交了更新，但 由于網(wǎng)絡(luò)中斷，提交方并未收到成功更新的消息，這種情況 下程序一般會返回給用戶未成功的

9、信息，而如果用戶錯誤的 任務(wù)未成功，則會重新提交申請，導致事務(wù)重復提交）二、 Q & AQ ：這種短時間內(nèi)訪客不會無限制持續(xù)增長， 而且 賣的票也很集中，百萬請求如果全部寫入緩存不會占很多內(nèi)存，再異步分批內(nèi)存中讀取來處理，可不可行？ A ：待回應(yīng)Q：請教大神一個問題，限流閾值怎么去設(shè)置呢？具體限流 有哪些緯度可以控制， 可以分享一下嘛？ A1 ：如果是合法的 訪問，限流不如分流，異步處理中保存好各階段的狀態(tài)很關(guān) 鍵（業(yè)務(wù)參數(shù)也屬于狀態(tài)一種） ，重復提交那種嚴格來講不 是限流，屬于正常的狀態(tài)控制 A2 ：限流還是訂單數(shù)，主要 是下單以及商品頁的壓力；重復提交那個不是限流，用的令 牌機制，

10、漏斗型的 A3 :限流閾值一般是通過，滑動窗口估 算出來的。如：服務(wù)壓測的并發(fā)數(shù)是100，服務(wù)處理平均耗時是 10 毫秒，這樣也可以算出一個閾值出來的，還有一種 就是應(yīng)用埋點的方式，通過對日志的分析，異步統(tǒng)計閾值。 分流是很好的方案。座位也是分價位 緩存在不同的 redis 中 A4 ：這種肯定要異步。既然是異步那每一步其實可以獨立 來設(shè)計（當然不同步驟間肯定有業(yè)務(wù)關(guān)聯(lián)） ，比如提交訂單 請求這步我可以獨立出來 就當做響應(yīng)百萬并發(fā)的上傳服務(wù) （當然還有基本的狀態(tài)更新） 。一個業(yè)務(wù)子系統(tǒng)（或者流行 語叫服務(wù)）只管與我業(yè)務(wù)相關(guān)的數(shù)據(jù)，只修改或生成與我相 關(guān)的業(yè)務(wù)數(shù)據(jù)，甚至不需要關(guān)心上一步誰下一步是

11、誰。當然 還需要一個全局協(xié)調(diào)跟蹤和驅(qū)動的系統(tǒng)，異步很類似工作流 的概念（有些地方叫引擎） A5 :其實就是基于狀態(tài)機的，就 和火車部一樣，出站就沒我毛事了。三、自由討論 3.1 直銷 銀行與II類賬戶Q:各位最近有碰到電子賬戶被監(jiān)管的情況嗎？綁卡要驗證 5 要素，但目前直銷銀行走的通道都是 4 要 素，不合規(guī) ,我這里是有幾個銀行被監(jiān)管盯上了,盯上了的要整頓。 A1 ：電子賬戶要綁卡，只能綁一類賬戶，加了這么個 驗證；目前的第三方支付渠道綁卡，都沒這個要素；說是央 行有個驗證通道，但很不穩(wěn)定，基本沒法用 A2 ：問題是現(xiàn) 在賬戶類型還沒有可靠的渠道可以區(qū)分吧？央行的是批量 的，也不所有的銀行都

12、支持，所以目前基本沒啥用。 A3 ：我 們有用戶綁二類賬戶，能入金，但是無法出金，同名賬戶也 不能；二類賬戶是不能轉(zhuǎn)賬的，代付到二類卡是失敗的，二 類賬戶是可以出金的， 即可以消費A9 :以下摘自百科：A10 : 二三類電子賬戶我們都改完了，但是目前沒有應(yīng)用場景，不 知道能做什么。當然我們小行做什么都慢悠悠的。 A11 ：于 魯義：個人銀行賬戶分類政策解讀及二類賬戶的應(yīng)用 3.2 pingpong 國內(nèi)合作支付公司 Q ：咱們這有知道 pingpong 在國 內(nèi)合作的支付公司是哪家的么？A :待回應(yīng)3.3聚合/三方收單商戶交易合法判定 Q:做聚合收單或者三方收單，對于商 戶這塊什么情況下可以判定交易合法有沒有些標準？規(guī) 則？ A :待回應(yīng)3.4交易貸Q:有朋友做交易貸的嗎