# HipChat 如何使用 ElasticSearch 和 Redis 存儲和索引數十億條消息 > 原文： [http://highscalability.com/blog/2014/1/6/how-hipchat-stores-and-indexes-billions-of-messages-using-el.html](http://highscalability.com/blog/2014/1/6/how-hipchat-stores-and-indexes-billions-of-messages-using-el.html)  *本文來自 [Zuhaib Siddique](http://www.linkedin.com/in/zuhaib) 的采訪， [HipChat ]](https://www.hipchat.com/) ， 團隊聊天和即時消息的制造商。* HipChat 始于一個不尋常的領域，您可能認為它沒有太大的希望，即企業組消息傳遞，但是隨著我們了解到那里有金 [企業群 [](http://www.developereconomics.com/still-building-consumer-apps-enterprise-pays-4x/) 。 這就是為什么 Atlassian 是 JIRA 和 Confluence 之類的工具開發者，他們 [在 2012 年收購了 HipChat](http://blog.hipchat.com/2012/03/07/weve-been-acquired-by-atlassian/) 。 在一個不經常聽到的故事中，大父母的資源和聯系實際上幫助 HipChat 進入了 [指數增長周期](https://s3.amazonaws.com/uploads.hipchat.com/10804/368466/10joz8sztfw4dfc/HipChat1B.jpg) 。 他們已達到 12 億條消息存儲標記，現在正每隔幾個月發送，存儲和建立索引的消息數量就增加一倍。 這種增長給曾經足夠的基礎架構帶來了巨大壓力。 HipChat 展示了一種常見的縮放模式。 從簡單開始，經歷流量激增，然后思考我們現在該怎么辦？ 通常，使用大型計算機是最佳的選擇。 他們做到了。 這給了他們一些喘息的空間，以便弄清楚下一步該怎么做。 在 AWS 上，在某個拐點之后，您將開始使用 Cloud Native，即水平擴展。 這就是他們所做的。 但是故事有一個轉折。 除了云/ SaaS 版本之外，安全方面的考慮還推動了本地版本的 HipChat 的開發。 我們將在本周晚些時候的[帖子](http://highscalability.com/blog/2014/1/8/under-snowdens-light-software-architecture-choices-become-mu.html)中詳細討論這一有趣的發展。 雖然 HipChat 并非 Google 規模，但可以從 HipChat 中學習很多有關它們如何及時索引和搜索數十億條消息的知識，這是 IRC 和 HipChat 之類的主要區別。 在不丟失消息的情況下索引和存儲負載下的消息是挑戰。 這是 HipChat 走的路，您可以學到什么？ 讓我們看看… ## 統計信息 * 每秒 60 條消息。 * 已存儲 12 億個文檔 * 4TB EBS 突襲 * AWS 上的 8 臺 ElasticSearch 服務器 * 26 個前端代理服務。 在后端應用服務器中將其翻倍。 * 18 人 * 0.5 TB 的搜索數據。 ## 平臺 * **托管**：帶有 75 個實例的 AWS EC2 East 當前全部為 Ubuntu 12.04 LTS * **數據庫**：當前用于聊天記錄的 CouchDB，正在過渡到 ElasticSearch。 MySQL-RDS 的其他所有功能 * **緩存**：Redis * **搜索**：ElasticSearch * **隊列/工作服務器**：Gearman（隊列）和 [Curler](https://github.com/powdahound/curler) ，（工作人員） * **語言**：Twisted Python（XMPP 服務器）和 PHP（Web 前端） * **系統配置**：開源 Chef + Fabric * **代碼部署**：Capistrano * **監視**：Sensu 和 monit 泵送警報到 Pagerduty * **圖表**：statsd + Graphite ## 產品 * 交通非常繁忙。 在周末和節假日，這里會很安靜。 在高峰負載期間，每秒數百個請求。 聊天消息實際上并不占流量的大部分; 它是狀態信息（離開，空閑，可用），人們在連接/斷開連接等。因此，每秒 60 條消息可能看起來很低，但這只是一個平均值。 * HipChat 希望成為您的通知中心，您可以在這里與團隊合作，并從工具和其他系統獲得所有信息。 幫助使每個人都處于循環中。 特別是在遠程辦公室。 * 之所以在 IRC 上使用 HipChat 的主要原因是，HipChat 可以存儲和索引每個會話，以便以后可以搜索它們。 強調搜索，因此您可以留在 HipChat 中。 使用此功能對團隊來說是個勝利，您可以隨時返回并記住發生了什么以及您同意做什么。 它還會將消息路由到同一用戶擁有的多個設備，并在發送消息時無法訪問您的設備時進行臨時消息緩存/重試。 * 增長來自更多的客戶，但隨著更多的客戶在每個站點使用該產品，其參與度也隨之提高。 他們的 API 集成也看到了增長。 * 消息的存儲和搜索是其系統中的主要可伸縮性瓶頸。 * HipChat 使用 XMPP，因此任何 XMPP 客戶端都可以連接到系統，這對于采用是一個巨大的勝利。 他們建立了自己的本機客戶端（Windows，Linux，Mac，iOS，Android），并具有擴展功能，例如 PDF 查看，自定義表情符號，自動用戶注冊等。 * 不久前，將 Wiki 之類的工具引入企業文化幾乎是不可能的。 現在，企業級工具似乎已被接受。 為什么現在？ * 基于文本的通信現在很普遍并且被接受。 我們擁有短信，IM 和 Skype，因此現在很自然地使用聊天工具。 * 分散的工作團隊的興起。 團隊越來越分散。 我們不能只是一起坐下來聽講座。 需要記錄所有內容，這意味著組織交流被視為一項重要資產。 * 增強功能。 內嵌圖像，gif 動畫等功能使它變得有趣，吸引了更廣泛的人群。 * HipChat 具有 [API](https://www.hipchat.com/docs/api) ，該 API 使得可以編寫類似于 [IRC 機器人](http://en.wikipedia.org/wiki/Internet_Relay_Chat_bot)的工具。 示例用法用于 Bitbucket 提交。 在 10:08，開發人員 X 提交了一些代碼來修復錯誤。 它通過 HipChat 發送，并直接鏈接到代碼提交和提交日志。 全部自動化。 Bitbucket 提交擊中了 Web 鉤子，并使用其中一個插件發布信息。 插件可幫助您編寫自己的機器人。 轉到您的 Bitbucket 帳戶。 假設我有我的 API 令牌，并且每次提交時都想發布到此 API。 對于 GitHub 類似地工作。 * 從客戶端上的 Adobe Air 開始，它泄漏了內存并會關閉計算機。 因此移至本機應用程序。 痛苦，但很好。 他們在公司各個部門的所有平臺上都有用戶。 您需要成為用戶所在的地方。 希望用戶在所有操作系統上都擁有出色的體驗。 用戶是所有人，而不僅僅是技術專家。 ## XMPP 服務器體系結構 * HipChat 基于 XMPP，消息是 [XMPP 節](http://xmpp.org/rfcs/rfc3920.html) 內的任何內容，可以是一行文本或日志的較長部分 輸出。 他們不想談論他們的 XMPP 體系結構，因此沒有很多細節。 * 他們沒有使用第三方 XMPP 服務器，而是使用 Twisted Python 和 XMPP 庫構建了自己的服務器。 這允許創建可擴展的后端，用戶管理以及輕松添加功能，而無需與其他人的代碼庫抗衡。 * AWS 上的 RDS 用于用戶身份驗證以及事務和 SQL 有用的其他區域。 這是一項穩定，可靠的技術。 對于本地產品，他們使用 MariaDB。 * Redis 用于緩存。 諸如哪些用戶位于哪個房間，狀態信息，誰在線等信息，因此與連接到哪個 XMPP 服務器無關緊要，XMPP 服務器本身不是限制。 * 痛點是 Re??dis 尚未聚類（尚未）。 為了實現高可用性，使用了熱/冷模型，因此從器件可以使用了。 從主節點到從節點的故障轉移大約需要 7 分鐘。 奴隸促銷是手工完成的，不是自動化的。 * 增加的負載暴露了代理服務器以及它們可以處理多少個客戶端的弱點。 * 這是一個實際的問題，因為不丟失消息是一個高度優先事項。 客戶表示不丟棄消息比低延遲更重要。 用戶寧愿遲到也不愿遲到。 * 使用 6 個 XMPP 服務器，系統運行良好。 隨著連接數量的增加，他們開始看到不可接受的延遲。 連接不僅來自客戶端，還包括支持其編程界面的機器人。 * 作為第一步，他們將前端服務器和應用程序服務器分開。 代理處理連接，后端應用程序處理節。 前端服務器的數量由活動的偵聽客戶端的數量決定，而不是由發送的消息數決定。 在提供及時服務的同時保持如此多的連接打開是一個挑戰。 * 解決數據存儲問題后，計劃將研究如何優化連接管理。 Twisted 效果很好，但是它們之間有很多聯系，因此必須弄清楚如何更好地處理它。 ## 存儲體系結構 * 在 HipChat 上增長的 10 億條消息不斷增長的同時，他們突破了 CouchDB 和 Lucene 解決方案存儲和搜索消息的限制。 * 認為 Redis 將是失敗點。 以為 Couch / Lucene 就足夠了。 沒有進行適當的容量規劃，也沒有查看郵件的增長率。 增長速度超出了他們的想象，因此不應該過多地關注 Redis 而是關注數據存儲。 * 當時，他們相信通過增加更多的功能進行擴展，然后再升級到越來越大的 Amazon 實例。 他們認為，隨著這種方法的發展，這種方法只能再使用 2 個月。 因此，他們必須做一些不同的事情。 * Couch / Lucene 一年未更新，因此無法進行修改。 另一個原因的另一個原因。 * 在亞馬遜上大約有十億條消息是一個轉折點。 有了專用服務器和 200 Gig 的 RAM，它們以前的體系結構可能仍然有效，但在資源有限的云中卻無法實現。 * 他們想留在亞馬遜上。 * 喜歡它的靈活性。 只需旋轉一個新實例并進行調整即可。 * 亞馬遜的脆弱讓您發展得更好。 不要將所有雞蛋都放在一個籃子里，如果某個節點出現故障，您已經處理好了，否則某些用戶的流量將會丟失。 * 使用動態模型。 可以快速丟失實例并啟動新實例。 云原生類型的東西。 隨時殺死一個節點。 殺死 Redis 大師。 5 分鐘后恢復。 目前已劃分為所有四個美國東部可用區，但尚未跨多個區域。 * EBS 僅使您擁有 1TB 的數據。 他們碰到這個限制時還不知道這個限制。 使用 Couch，他們遇到了 EBS 磁盤大小限制的問題。 HipChat 的數據為 0.5 TB。 要進行壓縮，Couch 必須將數據復制到壓縮文件中，從而使空間增加了一倍。 在周末進行壓縮時，在 2 TB RAID 上達到極限。 不需要 RAID 解決方案。 * 無法選擇 Amazon DynamoDB，因為他們正在啟動 HipChat 服務器，這是防火墻后面的托管服務。 * HipChat Server 推動技術堆棧上的決策。 私有版本是您自己的解決方案的主機。 某些客戶無法使用云/ SaaS 解決方案，例如銀行和金融機構。 NSA 嚇壞了國際客戶。 雇用了兩名工程師來創建產品的可安裝版本。 * Redis Cluster 可以是自托管的，并且可以像 ElasticSearch 一樣在 AWS 上運行。 他們使用本地版本的 MariaDB 代替 RDS。 * 無法考慮完整的 SaaS 解決方案，因為這將是一個鎖定。 * 現在過渡到 ElasticSearch。 * 已移至 ElasticSearch 作為其存儲和搜索后端，因為它可以吃掉他們可以提供的所有數據，它具有很高的可用性，只需添加更多節點即可透明地進行擴展，它是多租戶的，可以通過分片和透明方式進行透明 復制處理節點丟失，它建立在 Lucene 之上。 * 確實不需要 MapReduce 功能。 研究了 BigCouch 和 Riak Search（看起來效果不佳）。 但是 GET 上的 ES 性能相當不錯。 喜歡刪除組件的想法，少了一件麻煩的事。 ES HA 使他們對系統的可靠性感到非常有信心。 * 與 Lucene 兼容是一個巨大的勝利，因為他們所有的查詢都已經與 Lucene 兼容，因此這是自然的遷移途徑。 * 客戶數據千差萬別，從聊天記錄到圖像，因此響應類型無處不在。 他們需要能夠快速引導來自超過 12 億個文檔的查詢數據。 * 在一個越來越普遍的舉動中，HipChat 也將 ElasticSearch 用作其鍵值存儲，從而減少了所需的數據庫系統數量，從而降低了整體復雜性。 性能和響應時間是如此之好，他們以為為什么不使用它呢？ 響應時間在 10 毫秒至 100 毫秒之間。 它在某些區域擊敗了 Couch，而前面沒有任何緩存。 為什么要使用多種工具？ * 使用 ES 時，節點可能會宕機而沒有人注意，您將在重新平衡時收到有關 CPU 使用率過高的警報，但它一直在困擾。 * 有 8 個 ES 節點來處理流量的增長。 * 與所有基于 Java 的產品一樣，JVM 調整可能很棘手。 * 要使用 ES，必須對您要使用的堆空間進行容量規劃 * 測試緩存。 ES 可以緩存過濾器結果，速度非常快，但是您需要大量的堆空間。 在 8 個盒子上有 22 個堆的內存時，打開了緩存后，內存耗盡。 因此，除非有計劃，否則請關閉緩存。 * 緩存出現問題，因為它會遇到內存不足錯誤，然后失敗。 群集在幾分鐘內自我修復。 只有少數用戶注意到了問題。 * 由于網絡不可靠，Amazon 上的自動故障轉移是有問題的。 在集群中，這可能會導致選舉錯誤地發生。 * 用 ElasticSearch 解決這個問題。 最初有 6 個 ES 節點作為主節點運行。 節點將耗盡內存或遇到 GC 暫停，最重要的是網絡丟失。 然后其他人將不再能看到主人，也無法舉行選舉并宣布自己為主人。 他們的選舉架構存在缺陷，即他們不需要法定人數。 因此，出現了腦裂。 兩位大師。 造成了很多問題。 * 解決方案是在專用節點上運行 ElasticSearch 主服務器。 他們要做的就是成為主人。 從那以后一直沒有問題。 母版負責處理分片的分配方式（主要是誰），并映射副本分片的位置。 由于主機可以以出色的性能處理所有重新平衡，因此使重新平衡更加容易。 可以從任何節點查詢，并將自己做內部路由。 * 使用月份索引。 每個月都是一個單獨的索引。 每個主索引都有 8 個分片，然后在其上有兩個副本。 如果一個節點丟失，系統仍然可以運行。 * 沒有將 RDS 移入 ES。 他們需要 SQL 的東西留在 RDS / MariaDB 中，通常是用戶管理數據。 * 在主/從設置中，Redis 中有大量緩存，直到發布 Redis Cluster。 有一個 Redis stat 服務器，它在一個房間里，并且離線。 Redis 歷史記錄會緩存最后 75 條消息，以防止在首次加載會話時不斷訪問數據庫。 內部狀態或快速數據的狀態，例如登錄的人數。 ## 常規 * Gearman 用于異步工作，例如 iOS 推送和傳遞電子郵件。 * AWS West 用于災難恢復。 一切都會復制到 AWS West。 * Chef 用于所有配置。 ElasticSearch 為廚師提供了不錯的食譜。 易于上手。 與 Chef 一樣，因為您可以開始編寫 Ruby 代碼，而不使用 Puppet 風格的 DSL。 它還有一個不錯的活躍社區。 * 采集經驗。 他們現在可以使用公司的核心資產和人才，但是 Atlassian 不會弄亂什么可行，我們出于某種原因向您購買了。 可以在內部詢問，例如，如何擴展 ElasticSearch 以及 Atlassian 中的其他人何時需要幫助才能介入。總體而言，良好的經驗。 * 團隊結構扁平。 還是一個小團隊。 目前約有 18 人。 兩個人在發展。 平臺，iOS，Android，服務器端的一些開發人員以及 Web 開發工程師（法國）。 * Capistrano 用于部署到所有盒子。 * Sensu 用于監視應用程序。 忘記監視 ElasticSearch 節點的堆空間，然后遇到 OOM 問題，而沒有任何通知。 當前占堆的 75％，這是他們想要的最佳位置。 * Bamboo 用于連續集成。 * 客戶端尚未正式發布，由開發人員驅動。 有一個測試的暫存區。 * 組標志。 可以控制哪些組獲得功能以測試功能，以緩慢釋放功能并控制包裝盒上的負載。 * 功能標志。 例如，非常適合在 ElasticSearch 推出期間提供保護。 如果他們發現錯誤，則可以關閉功能并回滾到 Couch。 用戶不會注意到差異。 在 Couch 和 ElasticSearch 之間的過渡階段，他們將應用程序復制到兩個商店。 * 新的 API 版本將使用 Oauth，因此開發人員可以使用 HipChat API 在自己的服務器上進行部署。 讓客戶使用自己的服務器是一種更具可擴展性的模型。 ## 未來 * 將在幾個月內達到 20 億條消息，并且估計 ElasticSearch 可以處理大約 20 億條消息。 不確定如何處理預期的負載增加。 期望去 Amazon West 以獲得更多的數據中心可用性，并可能使更多的用戶進入不同的數據中心。 * 希望使用 AWS 的自動擴展功能。 * 進入語音，私人 1-1 視頻，音頻聊天，基本會議。 * 將來可能會使用 RabbitMQ 進行消息傳遞。 * 與 Confluence（Wiki）進一步集成。 使用 HipChat 交談，然后使用 Confluence 頁面捕獲詳細信息。 ## 課程 * **企業應用程序**中有很多錢。 向企業推銷可能會遭受酷刑。 較長的銷售周期意味著可能會遇到麻煩。 但是如果你成功了，那將是一個有利可圖的關系。 因此，您可能要考慮企業市場。 時代在變。 企業的發展可能仍然緩慢而緩慢，但是他們也正在采用新的工具和做事方式，那里有機會。 * **隱私變得越來越重要，并且在出售給企業**時會影響您的堆棧選擇。 HipChat 正在制作其產品的內部版本，以滿足不信任公共網絡或云數據的客戶的需求。 對于程序員來說，云作為平臺是非常有意義的。 對于企業而言，云可能是邪惡的。 這意味著您必須做出靈活的技術堆棧選擇。 如果您 100％依賴 AWS 上的服務，則幾乎不可能將系統移至另一個數據中心。 對于 Netflix 而言，這可能并不重要，但是如果您想向企業市場銷售產品，那就很重要。 * **放大以獲得一些呼吸空間**。 在等待弄清楚體系結構的下一步工作時，只需很少的錢，您就可以擴大規模，并給自己提供幾個月的呼吸空間。 * **選擇不能失敗的內容**。 HipChat 將永不丟失用戶聊天歷史記錄作為優先級，因此其體系結構將此優先級反映到將聊天記錄保存到磁盤，然后在宕機的系統恢復后重新加載。 * **轉到本地** 。 您的客戶在許多不同的平臺上，本機應用程序將提供最佳體驗。 對于擁有大量資源的創業公司來說，太多了??。 因此，在某個時候，將產品出售給擁有更多資源的公司是有意義的，以便您可以開發出更好的產品。 * **功能和組標志是更好的發行實踐** 。 如果您可以選擇要查看功能的組，并且可以在生產和測試中關閉功能，那么您不必擔心發布新版本。 * **選擇您真正對** 充滿信心的技術。 ElasticSearch 橫向擴展以應對增長的能力使 HipChat 對他們的解決方案充滿信心。 那個用戶會很高興的。 感覺很好。 * **成為過程流的一部分，您變得更有價值，并且很難刪除** 。 HipChat 作為人與工具之間的自然交匯點，也是編寫實現各種有用的工作流程 hack 的機器人的自然點。 這使 HipChat 成為企業中的平臺。 它啟用了原本無法構建的功能。 而且，如果您能夠做到這一點，那么就很難擺脫它。 * **AWS 需要單獨的節點存在總線** 。 荒謬的是，在云本身本身就是一件事，就是無法從客觀的第三方來源獲得機器狀態信息。 如果您查看機架，它將經常有一條單獨的狀態總線，因此插槽可以知道其他插槽是否可用。 這樣，您不必猜測。 在云中，軟件使用基于 TCP 的原始連接技術和心跳來猜測另一個節點何時關閉，這可能導致腦裂問題和故障轉移時的數據丟失。 現在是時候發展，并朝著可靠性邁出重大一步。 * **產品決策驅動器堆棧決策** 。 HipChat 服務器在技術堆棧上驅動決策。 Redis Cluster 可以是自托管的。 不能選擇 Amazon DynamoDB，因為他們正在防火墻后啟動托管服務。 * **在問題上投入很多精力只會使您到目前為止**。 您甚至需要在云中制定容量計劃。 除非您的架構從一開始就完全是 Cloud Native，否則任何架構都將具有負載拐點，在這些拐點處其架構將不再能夠處理負載。 看增長率。 投影出來。 什么會壞？ 您將如何處理？ 而且不要再犯同樣的錯誤。 HipChat 將如何處理 40 億條消息？ 不清楚。 * **知道系統的限制** 。 EBS 的存儲限制為 1 TB，這很多，但是如果您的存儲量接近該限制，則需要制定計劃。 同樣，如果您的數據庫（如 Couch）在壓縮階段使用兩倍的磁盤空間，這將影響您的限制。 * **世界會讓您感到驚訝**。 六個月前，HipChat 認為 Redis 將是最弱的一環，但它仍將保持強勁，而 Couch 和 EBS 是最弱的一環。 ## 相關文章 * [在 Reddit 上](http://www.reddit.com/r/programming/comments/1ujzel/scaling_hipchat_with_elasticsearch_and_redis/) / [在黑客新聞](https://news.ycombinator.com/item?id=7015179)上 * [為什么您仍在構建消費者應用程序？ 企業支付的費用是原來的 4 倍！](http://www.developereconomics.com/still-building-consumer-apps-enterprise-pays-4x/) * [HipChat 如何擴展到 10 億條消息](http://blog.hipchat.com/2013/10/16/how-hipchat-scales-to-1-billion-messages/) * Reddit on [HipChat 如何擴展到 10 億條消息-HipChat 的工程師 Zuhaib Siddique 解釋了其如何使用 CouchDB，ElasticSearch 和 Redis 來處理站點的負載](http://www.reddit.com/r/programming/comments/1svjjo/how_hipchat_scales_to_1_billion_messages_zuhaib) 。 * [HipChat 搜索現在由 Elasticsearch 支持](http://blog.hipchat.com/2013/08/12/hipchat-search-now-powered-by-elasticsearch/) * [HipChat ElasticSearch 聚會視頻+幻燈片](http://zuhaiblog.com/2013/12/04/hipchat-elasticsearch-meetup-video-slides/) * [SF ElasticSearch Meetup-HipChat 如何擴展為 1B 消息](http://www.youtube.com/watch?v=K2P7l98Uj9c) 26 臺前端服務器，每秒 60 條消息，似乎很重。 不錯的誠實寫作，謝謝。 非常豐富。 是的 每秒 60 條消息是不夠的。 這是錯字嗎？ 嗯 RTFA。 60 是平均，而不是一周中的全部 604800 秒。 有山峰。 我確定大多數前端服務器都用于與客戶端的連接。 每個開放的客戶端都需要維護與服務器的連接才能獲取聊天消息。 每秒那 60 條消息是進來，而不是出去。 我猜如果所有的客戶都在投票的話將會高出一噸。 這是最好的文章，我已經讀過很長時間 Mirza Tarkash 我不知道從持久性的角度來看，它們如何處理 Redis 固有的 50％故障率。 或者也許對他們是否看到類似的表現發表評論... 從 http://www.infoq.com/articles/jepsen 在 2000 次寫入中，Redis 聲稱其中 1998 年已成功完成。 但是，最終集中只有 872 個這些整數。 Redis 放棄了聲稱成功的 56％的寫入。 Alex，絕對沒有“ Redis 固有的 50％失敗率” ...我不確定您是否正確地理解了這一點。 特別是在（希望！）罕見的“裂腦”問題中，這是一個關于他們使用它的目的（并且希望每個人都將它用于輕量級工作隊列）的完全可以接受的問題。 我很高興將 Redis 用于 API 服務器上的作業隊列以及從 Logstash 進行提取，其失敗率為 0。 此外，本文還特別提到海拔是手動的，這種情況不會發生。 更進一步，沒關系，除了后端的負載。 這些是緩存服務器，而不是關鍵任務數據。 這確實是您完全不用擔心 ACID 合規性或幻像寫操作的情況。 很棒的文章。 肯定有幫助。 我確實要指出，盡管最后一段存在一些拼寫和語法問題： > 這個世界會讓您感到驚訝。 六個月前，HipChat 雖然 Redis 可能是最薄弱的一環，但它的表現仍然很強勁，而 Couch 和 EBS 是最薄弱的一環。 非常好的文章，但與許多服務器相比，數字 60 很小。 可能在“高峰時段”運送 600 或 6000 是否曾經考慮過將 Cloudant 作為擴展 CouchDB 的選擇？ 它適用于 Hothead Games。