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

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大會上的分享。