# StubHub 體系結構：全球最大的票務市場背后的驚人復雜性 > 原文： [http://highscalability.com/blog/2012/6/25/stubhub-architecture-the-surprising-complexity-behind-the-wo.html](http://highscalability.com/blog/2012/6/25/stubhub-architecture-the-surprising-complexity-behind-the-wo.html)  StubHub 是一個有趣的架構，因為作為門票的做市商，他們所從事的業務與我們通常考慮的業務不同。 StubHub 規模驚人，每年以 20％的速度增長，每小時可處理 80 萬個復雜頁面，每年可售出 500 萬張門票，每小時可處理 200 萬次 API 調用。 票務空間異常復雜。 StubHub 的流量非常棘手。 突發性，圍繞不可預測的游戲結果，事件，時間表和季節。 涉及很多錢。 有很多不同的參與者。 涉及許多復雜的業務流程。 StubHub 在業務上有幾個互補但又截然不同的部分：它們有一個廣告服務器組件，可為 ESPN 等網站提供廣告，豐富的交互式 UI 和實時門票市場組件。 對我而言，最有趣的是 StubHub 如何將票務，銷售點系統，FedEx 交付，買賣雙方以及金錢等曾經一度是高接觸的實體世界帶入數字領域。 他們通過與組織（例如美國職業棒球大聯盟）的深度電子集成以及將復雜業務流程移出應用程序空間的生命周期總線來實現這一目標。 這是一個很有趣的問題，因為在處理業務構建功能成為首要任務時必須繼續處理構建的舊系統，這使問題變得更加復雜。 讓我們看看 StubHub 如何使其全部工作... ## 資源 * 查理·芬曼（Charlie Fineman）在 QCon 上的演講： [StubHub：為全球最大的票務市場](http://www.infoq.com/presentations/StubHub-Designing-for-Scale-and-Innovation-for-the-World-s-Largest-Ticket-Marketplace)設計規模和創新 ## 商業模式 * **StubHub 是用于門票** 的 eBay。 為門票買賣雙方提供一個市場。 他們不像 Ticketmaster 。 * **托管模型用于為賣家** 提供信任和安全。 信用卡記錄在 StubHub 上，當確認訂單已收到時，才轉移款項。 * **門票不是商品** 。 買家想要特定的門票，而不是看臺座位。 數量有限，沒有滯票。 賣方不斷更新價格和數量以響應市場力量。 這是一個非常活躍的市場。 ## 統計信息 * 每年 500 萬訂單 * 200 萬個活動列表/門票。 * 門票圍繞 45,000 個賽事進行。 美國職業棒球大聯盟的職缺賽季和超級碗是最活躍的時期。 * 銷售額每年以 20％的速度增長。 * 每小時可處理 600k-800k 復雜頁面。 在后期賽季每小時爆破一百萬。 * 在美國 10 到 12 個核心醒著時間的狹窄時段中，流量突發。 例如，季后賽結束后，會有買家為下一場比賽瘋狂。 * 每小時有 200 萬來自會員的 API 調用。 * 24-36 工程師。 * 這是一項高觸感的業務。 交易的支持電話過去是 1-1，但現在好多了。 員工最大的部分是客戶服務和后臺業務運營支持。 ## 平臺 * Java * 冷融合（舊版） * ActiveMQ * [SEDA](http://www.eecs.harvard.edu/~mdw/proj/seda/) （分段事件驅動的體系結構） * Lucene / Solr * Jboss * 內存緩存 * Infiniband -到 SAN 的快速網絡 * XSL * Oracle 的高級隊列 * TeamWorks -IBM 工作流構建器 * Splunk * Apache HttpClient * Log4j（使用消息格式） * 掛毯 ## 架構 * 門票的三種購買來源：Web，銷售點系統，批量上傳。 批量上傳允許將票證單上傳到系統中。 * Manager 層在 Ticket 數據庫上方提供了業務對象抽象。 它調解了所有與票證表的對話。 * 票務表會因買賣雙方的活動以及事件周圍的自然流量突發性而受到影響。 * 活躍的市場可能導致移動客戶端與系統的當前狀態過時，因此買家對舊數據做出反應。 * 兩個數據泵將來自 Tickets 數據庫的數據饋送到內部和外部系統：我的帳戶，查找和公共饋送。 我的帳戶是用戶帳戶的界面。 查找是一種搜索功能。 Public Feeds 為 ESPN 和 eBay 等網站提供支持。 * 內部供稿-包含用于儀表板，賣家是誰，銷售情況，銷售速度，熱圖等敏感信息，例如帳戶信息。它還根據敏感的市場數據供稿主頁的某些部分， 例如熱門話題，他們不想與公眾分享。 * 外部供稿（LCS）-廣告商，例如 ESPN ，都通過此供稿供稿。 廣告是通過 IP 地址映射的地理位置。 * LCS （上市目錄服務）： * 我在這里道歉，幻燈片有些偏離，并且很難使演講者與演示文稿匹配。 所有錯誤都是我的。 * 觸發器用于使修改表保持最新狀態，以進行數據庫中發生的更改。 * 更改數據捕獲作業不斷輪詢更改，并將消息注入到 ActiveMQ 代理中。 這是路由的第一級，包含 sma ll 有效負載：對象 ID，對象類型和更改日期。 * 更改數據被路由到主服務器，這是在數據中心之間進行復制的基本機制。 輔助數據中心訂閱了這些主題，這就是在數據中心之間復制數據的方式。 * 進入主數據后，數據將被注入 SEDA 隊列中進行處理（稍后會有更多介紹）。 * 未使用管理器是因為存在許多不使用管理器而直接進入數據庫的舊系統，因此數據庫是分發增量的常見點。 * 他們的大多數廣告是 Flash，但有些廣告使用 HTML 呈現。 * LCS 提供了購物體驗，例如從體育場的交互式圖形中選擇門票。 Solr 使添加這樣的新功能非常容易。 * SEDA （分段事件驅動的體系結構）在主服務器中使用 * 主服務器接收 sma ll 更新并弄清楚如何 構建進入內存緩存的內容，以便最終將路由到 Solr 。 * 使用協議緩存格式將消息緩存在 memcached 中。 * 消息發送到第二個代理，該代理將消息分散到邊緣，即 Lucene / Solr。 * 消息使用者從代理接收消息。 * 從數據庫加載實體。 * 確定更新是否有任何級聯影響。 因為 Solr 和其他 NoSQL 數據庫不進行聯接，所以例如，如果更改了樂隊名稱，則該更改必須傳播到 ll 事件。 * 序列化實體。 將其存儲在內存緩存中。 * 將消息發送到第二個 ActiveMQ 代理，該代理將消息路由到邊緣，即 Solr。 * 通過單獨的路由處理代理偵聽代理。 這曾經在 Jboss 中，但是 Jboss 會不知所措，他們遇到了饑餓問題，因此將其移出 Jboss。 該偵聽器成為系統中用于操作管理的有用閥門。 如果他們需要換出新的 Solr 索引以放入新架構，則可以關閉閥門，讓消息在消息代理中備份，然后再次打開閥門，消息將再次開始流動。 從 Solr 故障中恢復，復制索引和更新模式時，這些閥門對其操作穩定性產生了巨大影響。 * A ll 這些都是阻塞操作，因此使用線程池可以防止數據庫連接風暴。 * SEDA 是一種平滑負載的技術。 從資源管理的角度來看，這對他們是有效的。 想法是將工作分解成足夠小的部分，以至于緩慢的工作不會竊取其他用戶的線程。 工作是分階段建模的，每個階段都有自己的線程池，可作為工作節流閥。 * Solr * Solr 提供了一個不錯的文檔存儲和自然語言文本查詢功能。 * 所有搜索都基于 Solr，包括構面。 * 快速。 查詢以 10 毫秒或更短的時間返回。 他們在 SAN 上使用了 Infiniband 網絡，發現他們不需要在內存中緩存數據，他們可以通過快速的網絡以足夠快的速度為 SAN 提供數據服務。 * 潛力。 靈活的查詢語言，可以使用 ll 文本搜索以及 geo -特殊搜索。 * 支持許多輸出格式：XML，Atom， RSS ，CSV， Json 。 使與各種客戶端的集成變得更加容易。 * 高頻寫入不是很好。 在高頻寫入下復制似乎集成得不好。 看到成千上萬的更改時執行 rsync 不起作用。 您會獲得真正過時的數據。 因此，他們必須建立自己的復制機制。 * 平面數據結構。 仍然幾乎是面向行的。 他們希望支持結構更復雜的文檔。 * DCL -雙擊介紹瀏覽 * URL 映射到 ID ：類型 ID，地理位置 ID，渲染類型 ID。 * DCL （僅是 XSL ）使用類型 ID 和 Geo ID 為 LCS 創建查詢。 然后可以一般性地呈現返回的數據。 因此 ll footba ll 小組可以使用 URL 映射 XSL 和 LCS 為他們生成具有完全相同結構的相似頁面 ]。 * 巨大的生產率提高，使添加新功能變得更加容易。 頁面中的每個塊都是通過 CMS 管理的單個資產。 它們是 XSL 的大塊，針對從 LCS 中檢索到的上下文文檔進行渲染。 * A RenderChunkByName ca ll 使在 Facebook 等其他服務上呈現事件變得容易。 * 在后端進行所有這些操作以實現 SEO 目的。 當搜索引擎可以為 Ajax 編制索引時，他們可能不需要這樣做。 * gifs ，樣式表等的邊緣緩存，但是數據緩存在它們的服務器上。 * 減少每筆交易的客戶互動次數： * 客戶互動是其營業收入的最大消耗。 當情況惡化時，需要與買賣雙方共同努力以解決問題。 * 增加客戶自助服務。 顧客想知道什么時候拿到錢和票。 MyAccount 屏幕允許客戶在不使用客戶服務的情況下檢查訂單進度。 * 向賣家公開 API ，以便他們可以將這些功能集成到他們的系統中。 * IVR -集成的語音識別系統支持客戶打電話以查找其帳戶狀態。 * 現金流量對供應商很重要，因此他們致力于更快地付款。 * 與美國職棒大聯盟（Major League Baseball）的電子集成，因此他們可以在賣方實際擁有票證之前直接從賣方將票證轉讓給買方。 即時交付并極大地提高了客戶滿意度并消除了故障點。 * 生命周期總線 * 用于防止硬鏈接應用程序中的復雜工作流。 簽出應用程序不必擔心 ll 下游存在的不同業務流程。 您只需要擔心已驗證的信用卡和訂單，而不要擔心配送和電子郵件之類的問題。 * 在處理遺留問題和管理站點更改時很有用。 * 有關于 ll 主要生命周期事件的主題。 代理在 Oracle 隊列中偵聽主題。 下訂單時，它將進入未確認狀態。 偵聽器將收聽“未經確認”的主題，并通過電子郵件向賣方發送電子郵件以訪問該站點并確認訂單。 當賣方確認訂單后，那里的代理商將從買方的托管賬戶中提取款項，向買方發送電子郵件，說明賣方已確認并在何處找到機票。 確認票證后，付款便退給了賣方。 * 所有這些邏輯都與面向網站的最終用戶分離。 這些都是后臺引擎。 * TeamWorks 為這些流程建模，發現弱點，監視流程，檢查 SLA 并觸發操作。 幫助更好地優化后臺業務流程。 由于他們每年以 20％的速度增長，因此他們不希望運營團隊的年增長率達到 20％。 * FedEx 是最初的履行方式。 電子實現已添加。 業務流程如下：未確認->自動確認； 已確認->條碼重發和付款 PDF； 實現。 您要做的就是編寫在相同訂單生命周期內生存的代理，以實現新的實現模式。 該邏輯不在應用程序中。 它在代理中，是一個可單獨部署和測試的單元。 * 避免欺詐。 使用相同的生命周期模型來實現，但增加了兩個新狀態：已購買和已批準。 他們無需進行任何更改即可添加避免欺詐的功能。 他們只需要更改狀態機即可。 代理決定將其移至批準狀態或未批準狀態。 * 銷售點系統集成 * 使用兩個階段的提交：在外部系統上預訂票證，將其標記為 StubHub 中聲明的內容，在外部系統上提交購買。 * 希望對此進行概括，以便其他系統可以在交易中購買門票。 將門票與旅行或酒店購買捆綁在一起。 * Splunk 和染料 * 在 StubHub 上最大的投資回報率項目之一。 節省了很多調試時間。 * 染色-工件被放置在每個請求的 HTTP 標頭中。 * 這些使用 Log4j 記錄。 * 使用 Splunk ，如果訂單有問題，您可以使用染料標記查看日志行以向后推 ll ，然后查看 ll 屬于請求的呼叫，包括對 LCS 之類的其他服務的二次呼叫。 追溯活動很容易。 * 確實類似于 Splunk 。 就像日志行的文檔存儲。 將染料標記和 ID 排序到日志行，就像一系列鍵值對一樣， Splunk 使得查看日志變得非常容易。 他們的儀表板是使用 Splunk 編寫的，用于統計信息，例如每分鐘的事務，每分鐘的失敗。 您可以根據需要對數據進行切片和切塊。 * 將 Log4j 與消息格式一起使用，以便它不會創建動態字符串。 ## 得到教訓 * **可擴展性是專業化** 。 每個問題空間都有其獨特的特征，必須構建任何系統來解決該特定問題。 StubHub 受制于對安全購買體驗的需求，票務市場的獨特性質，突發流量以及事件多變的局面。 他們的系統必須反映這些要求。 * **從一開始就使用抽象層** 。 否則，您將無法繼續為舊客戶提供支持，而超出了您的承受能力。 * **生產中的烘烤** 。 實施多種解決方案，并在生產中進行審核，以確定哪個版本更好。 StubHub 在生產中測試了兩個不同的數據泵版本，以發現哪種版本更合適。 您不想支持多種基礎架構。 * **將工作移出 Jboss** 。 大量請求可能會導致 Jboss 餓死，因此他們將工作移到 Jboss 之外。 * **通過因果鏈** 滲濾染料。 檢測請求，以便可以在整個堆棧中跟蹤請求。 這是一個巨大的投資回報，能夠調試整個堆棧中的問題。 * **優化業務流程。** 系統之間的電子集成。 通過充當賣方，買方和 MLB 之間的協調者，他們能夠提高客戶滿意度并消除交易中的大量可能失敗點。 購買了受歡迎的銷售點程序，以便他們可以與它集成。 * **建立在您自己的 API** 上。 他們花費大量時間嘗試在自己的 API 上構建自己的應用程序，以便他們可以更好地管理其用戶和合作伙伴的體驗。 * **一般定義資產** 。 定義資產以便可以在任何上下文中呈現它們，可以輕松組成不同格式的頁面并在其他網站上呈現事件。 * **從 ROI 透視圖** 最大化開發。 尋找可提高開發人員 ROI 的項目。 使用 Solr 對他們來說是一個巨大的勝利。 它易于使用，快速且非常實用，可以立即滿足許多類型的查詢。 * **SEDA 適合阻止讀取** 。 他們的許多系統都基于阻止讀取，因此 SEDA 非常適合該用例。 線程池可防止淹沒他們要使用的資源。 * **在客戶端** 上呈現。 對于像體育場館地圖這樣非常酷的交互式地圖，在客戶端上通過 ll 處理 ll 的 UI 交互可節省大量服務器負載。 即使對于具有 10-20K 列表的大型活動，下載整個列表也是一個更好的解決方案。 * **比重框架**更薄。 沉重的框架易于使用和濫用。 隱藏的復雜性使您很快失去對站點的控制。 示例：Hibernate 和基于組件的框架。 驗證和業務邏輯可能會泄漏到表示層中。 做出明智的決定。 了解遺留問題方面的問題。 * **糟糕的經歷是最好的訓練** 。 就像沒有教給如何正確做事一樣。 剛開始 StubHub 的家伙正在通過盡快發布功能來建立業務，但這留下了一筆遺產。 管理遺留物的關鍵是管理依賴關系。 使用基于代理的 Lifecycle Bus 樣式解決方案可幫助他們了解對遺留系統的依賴性。 * **使用工作流將狀態機與應用程序分離。** 不要在應用程序邏輯中嵌入復雜的流。 外部化邏輯，以便業務流程可以更靈活的方式耦合在一起。 這使系統在未來變得無限靈活和適應性強。 * **避免使用 ETL** 。 它引入了許多您不想處理的依賴項。 有風險。 當您嘗試確定財務上依賴的變更對您而言是否很大時，舊式數據模型可以真正占用資源。 * **不要縮短 CM 和部署**。 當前，對于開發人員來說，這是最大的浪費時間。 非常痛苦 現在投資您的 CM 和部署系統。 * **投資持續改進** 。 它不是免費提供的。 在項目上運行驗尸。 確保問題不再出現。 隨著公司的發展，這些東西無法擴展。 立即做出正確的決定，否則將來 ll 需要花費 3 到 5 倍來解決。 * **在系統** 中建立操作閥。 例如，如果您需要換出新的架構，請使用一個閥門，您可以在其中關閉事件并重新啟動它們。 該 Java Framework Tapestry 在哪里使用？ 您是在我們網站上還是其他地方？ “當您試圖找出變更是否會帶來巨大收益時，它們將成為您財務上依賴的系統。” 句子里有錯字，對不對？ 難道不是“當您試圖確定變更是否會創建您在財務上依賴的系統時”嗎？ 謝謝。 愛德華 我認為這個家伙在獲得我的要點方面做得很好，但是在這種情況下...是的...這很想念...我認為不是錯字。 :-)在不返回原始錄音版本的情況下，它應該類似于： “當您試圖確定更改是否會在您所依賴的系統中造成回歸時” 我真的想了解更多有關如何在 HTTP 標頭中使用 splunk 和 dye 來跟蹤整個堆棧中的每個請求的信息，從調試的角度來看，這是非常有用的功能。