構建可承極端流量的軟體系統最佳實踐

1 Ticketmaster出啥問題了？

暫停整個銷售意味著存在一個對票務結賬流程至關重要且可能導致連鎖故障的依賴性，問題可能與PayPal支付處理工作流有關。Ticketmaster依賴PayPal作為其主要的全球支付處理平臺。

2 Verified Fans系統缺陷

Ticketmaster最初實施Verified Fans系統，以區分機器人和真實人類，以打擊黃牛和門票轉售商。有350萬經過驗證的粉絲註冊進行預售。其中150萬收到邀請碼，而200萬則處等待狀態。這通常是縮短等待時間、使門票銷售更加順利的好方法。然而，泰勒·斯威夫特引起“歷史上前所未有的需求”：

• Ticketmaster原本準備好處理150萬受邀購票的粉絲，但當超過1400萬人出現時，他們不知所措
• 網站上超過15％的互動經歷問題，包括邀請碼驗證錯誤
• 一旦系統容量超過，系統未能拒絕新請求，因此使用者繼續傳送請求，最終超載和使伺服器崩潰

最終，一些使用者即使將門票放入購物車也無法結賬。為控制損失，Ticketmaster嘗試等待更多的客戶並延遲銷售，導致排隊時間更長。許多經過驗證的粉絲在這些佇列中等了幾個小時，最終卻收到錯誤訊息。一舉一動，足見慎重。設定對請求數量施加硬限制可能本可以防止許多混亂和挫敗感。

3 連鎖故障

儘管一開始就清楚Eras巡演將帶來巨大的門票需求，但這一需求的規模將在太晚才能實現。

Ticketmaster的第一個錯誤是對試圖購買門票的顧客數量準備不足。容量規劃是系統設計重要方面，當系統沒有足夠的安全保障來限制請求時，事情易失控。

事故事後分析中識別到重要因素：

在這四個因素作用，請求數量激增到驚人***35億次***，之前峰值四倍。

產生效果類似[DDoS攻擊]。雖然我相信Ticketmaster學會更加優先考慮未來更為強大的容量規劃措施，但看到一個應該為這種時刻做好準備的公司在壓力下失敗還是有些出乎意料。主要教訓應該是企業在容量規劃方面採取主動措施的***重要性***。透過正確的應急措施，類似場景可避免。

4 如何設計一個應對高需求的系統？

實時排隊是難題。如Ticketmaster的目標是讓數十萬甚至數百萬使用者實時排隊等待搶購門票的活動，那將需要大量的處理能力。時間戳粒度不足以為任何可感知數量的併發使用者排隊。 （有比實時排隊更好的為顧客提供服務的方法，但稍後討論。）

這種情況在分散式計算的世界並不新鮮，甚至有一個你可能以前聽說過的名字：“Thundering Herd（雷鳴般的群體）”問題。大型分散式系統如Facebook處理過比泰勒·斯威夫特粉絲更多的“雷鳴般的群體”問題。

可假設Ticketmaster並無太多彈性容量。彈性容量指備用伺服器的可用性，用於處理流量的增加。通常，這些額外伺服器用於非關鍵資料或非時間敏感的處理。當網站訪問量激增時，這些備用伺服器可用於幫助管理額外的負載。然而，僅增加更多計算能力似乎有點簡單化。因此，讓我們討論在需求高情況下系統如何設計擴充套件的三種方式。

5  快取

處理高流量負載的最明顯方法是儘可能快取儘可能多的資料。快取可以在伺服器或客戶端級別執行，對於頻繁請求的資源的響應特別有用。如果能夠加快交付速度，就可以為更多使用者提供服務，同時利用更少的計算能力。

6 優雅降級

經典的容量規劃考慮。最簡單形式中，優雅降級本質是一種逐漸拒絕請求的方式。隨負載增加，工作流程將如下：

優雅降級確保即使其他部分失敗，核心系統功能也是可用的。現實優雅降級的例子是自動扶梯：當自動扶梯停止移動時，它就變成樓梯。正常工作時效率更高，但最終結果一樣。

7 構建一個等待室並設定購買時間限制

Ticketmaster已經擁有一個名為“智慧佇列”的等待室，並設定一個時間限制購買門票。這都是解決機器人攻擊或使用者持有門票卻無購買意圖的好做法。

Ticketmaster並未明確規定在佇列最終解除時有多少使用者可嘗試購買門票。Ticketmaster系統試圖“保留”放入購物車的門票，然後給予完成交易的時間限制。

問題出現在購物車中的門票實際上並不可用時。當發生這種情況時，在結賬時會出現錯誤，使用者將返回到互動式座點陣圖（ISM）以將另一張門票放入購物車中。這可能導致系統列出待售門票的使用者大規模湧入。

8  第三方依賴是否毀掉Ticketmaster？

防止將來發生這種情況的Ticketmaster最佳方法確實取決於Ticketmaster的內部設計。

由於大多故障發生在使用者購物車門票後，有可能透過PayPal等支付處理依賴或VISA和Mastercard等卡提供商平臺引起的支付處理依賴引起了系統連鎖故障。

9 但需求是不是太高了？

這確∂實是問題的一部分。導致泰勒·斯威夫特巡迴演唱會前的獨特條件確保了一個對歌手下一場演出渴望不已的粉絲群體。她長時間舞臺缺席，加上熱切的後疫情音樂會觀眾的熱情，創造對門票的前所未有需求。

Ticketmaster估計，“根據我們網站訪問量，泰勒需要進行超過900場體育場演出（幾乎是她正在進行的演出次數的20倍）。”即使Ticketmaster能夠完美地進行一次釋出，許多粉絲仍然可能一無所獲。再加上她在北美巡演的社交媒體炒作，不難看出為歐洲Swifties銷售門票將是一項挑戰。

咋做？總的來說，透過部署上面提到的所有緩解策略（快取、彈性需求、優雅降級等），為10億次系統呼叫做好準備是一個好的做法。這比Ticketmaster報告的35億流量要多得多，因此可能是他們的系統被一個引起系統中連鎖故障的棘手瓶頸所阻塞。

10 有限發售系統的未來

暫時放下容量規劃，從使用者角度考慮預售流程。

一些使用者認為Ticketmaster的Verified Fans系統複雜。許多粉絲報告說他們花了幾個小時在佇列中，最終在佇列前面時卻遇到結賬錯誤。整個預售流程需要很多時間，有時長達四到五小時。這還不包括註冊為Verified Fan並收到預售程式碼所需準備時間。

對有正常日常職責的普通粉絲，這承諾可能是不可承受之重。可新增多層粒度以幫助減輕軟體系統和消費者壓力：

雖然我不認為Ticketmaster會完全推翻他們的預售工作流程，但重要的是要記住，容量限制和其他系統設計瓶頸有時可以透過最佳化其他方面來解決。

這種全面解決問題的方法是系統設計的關鍵方面。