CouchDB 最佳 App 大獎得主 blitz.io 技術架構剖析
Blitz是一家提供壓力測試服務的公司，最近它獲得了在CouchConf上評選的最佳CouchDB App大獎，本文就是講述Blitz的CouchDB使用架構。他們何以能被評為最佳CouchDB App的，其具體技術架構都將在本文中為大家呈現。
先上一個架構圖：
從圖上我們大概能看到，他們在不同的地區分別部署了兩個CouchDB集群，這兩個集群分別服務不同區域的數據寫入，并保持雙向的數據同步。
需要注意的一點是，Blitz是一家測試服務提供公司，他們的主要業務是為世界各地的應用提供測試服務，所以他們的應用場景都是針對某一個點進行壓力測試。后面會說到他們甚至業務構建的任務通知分發系統。
Map/Reduce
使用CouchDB不用Map/Reduce肯定是不可能的，在Blitz，一共有6個_design文檔和30個View，以他們目前的應用需求，并沒有使用過多的Reduce，只是在一些統計類的應用上使用了，而且出于對性能的考慮，他們也只采用了CouchDB內建的一些Reduce方法，比如_sum和_count這種。
Multi-master 的數據同步
目前他們分別在california和virginia安置了基于EC2的CouchDB集群，數據會在兩個機房之間進行同步。這樣做有兩個好處，一是達到數據無端冗余備份的目的，到是為其服務的產品提供盡可能近的服務連接。目前他們一共有4個集群，兩個是運行的CouchDB 1.0.2，另外兩個運行的是CouchDB1.1，由于CouchDB之間的備份不受版本的影響，目前4個集群在同步備份。這是Blitz的無縫升級策略，先升級部分集群進行測試沒有問題再進行全面升級。
_replicator 庫
在CouchDB1.1 版本后，添加了非常重要的_replicator 庫，它最顯著的特點就是在宕機重啟后能保證_replicator庫的完整性。所以備份同步操作更方便且穩定了。
帶過濾處理的_changes庫
通過對_changes庫進行過濾處理，Blitz構建了其通知系統。通知系統原理是，多個地區的CouchDB節點在監聽_changes庫時，通過一個過濾器，實現只對與自己有關的任務進行接收。這是一個類似IRC管道的通知系統。
通過沖突來確認任務擁有權
當一個任務通過上面說的任務系統進行分發，那么目標地區的多個節點都會被喚醒進行任務處理，那么最終誰在處理這個任務呢？我們通過修改同一個文檔并產生沖突的方式來決定。這讓我們對哪個節點承擔了什么樣的任務有一個清晰的認識。