Crittercism: 在MongoDB上實現每天數十億次請求

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

背景

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

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

路由

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

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

對于這一問題Mike Chesnut表示：

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

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

分片替換

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

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

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

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

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

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

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

結論

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

來自：http://www.infoq.com/cn/news/2014/03/crittercism-scaling-billions-req