默認
打賞 發表評論 0
社交軟件紅包技術解密(七):支付寶紅包的海量高并發技術實踐
閱讀(1358) | 評論(0 收藏2 淘帖1 1

本文引用自InfoQ,原題《1808 億次,16 倍的超越!談支付寶紅包的高并發挑戰》,鏈接:infoq.cn/article/alipay-high-concurrency-challenge,收錄時有改動。


1、引言


螞蟻金服旗下的支付寶經過十幾年的發展,從簡單的支付工具逐步發展成互聯網金融平臺。

2013 年余額寶的崛起就是互聯網金融平臺升級的標志型事件,這一年支付寶順利進行了 PC 向無線的布局,可以說架構成功升級到移動互聯網金融平臺。

經過多年的發展,口碑和社交業務的崛起讓支付寶架構進一步在原有架構基礎上拓展出支持線下市場和社交的生活互動型架構。2015 年錢包 9.0 的發布,這個里程碑式的項目初步奠定了支付 + 移動互聯網金融 + 生活互動型混合架構。架構演進示意圖如圖 1 所示。

社交軟件紅包技術解密(七):支付寶紅包的海量高并發技術實踐_1.jpg
▲ 圖 1:架構演進示意圖

本文將為讀者剖析支付寶紅包系統背后的技術細節。

二、分享者


社交軟件紅包技術解密(七):支付寶紅包的海量高并發技術實踐_yuxinlin.jpg
于新林(青軒):2007 年加入支付寶,2012 年加入無線團隊,目前是支付事業群首席架構師。一路伴隨著支付寶的發展走過來,經歷了從支付到金融再到生活服務平臺的架構延展,具備豐富的超大型金融互聯網和超級 App 架構能力。

三、系列文章


❶ 系列文章目錄:


❷ 其它相關文章:


4、項目保障體系


當年(2015 年 12 月份)我們在第一時間得知支付寶中標央視消息后,既興奮又擔心!興奮的是,這是一次千載難逢的機會,我們終于可以一展身手。擔心的是,支付寶和央視聯合搞活動,是我們有史以來最大規模的活動,到底規模多大,我們沒有任何概念。唯一能得到的信息是,歷年觀看春晚的人數大約在 7 億多,支付寶的年度活躍用戶 4 億多,至于用戶的行為習慣,沒有任何參考模型。

雖然心里不是很有譜,但也沒那么擔心,信心來自于兩方面:

  • 1)經歷過這么多年的雙 11 和去年的除夕,多年經驗的沉淀,我們對超大規模的活動沉淀總結出一整套預測模型,而且這個預測模型經過了多次實戰檢驗,相對比較準確;
  • 2)從錢包 9.0 開始,我們已經開始布局生活服務平臺,這個版本搭建起社交和口碑兩個平臺的雛形,架構上從移動互聯網金融架構擴展出能支撐生活互動型的架構,形成了支付 + 互聯網金融 + 生活互動的混合架構,這種架構體系既能支持移動互聯網金融的高可用、資金安全、高彈性伸縮,又能支持生活互動型架構的輕巧、靈便、彈性十足的特點。架構示意圖如圖 2 所示。

社交軟件紅包技術解密(七):支付寶紅包的海量高并發技術實踐_2.jpg
▲ 圖 2:總體架構示意圖

團隊在拿到中標信息后,我們迅速決策,達成了以下指導原則:

優先確保核心鏈路,保證核心鏈路上用戶體驗順暢。萬一出現系統容量不足,系統必須能扛住洪峰,不被壓垮,即使這種情況下也要給用戶盡量友好的提示文案。在確保主鏈路基礎上,還需要照顧到支付寶 App 內幾百個非關鍵鏈路,對于非關鍵鏈路按照業務重要程度分為 4 個等級,根據等級分配不同的資源配置。


當時,經過 2 個月的精心準備,在激動人心的 4 小時結束后,整個春晚支付寶系統穩穩地扛住了 4 波洪峰,表現平穩,無論是核心鏈路還是非核心鏈路,沒有出現任何問題。4 個小時內幾乎沒有用戶因為系統、功能上的問題而產生投訴,客服同學沒有任何咨詢壓力。

用戶“咻一咻”在第二場活動達到高潮,累計互動次數達到 1808 億次,是2015年的 16 倍。20 點 38 分,“咻一咻”峰值達到 177 億次 / 分鐘。可以想象一下,幾億用戶同時拿著手機,以想戳透手機屏幕的速度點擊咻咻按鈕,幾億的請求瞬間從客戶端洪水般涌入服務端,對后臺將是多大的壓力!這么高并發情況下,如果系統設計不合理或者預測模型不準確,將立即被沖垮,應用系統一旦被沖垮,高壓下根本沒有恢復的機會。

社交軟件紅包技術解密(七):支付寶紅包的海量高并發技術實踐_77.jpg

5、五項準備


為了保證整個春晚順利進行,我們在以下 5 個方面做足了功課。

1)相對合理的超大規模壓力預測模型。前提約束條件要說明下,服務器資源是有限的。總共這么多服務器,要充分利用起來需要兩個條件。

  • 應用架構必須可以大規模擴容。如果架構不合理,即使有服務器也沒法擴容,剛好在架構演進的過程中,支付寶 App 服務端進行了 LDC 單元化改造,擴容對我們來說 so easy。
  • 模型要盡量準確。模型不準確的后果是用戶的行為習慣和預期不同,導致部分業務壓力特別大,無法正常提供服務,而另外部分服務器十分空閑,占著機器資源不干活。

2)核心鏈路和非核心鏈路徹底梳理。核心鏈路梳理和非核心鏈路梳理相對比較容易,注意以下 5 點。

  • 接入層必須具備足夠富裕的容量支撐,即使因為評估不準浪費部分機器也是可以容忍的。接入層一旦出問題,所有業務將全軍覆沒。如果接入層足夠健壯,當某個業務抗不住時,完全可以通過限流來隔離這個業務,而其他業務不受任何影響。
  • 用戶必須能進得來。也就是要保證用戶能順利登陸進來,如果用戶連登陸都受限制,體驗肯定好不到哪兒去。
  • 用戶要能玩起來。這是核心業務邏輯,如果咻都沒法咻,或者咻了半天紅包或者福卡發不出去,那也是致命的。
  • 要能保證用戶能傳播和互動起來,包括分享、加好友、聊天。
  • 非核心業務需要進行合理分級。我們大致分了 4 檔。第一檔 4 個 tab,非核心鏈路中的最高優先級,必須力保。第二檔 1 級入口,容量必須是平時的幾十倍。第三檔 2 級入口,容量是平時的十幾倍。第四檔,一、二、三檔外的其他業務,要保證系統具備自我保護能力,底線是不能被壓跨。

3)大規模生產系統全鏈路壓測。核心鏈路和非核心鏈路梳理清楚了,進行了性能優化和系統擴容后,能否達到我們預測的目標值,要靠線上全鏈路壓測來驗證。全鏈路壓測相應的原則:核心鏈路必須全部覆蓋,包括單獨壓測和混合壓測,非核心鏈路要盡最大可能覆蓋。經過項目組的努力,全鏈路壓測基本覆蓋了所有的核心鏈路和非核心鏈路,覆蓋率接近 100%。單系統或接口壓測問題不大,但混合壓測就比較頭痛,主要還是用戶行為預測的問題,為了確保萬無一失,在混合壓測時組合出多個模型進行壓測,盡最大可能暴露出系統的性能和容量問題。

4) 高頻次灰度內測和線上小規模活動預熱(2 月 1 日和 2 月 4 日兩次小規模活動)。高頻次的內部灰度測試更主要是能暴露出一些比較隱蔽的功能問題,能進行充分的業務配置演練。而兩次小規模預熱則起到了更大的作用,雖然規模沒有春晚大,但用戶行為習慣具備一定的參考性,并能相對真實地模擬春晚活動。我們在這兩次預熱活動中確實也發現了一些問題,并且根據相對真實的用戶行為習慣對系統容量進行了調整和優化,有效地防止了春晚出現資源分配不均的問題。

5) 上千個業務、技術預案和完備的應急響應體系支持。業務上主要參數化、配置化,通過服務端來控制客戶端的行為,以滿足業務多樣性需求,降低客戶端版本升級困難帶來的沖擊。技術上預案分為提前預案和應急預案。提前預案主要作用是讓服務器輕裝上陣,將計算能力節省下來供核心功能使用,比如降級日志、關掉定時任務等。而應急預案更主要是用來保命的,萬一系統在某些點出現了意外狀況,會通過所謂的大招以犧牲部分非核心業務來保核心業務,也就是丟卒保車。當然春晚因為前期工作做得比較到位,這些大招都深藏閨閣,沒機會施展。

社交軟件紅包技術解密(七):支付寶紅包的海量高并發技術實踐_66.jpg

6、八大技術難點


這么超大規模的活動,肯定存在很多技術難點,平時看不起眼的一個問題,在超大規模情況下,就可能被放大。接下來簡短總結這些技術難點。

1) 登陸:去年除夕,我們登陸上容量做的不足,導致用戶在登陸時就被擋在門外。本次春晚,我們做了硬性規定,必須能順利登陸進來,堅決不允許出現因為登陸系統處理能力不足而導致出現限流這種很不好的體驗。去年的登陸峰值大約在十幾萬每秒,今年我們提出實現百萬登陸能力,這個量是平時量的 200 倍左右,也是去年除夕峰值的 6、7 倍,而我們用戶數量也僅僅增長了 2,3 倍,百萬級別應該沒有問題,而實際上登陸量確實也在這個數量級。

目標確定好了,接下來比較難的就是如何做到這個系統容量目標。性能優化和擴容兩手抓,而且更多的是要靠性能優化,作為有追求的工程師擴容不應該是首選。經過 1 個月左右極致的性能優化,最終機器僅僅擴容到原來的 4 倍,大約在幾千臺,其他的提升全部通過性能優化實現。

2)如何應對洪峰(圖 3 是簡單的架構示意圖): 可以想象,幾億用戶同時在線,在幾乎同一時刻進行咻咻操作,瞬間洪水般流量直接沖進來,當時秒級峰值達到了 2.95 億次。對于這么大的流量,我們使用了漏斗形的分流、導流方案。客戶端請求到我們的網絡設備后,從應用視角我們大體分為三層 LVS、spanner、gateway。這兒你可以看作一個漏斗,越往里層,可以處理的請求越小。之所以這么設計,還是基于業務和用戶體驗,對于咻一咻,雖然有 2.95 億次請求,但我們的獎品個數是有限的,每場只有 6000 萬個現金紅包和上億張福卡。如果發獎能力達到了 6000 萬每秒,那 6000 萬個現金紅包瞬間被秒光,這也不是業務和用戶想看到的。我們平衡下來,將獎品(現金紅包 + 福卡)發放能力設定在 100 萬每秒,大約可以在幾分鐘內順利發完這 6000 萬個現金紅包。

這里有幾個關鍵點,gateway 的處理能力是千萬級別,集中咻咻大約用掉了 100 萬,剩下 900 萬是給其他業務的。當大量咻咻請求沒到 gateway 時,lvs 和 spanner 要能正確處理,給用戶比較好的體驗,不能出現任何限流問題,這也符合用戶沒有中獎預期。我們的處理方案是,如果咻咻請求沒到后端,給用戶隨機顯示彩蛋(包括文案、圖片、視頻等)。對于 spanner 雖然處在網絡更外層,但也需要理解部分業務邏輯。比如要能識別出不同的 rpc 請求,尤其是要能區分出咻咻接口。如果 spanner 不做任何識別,只管向網關轉發 1000 萬請求,那肯定將導致轉發的咻咻請求超過 100 萬,而擠占了其他業務的配額,導致其他業務被 spanner 限流無法正常處理。

社交軟件紅包技術解密(七):支付寶紅包的海量高并發技術實踐_3.jpg
▲ 圖 3:網絡漏斗模型示意圖

3)活動獎品控制系統:春晚一共搞了 4 場活動,大約發了 2.3 億個現金紅包和十幾億張福卡。在這么大規模的活動下,我們做到了 0 差錯 0 資損,沒有多發或者少發一個紅包,嚴格控制了福卡的發放比例,也合理控制了發獎速度。4 場活動基本控制在 3-5 分鐘內完成,嚴格按照我們設定的預期模型執行。所有這些都得益于我們的獎品控制系統,對于這個系統設計上有 3 個基本原則。

  • 1)資金 0 資損。
  • 2)百萬級的獎品處理能力。
  • 3)靈活的獎品發放控制。

4)動態技術:客戶端的一個最大的問題就是版本發布,有個成語叫做“覆水難收”,剛好比較形象地說明了這個問題。版本一旦發布,如果有問題需要讓用戶再次升級,時間已經來不急了。

為了更好地控制客戶端的行為,參數化、配置化就成了必不可少的利器。但參數化、配置化帶來了兩個問題:

  • 1)客戶端預埋了很多邏輯,極大的增加了代碼復雜度,客戶端的代碼測試難度加大,質量很難保證。;
  • 2)因為參數化、配置化,需要有機制能夠保證配置數據能盡可能實時下發給幾億客戶端,并且在最短的時間內生效。

對于客戶端復雜度增大的問題,主要通過多套機制保障:

  • 1)傳統的質量保障,加強測試力度;
  • 2)進行不同范圍內的人群進行灰度。;
  • 3)安排多輪演練,模擬各種配置場景。;
  • 4)為了保證春晚的萬無一失,年前增加了幾場小規模預熱,通過預熱發現盡可能多的問題,并進行規避;
  • 5)端版本發布后,產生的部分 bug,必須修復,通過熱補丁的方式,在不發布版本的情況下修復這些 bug。

對于配置的實時下發,我們單獨做了一套機制,使用推拉結合的方式,在最短的時間內下發配置信息。以服務端推送為主,通過 sync 機制,只要用戶在線,盡最大可能將配置數據推送到客戶端,萬一有極少量配置推送失敗,還可以通過拉的方式進行補償,這樣確保了配置數據一定能下發到客戶端。

5)資源管理:在這次春晚活動中,涉及到大量的資源,包括圖片、拜年視頻等。圖片和視頻都比較大,十幾 b 到幾百 kb 不等。當在高峰期時,如果瞬間有海量的請求到 CDN 上,這么大的請求帶寬根本扛不住。我們當時預估了大約有幾 T 的帶寬需求。

為了能有效地扛住瞬間峰值對 CDN 的壓力,我們對資源進行了有效的管理和控制。首先在客戶端預埋了幾個缺省資源,萬一真不行了,這幾個資源可以用。其次盡量提前打開入口,當用戶瀏覽過后,就將資源下載到本地。再次瀏覽時不再需要遠程訪問 CDN。最后,做了應急預案,高峰期一旦發現流量告警,緊急從視頻切換到圖片,降低帶寬壓力,確保不出現帶寬不夠而發生限流導致的黑屏等體驗不好的問題。

最后的結果可以用完美來形容,由于預熱充分,帶寬雖然很高,但沒達到我們的告警值,應急預案也沒有使用。

6)實時數據計算能力:紅包剩余個數盡可能實時準確顯示。這里有一個細節,當咻咻的時候,紅包剩余個數隨著你咻咻在不停的遞減,而且遞減的個數比較平滑,不像某些 App,出現長時間不動,動一次就是斷崖式變化。雖然這是一個不起眼的細節,但我們為了給用戶更好的體驗,讓沒搶到紅包的用戶能在最短的時間內知道盡量準確的紅包剩余個數,我們解決了這個技術難題。

我們充分利用了兩個方面的能力。一是實時的流式計算處理能力,可以在秒級收集各個服務器處理的紅包個數,并且進行匯總計算,并把這個計算結果寫在緩存中。另一方面我們充分利用每個請求頭的控制信息,在用戶每次請求的同時帶回剩余個數。客戶端收到應答后,如果發現本次請求沒有中獎,從頭部控制信息中解析出紅包剩余個數并正確顯示。

7)全鏈路壓測:支付寶有一套非常強大的線上環境壓測的利器,能夠模擬出你所想要的任何請求場景。對于參與用戶量非常大的活動,前期再完備的準備,也不能確保一定不出問題,需要對線上環境進行性能壓測。在全鏈路壓測機制下你不僅僅可以知道各個應用系統的容量水位和目標之間的差距,還能夠知道整個基礎設施層,比如數據庫、網絡、存儲等的瓶頸,讓你能夠根據壓測數據進行快速決策。

社交軟件紅包技術解密(七):支付寶紅包的海量高并發技術實踐_55.jpg

8)超大規模活動彈性計算能力:這么大規模的活動,初步計算下來,大約需要幾萬臺機器,包括應用服務器、存儲、網絡設備等。對于這么大量的資源調配,如果沒有金融云高彈性能力,短時間內部署完成,這是不可想象的。得益于金融云的高彈性能力,我們基本做到在 1 周內完成了相關資源的調配部署。

社交軟件紅包技術解密(七):支付寶紅包的海量高并發技術實踐_44.jpg

7、本文小結


在春晚的轟轟烈烈中我們收獲了很多,其中最重要的一點是我們對春晚的用戶行為有個初步的了解,如果再搞這種超大規模的活動,預測模型將更加精確。如果來年央視春晚我們繼續中標,我們將做得更加從容,更加順滑,真正做到喝著咖啡過春晚!

(原文鏈接:https://www.infoq.cn/article/alipay-high-concurrency-challenge

附錄:更多架構方面的文章匯總


[1] 有關IM架構設計的文章:
淺談IM系統的架構設計
簡述移動端IM開發的那些坑:架構設計、通信協議和客戶端
一套海量在線用戶的移動端IM架構設計實踐分享(含詳細圖文)
一套原創分布式即時通訊(IM)系統理論架構方案
從零到卓越:京東客服即時通訊系統的技術架構演進歷程
蘑菇街即時通訊/IM服務器開發之架構選擇
騰訊QQ1.4億在線用戶的技術挑戰和架構演進之路PPT
微信后臺基于時間序的海量數據冷熱分級架構設計實踐
微信技術總監談架構:微信之道——大道至簡(演講全文)
如何解讀《微信技術總監談架構:微信之道——大道至簡》
快速裂變:見證微信強大后臺架構從0到1的演進歷程(一)
17年的實踐:騰訊海量產品的技術方法論
移動端IM中大規模群消息的推送如何保證效率、實時性?
現代IM系統中聊天消息的同步和存儲方案探討
IM開發基礎知識補課(二):如何設計大量圖片文件的服務端存儲架構?
IM開發基礎知識補課(三):快速理解服務端數據庫讀寫分離原理及實踐建議
IM開發基礎知識補課(四):正確理解HTTP短連接中的Cookie、Session和Token
WhatsApp技術實踐分享:32人工程團隊創造的技術神話
微信朋友圈千億訪問量背后的技術挑戰和實踐總結
王者榮耀2億用戶量的背后:產品定位、技術架構、網絡方案等
IM系統的MQ消息中間件選型:Kafka還是RabbitMQ?
騰訊資深架構師干貨總結:一文讀懂大型分布式系統設計的方方面面
以微博類應用場景為例,總結海量社交系統的架構設計步驟
快速理解高性能HTTP服務端的負載均衡技術原理
子彈短信光鮮的背后:網易云信首席架構師分享億級IM平臺的技術實踐
知乎技術分享:從單機到2000萬QPS并發的Redis高性能緩存實踐之路
IM開發基礎知識補課(五):通俗易懂,正確理解并用好MQ消息隊列
微信技術分享:微信的海量IM聊天消息序列號生成實踐(算法原理篇)
微信技術分享:微信的海量IM聊天消息序列號生成實踐(容災方案篇)
新手入門:零基礎理解大型分布式架構的演進歷史、技術原理、最佳實踐
一套高可用、易伸縮、高并發的IM群聊、單聊架構方案設計實踐
阿里技術分享:深度揭秘阿里數據庫技術方案的10年變遷史
阿里技術分享:阿里自研金融級數據庫OceanBase的艱辛成長之路
社交軟件紅包技術解密(一):全面解密QQ紅包技術方案——架構、技術實現等
社交軟件紅包技術解密(二):解密微信搖一搖紅包從0到1的技術演進
社交軟件紅包技術解密(三):微信搖一搖紅包雨背后的技術細節
社交軟件紅包技術解密(四):微信紅包系統是如何應對高并發的
社交軟件紅包技術解密(五):微信紅包系統是如何實現高可用性的
社交軟件紅包技術解密(六):微信紅包系統的存儲層架構演進實踐
社交軟件紅包技術解密(七):支付寶紅包的海量高并發技術實踐》
>> 更多同類文章 ……

[2] 更多其它架構設計相關文章:
騰訊資深架構師干貨總結:一文讀懂大型分布式系統設計的方方面面
快速理解高性能HTTP服務端的負載均衡技術原理
子彈短信光鮮的背后:網易云信首席架構師分享億級IM平臺的技術實踐
知乎技術分享:從單機到2000萬QPS并發的Redis高性能緩存實踐之路
新手入門:零基礎理解大型分布式架構的演進歷史、技術原理、最佳實踐
阿里技術分享:深度揭秘阿里數據庫技術方案的10年變遷史
阿里技術分享:阿里自研金融級數據庫OceanBase的艱辛成長之路
達達O2O后臺架構演進實踐:從0到4000高并發請求背后的努力
優秀后端架構師必會知識:史上最全MySQL大表優化方案總結
小米技術分享:解密小米搶購系統千萬高并發架構的演進和實踐
一篇讀懂分布式架構下的負載均衡技術:分類、原理、算法、常見方案等
通俗易懂:如何設計能支撐百萬并發的數據庫架構?
>> 更多同類文章 ……

即時通訊網 - 即時通訊開發者社區! 來源: - 即時通訊開發者社區!

上一篇:社交軟件紅包技術解密(六):微信紅包系統的存儲層架構演進實踐下一篇:社交軟件紅包技術解密(八):全面解密微博紅包技術方案

本帖已收錄至以下技術專輯

推薦方案
打賞樓主 ×
使用微信打賞! 使用支付寶打賞!

返回頂部
曾氏料二肖中特