eBay：使用MongoDB創建關鍵業務的多數據中心應用

作為全球前十的零售品牌，eBay的活躍用戶有一億七千多萬，並擁有跨越全世界190個市場的10億購物清單，這樣的規模下，eBay絕對不允許出現宕機的情況。這也就是為什麽公司會依賴於MongoDB提供企業級平臺標準以及面向用戶的應用。

在今年的MongoDB World conference大會上，eBay的首席NoSQL DBA，Feng Qu，為大家展示了他以及他的團隊開發的用來支持企業級MongoDB部署的一整套架構—彈性應用的實用設計模式。

Qu先生首先探討了“可用性”這個概念在最近幾年的變化。在過去，網址進行周期性的定時停服維護是正常的，但是，最近幾年，隨著如今服務的全球化，用戶以及企業都不再接受這樣的停服操作。除此之外，大部分組織機構把他們的服務部署在商業硬件平臺而不是之前的Sun Solaris / Sparc 。商業硬件相對更加便宜，但是出現問題的頻率也相對較高。這些因素都實質上影響著軟件團隊對可用性的看法。這也eBay要創建“彈性設計模式”的初衷，就是要創建最佳的數據庫系統可以最大化平均失效時間（MTTF）同時最小化平均恢復時間（MTTR）。

開發人員創建應用的時候可以選擇五種企業認可的數據庫標準。除了MongoDB，還可以選擇oracle和MySQL這樣的關系型數據庫以及另外兩種nosql數據庫系統。Qu先生的團隊會為他們的選擇提一些意見，保證所選的數據庫系統可以支撐數據讀取模式、用戶壓力等等。

eBay目前運行著3000多非關系型數據庫實例，支撐著大量應用以及應用之間PB級別的數據傳輸。在過去，oracle是記錄系統，非關系型數據庫只維護一些臨時數據，現在非關系型數據庫的場景已經成熟，不僅擁有一致性、具體到點的備份以及及時恢復性，MongoDB在eBay中的有些場景中也可作為記錄系統。

盡管eBay的非關系型數據庫提供內置的故障彈性，他們也可以選擇不同的設計權衡來影響應用的表現。DBA在選擇時主要是考慮以下幾個方面：可用性、一致性、持久性、可恢復性、伸縮性以及性能。例如，使用點對點的無主設計的nosql數據庫在一個節點故障後必須啟動數據修復和重新平衡的過程，這些過程的代價很大。重新平衡的進程會嚴重影響系統的吞吐量和延遲，客戶端等待恢復的時候會造成連接堵塞，進而導致應用出現故障。為了避免這種情況，eBay在無主數據庫的上層增加了一個應用層面的分片，這個方法最初是為oracle設計的。DBA使用這種方式可以把一個大的集群分解成一系列的子集群，把重建的負荷放在個別節點上，只影響個別查詢操作。正是為了應對不同類型的數據庫行為，eBay才建立的彈性設計模式。

Qu先生為我們展示了下圖的MongoDB彈性設計模式

在這種設計模式下，MongoDB復制集的7個節點分布在eBay在美國的三個不同的數據中心。這種模式可以在主節點遇到故障時，數據庫集群可以保持可用性。可以為MongoDB的復制集成員分配優先級，這個優先級可以決定主節點遇到故障後哪個次節點可以被推舉為新的主節點。例如，可以設定在主節點故障後，位於DC1的節點可以優先被選舉為主節點。只有DC1中多有的節點都出現故障，DC2中的成員才可以被選舉為主節點，當然新的節點選舉的依據是，從原來節點中同步到最新的數據的節點才是主節點。這種模式的一個延伸做法是使用MongoDB的“大多數寫入關註”來保證跨數據中心的寫入持久性。

MongoDB的標準設計模式是eBay的“高密集、高可用讀取模式”的基礎，此模式用於支撐eBay的產品目錄模塊。為了應對產品目錄模塊的壓力，需要把MongoDB的復制集成員擴展到50個，為讀取擴展性以及彈性提供了分布式數據架構。

eBay開發了“高性能讀寫模式”以支撐高密度的寫入壓力，這種模式是把MongoDB集群的分片服務器分布在美國不同數據中心。

同樣，開發人員可以對這種模式具體的讀寫關註進行設置，調整系統持久性以及彈性以滿足不同應用的需求。

Qu先生指出，隨著MongoDB的功能的增強，MongoDB可以用來滿足更多的應用需求：

l MongoDB3.4中引入的zone sharding功能可以使eBay支撐那些對分布式以及持續寫入可用性要求較高的應用。

l 即將在MongoDB3.6中發布的可重寫操作，可以減少應用端的異常處理代碼

如果想深入了解eBay的設計模式，可以參考Feng Qu在MongoDB大會上的分享。

易趣：使用MongoDB創建關鍵業務的多數據中心應用