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管道的通知系统。

通过冲突来确认任务拥有权

当一个任务通过上面说的任务系统进行分发，那么目标地区的多个节点都会被唤醒进行任务处理，那么最终谁在处理这个任务呢？我们通过修改同一个文档并产生冲突的方式来决定。这让我们对哪个节点承担了什么样的任务有一个清晰的认识。

来源：blog.mudynamics.com

技术传播，需要你我共同努力！