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

標籤：依據   導致   記錄   修複   資料庫   技術分享   3.4   關注   異常   

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建立關鍵業務的多資料中心應用