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

anyShare据说看到好文章不转的人,服务器容易宕机!
          

无觅相关文章插件,快速提升流量