使用MongoDB構建任務關鍵型多數據中心應用程序

540次閱讀

作為全球 10 大零售品牌，在全球 190 個市場擁有 170 多萬活躍買家和 10 億個實時列表，eBay 無法承受系統停機。這就是為什么該公司依賴 MongoDB 作為其核心企業數據平臺標準之一，為運行 ebay.com 的多個面向客戶的應用程序提供支持。

在今年的 MongoDB World 大會上，eBay 的首席 NoSQL DBA 曲峰展示了適用于彈性應用程序的實用設計模式——他的團隊為支持企業級 MongoDB 部署而開發的一組架構藍圖。

曲先生開始了他的會議，討論了這些年來可用性的概念是如何變化的。過去，站點為每周維護事件安排停機時間是可以接受的。隨著當今服務的全球性，無論是用戶還是企業，都不太接受！此外，大多數組織現在在商品硬件平臺上構建他們的服務，而不是過去異國情調的 Sun Solaris / Sparc 服務器。雖然商品硬件的成本要低得多，但它也經常出現故障。這兩個因素從根本上改變了工程團隊考慮可用性的方式，并促使 eBay 創建其“彈性設計模式”來制定數據庫最佳實踐，以最大限度地提高平均故障時間 (MTTF) 并最大限度地減少平均恢復時間 (MTTR)。

為了構建他們的應用程序，eBay 開發人員可以從五種企業批準的數據庫標準中進行選擇。除了 MongoDB，團隊還可以選擇使用 Oracle 或 MySQL 關系數據庫，以及兩個 NoSQL 選項。曲先生的 DBA 團隊提供有關選擇適當數據庫的指導，根據應用程序的數據訪問模式、用戶負載、數據類型等來確定選擇。

eBay 目前運行著 3,000 多個非關系型數據庫實例，支持一系列應用程序，管理它們之間的數 PB 數據。過去，Oracle 是記錄系統，而非關系型數據庫處理“參與系統”中使用的瞬態數據。然而，非關系數據庫領域已經成熟。通過一致的時間點備份和恢復，MongoDB 現在還為 eBay 的記錄系統用例提供服務。

雖然 eBay 的所有非關系數據庫選擇都提供內置的故障恢復能力，但它們做出了不同的設計權衡，可能會影響應用程序行為。DBA 團隊從六個維度評估這些差異：可用性、一致性、持久性、可恢復性、可擴展性和性能。例如，那些使用點對點、無主設計的 NoSQL 數據庫具有昂貴的數據修復和重新平衡過程，必須在節點故障后啟動。此重新平衡過程會影響應用程序吞吐量和延遲，并且會在客戶端等待恢復時導致連接堆疊，從而導致應用程序停機。為了減輕這些影響，eBay 不得不在這些無主數據庫之上分層應用程序級分片解決方案，該解決方案最初是為其 Oracle 資產開發的。這種方法使 DBA 團隊能夠將較大的集群劃分為一系列子集群，從而將重新平衡開銷隔離到較小的節點集，僅影響查詢的一個子集。eBay DBA 團隊正是針對這些不同類型的數據庫行為構建了其彈性設計模式。

曲先生介紹了eBay標準的“MongoDB Resilience Design Pattern”，如下圖1所示。

MongoDB 彈性架構的 eBay 設計模式

圖 1：eBay 的 MongoDB 彈性架構設計模式。（圖片由 eBay 的 MongoDB World 介紹提供）

在這種設計模式中，一個 7 節點的MongoDB 副本集分布在 eBay 的三個美國數據中心。這種模式確保在主數據中心發生故障時，數據庫集群可以通過在其余數據中心之間建立仲裁來保持可用性。可以為 MongoDB 的副本集成員分配選舉優先級，以控制在主要失敗的情況下哪些次要成員被視為晉升的候選人。例如，如果主副本集成員失敗，則優先選擇 DC1 本地的節點。只有當整個 DC1 發生中斷時，才會考慮選擇 DC2 中的副本集成員，并根據哪個節點提交了最近的寫入操作來選擇新的主要成員。這種設計模式可以通過使用MongoDB 的多數寫入關注進行擴展啟用跨數據中心持久寫入。

標準 MongoDB 設計模式用作演示文稿中討論的 eBay“讀取密集/高可用讀取模式”的基礎，該模式用于支持 eBay 產品目錄。對于目錄工作負載，MongoDB 副本集擴展到 50 個成員，為讀取可擴展性和彈性提供海量數據分布。

對于寫入密集型的工作負載，eBay 開發了“極高的讀/寫模式”，該模式在其美國數據中心分布了一個分片的 MongoDB 集群。

MongoDB 極高讀/寫模式的 eBay 設計模式