作為世界前十十個全球零售品牌，擁有1.7億活躍買家和10億在線市場，eBay無法承受系統停機帶來的損失。這就是為什么公司依靠MongoDB作為其核心企業數據平臺標準之一，為運行ebay.com的多個面向客戶的應用程序提供支持。

在今年的MongoDB全球大會上，eBay的首席NoSQL DBA曲峰提供了彈性應用程序的實用設計模式 — 他的團隊開發的一套支持企業級MongoDB部署的架構藍圖。

曲先生開始討論多年來可用性概念的變化。過去，網站可以接受每周維護的預定停機時間。隨著當前服務的全球化，用戶或業務都不會接受如此頻繁的停機!此外，大多數公司現在在商業硬件平臺上構建其服務，而不是以前的 Sun Solaris / Sparc服務器。雖然商業硬件的成本要低得多，但是它也經常故障。

這兩個因素從根本上改變了工程團隊如何考慮可用性，并且引導eBay創建其“彈性設計模式”，以建立最大化平均故障時間(Mean Time To Failure，MTTF)并最大限度地減少平均恢復時間(Mean Time To Recovery，MTTR)的數據庫最佳實踐。

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

eBay目前運行超過3000個非關系型數據庫實例，為一系列應用程序提供支持，可在其間管理數PB數據。 在過去，Oracle是“記錄系統”，而非關系型數據庫則處理“參與系統”中使用的臨時數據。 然而，非關系型數據庫環境已經成熟。通過一致的時間點備份和恢復，MongoDB現在也在eBay上服務于記錄系統的用例。

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

曲先生介紹了eBay的“MongoDB彈性設計模式”，如圖1所示。

圖1：MongoDB恢復架構的eBay設計模式(圖片由eBay的MongoDB世界大會演示提供)

在這種設計模式中，一個7節點的MongoDB副本集遍布eBay的三個美國數據中心。此模式可確保在主數據中心發生故障的情況下，數據庫集群可以通過在剩余的數據中心之間建立一個仲裁來保持可用性。MongoDB的副本集成員可以被分配選舉優先級，以控制哪些Slave成員被認為是在Primary成員失敗時的晉升候選人。例如，如果副本集Primary成員失敗，則DC1本地的節點將被優先選擇。只有整個DC1遭受中斷，DC2中的復制集成員才會被認為可以進行選舉，根據哪個節點已經執行最近的寫操作選擇新的Primary成員。 可以通過使用MongoDB的 majority write concern來擴展這種設計模式，以使得能夠跨數據中心持久的寫入。

標準MongoDB設計模式被用作eBay的“閱讀強化/高可用讀取模式”的基礎，該演示文稿用于為eBay產品目錄提供支持。對于目錄負載，MongoDB副本集可以擴展到50個成員，為大并發量的數據分發提供了讀取的可擴展性和恢復能力。

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

圖2：MongoDB極高讀/寫模式的eBay設計模式(圖片由eBay的MongoDB世界演示提供)

其次，eBay開發人員可以使用特定的MongoDB寫入和讀取配置來設計模式，以調整最佳滿足不同應用需求的持久性和一致性級別。

曲先生指出，隨著近期的產品功能增多，MongoDB正在越來越滿足更廣泛的應用需求：

• 對MongoDB 3.4添加區域分片使得eBay能夠為需要跨多個數據中心提供分布式、永久寫入可用性的應用程序提供服務。
• 針對即將發布的MongoDB 3.6版本的可重寫的寫入將允許eBay減少應用程序異常處理代碼。