MongoDB的擴展能力可以滿足你業(yè)務需求的增長——這也是為什么它的名字來源于單詞humongous（極大的）的原因。當然，這并不是說你在 使用MongoDB的路上并不會碰到一些發(fā)展的痛點。Crittercism是一家專門為手機應用程序提供技術支持的初創(chuàng)公司，該公司在過去兩年間發(fā)展迅 猛，其運營總監(jiān)Mike Chesnut于最近發(fā)表了一篇博文，描述了公司在快速發(fā)展的過程中遇到的一些MongoDB陷阱以及從中學到的經(jīng)驗。在今年6月將會舉行的 MongoDB World 大會上，Mike Chesnut將會介紹Crittercism是如何在MongoDB上實現(xiàn)每秒30,000次請求的。

背景

Crittercism 提供了世界上首個領先的移動應用 性能管理（mAPM）解決方案。其SDK被嵌入了成千上萬的應用中，在全世界有近十億用戶。該公司致力于收集性能數(shù)據(jù)，例如錯誤報告、崩潰診斷細節(jié)、面包 屑（breadcrumbs，指導航記錄）、設備/載體/OS統(tǒng)計和用戶行為等。這些數(shù)據(jù)大部分是非結構化的，并且隨著應用程序、版本、設備和使用模式的 不同變化很大。

Crittercism將所有的這些數(shù)據(jù)存儲在MongoDB中以便于收集原始信息供用戶以各種方式使用，同時還提供了將數(shù)據(jù)概括到易消化、可操作 的維度所需的分析功能。在過去的18個月中，Crittercism每天的請求量增長了超過40倍，主要的MongoDB集群現(xiàn)在存儲的數(shù)據(jù)量超過了 20TB。

路由

MongoDB文檔顯示，最常見的拓撲結構是在每一個客戶端系統(tǒng)上包含一個路由器—— 一個mongos進程 。Mike Chesnut表示他們開始的時候就是這樣做的，并且在很長的一段時間內(nèi)這種方式工作的很好。

但是隨著生產(chǎn)環(huán)境中前端應用程序服務器的數(shù)量從十幾臺增長到幾百臺，Crittercism發(fā)現(xiàn)mongos路由和mongod分片服務器之間建立了幾百、有時候甚至是幾千個連接，負載非常重。這意味著每當 chunk平衡 （MongoDB分片集群為了保持數(shù)據(jù)均勻分布所必須使用的平衡措施）發(fā)生的時候傳送存儲在 配置數(shù)據(jù)庫 中的chunk位置信息都需要花費相當長的時間。這是因為每一個mongos路由都必須清楚地知道每一個chunk都存在于集群中的哪些位置。

對于這一問題Mike Chesnut表示：

我們發(fā)現(xiàn)將 mongos 路由合并到少數(shù)幾臺主機上能夠減輕這個問題。我們產(chǎn)品的基礎設施在 AWS 上，所以我們在每個可用區(qū)域內(nèi)部署了 2 臺 mongos 服務器。這樣每個區(qū)域都有冗余，同時還為客戶端提供了到 mongos 路由的最短網(wǎng)絡路徑。我們也擔心請求路徑中會增加額外的驛站，但是通過 Chef 配置所有的客戶端讓它們僅與自己區(qū)域內(nèi)的 mongos 路由通信能夠最小化這個問題。

這種拓撲結構的變化極大地減少了 mongos 路由和 mongod 分片服務器之間的連接的數(shù)量（這一點可以通過 MMS 衡量），并且沒有明顯地降低應用程序的性能。此外我們還對 MongoDB 做了一些改進，讓它能夠更有效地完成 mongos 更新和內(nèi)部一致性檢查。借助于這些措施以及新的網(wǎng)絡拓撲結構，我們現(xiàn)在能夠在不引發(fā)性能問題的情況下平衡集群中的 chunk 。

分片替換

Crittercism公司遇到的另一個場景是需要動態(tài)地替換mongod服務器從而遷移到更大的分片上。Mike Chesnut表示：

對于這一問題我們再次采用了文檔中 推薦的最佳部署實踐 ，將 MongoDB 部署到使用大型 RAID 10 磁盤陣列并且運行著 xfs 的服務器實例上。我們使用了有 16 塊磁盤的 AWS m2.4xlarge 實例。處于性能方面的考慮，我們使用了基本的 Linux mdadm ，但是這樣也犧牲了磁盤配置靈活性。這樣做的結果是當我們需要為分片分配更多容量的時候，我們需要執(zhí)行一個遷移程序，有時候這會花費幾天的時間。這意味著我們不僅需要提前做出合適的計劃，還需要了解整個流程從而對其進行監(jiān)控并在出現(xiàn)錯誤的時候做出響應。

當所有副本的磁盤利用率大致相等的時候我們會開始一個復制集。首先我們會創(chuàng)建一個新的服務器實例，為它分配更多的磁盤，然后使用 rs.add() 方法將其添加到這個復制集中。

新副本將進入 STARTUP2 狀態(tài)并在該狀態(tài)保持一段時間（在我們的情況下通常是 2 到 3 天），在此期間它首先會復制數(shù)據(jù)，然后會通過操作日志（ oplog ）復制趕上進度并構建索引。索引的構建通常會停止復制過程（注意，這個行為在 MongoDB 2.6 中必定會改變），所以嚴格來說復制延遲時間并不是一直在縮短——在一段時間內(nèi)它會穩(wěn)步縮短，然后當一個索引構建發(fā)生的時候復制便會暫停，延遲時間會再次延長。一旦索引構建完成，那么復制將會再次恢復。值得注意的是，當索引構建發(fā)生的時候， mongostat 以及其他任何需要讀鎖的操作都將被阻塞。

副本最終會進入 SECONDARY 狀態(tài)并具備完整的功能。這時候我們可以 rs.stepDown() 一個舊的副本，關閉它上面運行的 mongod 進程，然后通過 s.remove() 方法將它從復制集中移除，讓服務器做好退出的準備。

之后復制集中的每一個成員都會重復這個過程，直到這些成員都被使用更大磁盤的新實例替換為止。

雖然這個過程有點耗時，有點乏味，但是卻可以讓我們以一種優(yōu)雅的方式增長數(shù)據(jù)庫的足跡，不會對客戶造成任何影響。

結論

和使用其他任何技術一樣，運營大規(guī)模MongoDB也需要一些知識，有些知識你可以從文檔中獲取，而另一些則來自于經(jīng)驗。通過嘗試一些不同的策略， 例如上面提到的那些，你可以發(fā)現(xiàn)一些之前并不明顯的靈活性。對于Crittercism的運維團隊而言，合并mongos路由層無論是在性能方面還是在管 理性方面都是一個巨大的成功，此外開發(fā)上面提到的遷移程序讓我們能夠持續(xù)地發(fā)展，在滿足自己業(yè)務需要的同時不會影響我們的服務或者客戶。

Crittercism: 在MongoDB上實現(xiàn)每天數(shù)十億次請求