CouchDB 最佳 App 大奖得主 blitz.io 技术架构剖析

     <p><a href="/misc/goto?guid=4958183229505857610">Blitz</a>是一家提供压力测试服务的公司，最近它获得了在<a href="/misc/goto?guid=4958183230238660558">CouchConf</a>上评选的最佳<span class="wp_keywordlink_affiliate">CouchDB</span> App大奖，本文就是讲述<span class="wp_keywordlink_affiliate">Blitz</span>的CouchDB使用架构。他们何以能被评为最佳CouchDB App的，其具体技术架构都将在本文中为大家呈现。</p>    <p>先上一个架构图：</p>    <p><a href="/misc/goto?guid=4958183230957955037"><img title="blitzio.png" border="0" alt="blitzio.png" src="https://simg.open-open.com/show/c1b0f48fdb30c5fbf147eafa0f86995b.jpg" /></a></p>    <p>从图上我们大概能看到，他们在不同的地区分别部署了两个CouchDB集群，这两个集群分别服务不同区域的数据写入，并保持双向的数据同步。</p>    <p>需要注意的一点是，Blitz是一家测试服务提供公司，他们的主要业务是为世界各地的应用提供测试服务，所以他们的应用场景都是针对某一个点进行压力测试。后面会说到他们甚至业务构建的任务通知分发系统。</p>    <h3>Map/Reduce</h3>    <p>使用CouchDB不用Map/Reduce肯定是不可能的，在Blitz，一共有6个_design文档和30个View，以他们目前的应用需求，并没有使用过多的Reduce，只是在一些统计类的应用上使用了，而且出于对性能的考虑，他们也只采用了CouchDB内建的一些Reduce方法，比如_sum和_count这种。</p>    <h3>Multi-master 的数据同步</h3>    <p>目前他们分别在california和virginia安置了基于EC2的CouchDB集群，数据会在两个机房之间进行同步。这样做有两个好处，一是达到数据无端冗余备份的目的，到是为其服务的产品提供尽可能近的服务连接。目前他们一共有4个集群，两个是运行的CouchDB 1.0.2，另外两个运行的是CouchDB1.1，由于CouchDB之间的备份不受版本的影响，目前4个集群在同步备份。这是Blitz的无缝升级策略，先升级部分集群进行测试没有问题再进行全面升级。</p>    <h3>_<span class="wp_keywordlink_affiliate">replicator</span> 库</h3>    <p>在CouchDB1.1 版本后，添加了非常重要的_replicator 库，它最显著的特点就是在宕机重启后能保证_replicator库的完整性。所以备份同步操作更方便且稳定了。</p>    <h3>带过滤处理的_<span class="wp_keywordlink_affiliate">changes</span>库</h3>    <p>通过对_changes库进行过滤处理，Blitz构建了其通知系统。通知系统原理是，多个地区的CouchDB节点在监听_changes库时，通过一个过滤器，实现只对与自己有关的任务进行接收。这是一个类似IRC管道的通知系统。</p>    <h3>通过冲突来确认任务拥有权</h3>    <p>当一个任务通过上面说的任务系统进行分发，那么目标地区的多个节点都会被唤醒进行任务处理，那么最终谁在处理这个任务呢？我们通过修改同一个文档并产生冲突的方式来决定。这让我们对哪个节点承担了什么样的任务有一个清晰的认识。</p>    <p>来源：<a href="/misc/goto?guid=4958183231709789671">blog.mudynamics.com</a> </p>