随着web2.0兴起，高并发大数据量的应用对数据库高速响应的性能要求日趋明显，传统的关系型数据库在这方面显得有些乏力。有矛自有盾，内存DB的出现弥补了传统关系型db的不足。眼下市面流行的内存db主要有redis、memcach、mongodb。前面二者是基于key-value形式存储，而mongodb是基于关系型数据库表的一些特性的存储方式，并支持索引。

所以在一些对大数据量、数据关联度有要求的场景下，mongodb是一种不错选择。

Replica Set是mongodb的一个副本集群方案，它优越于传统的数据库主从方式。

传统的主从方式。master负责读写，slaver负责从master同步数据，一旦master宕机。slaver就废了，这样的方式在灾备方面有缺陷。而mongodb的Replica Set的集群机制攻克了这样的缺陷。

Replica Set：

主要分为：primary（主节点，提供增删查改服务），slaver（备节点。仅仅提供读）,arbiter（仲裁节点，不存储数据，仅仅负责仲裁）。

流程：client从primary节点读写数据，slaver从primary那里同步数据，当primary宕机时候。arbiter会在10秒内从众多slaver节点中选出一个健康的slaver顶替primary，这样就减轻了灾害。arbiter节点本身不存储数据。仅仅是监測集群中primary和slaver的执行情况（假设arbiter宕机，整个集群也就废了，唯一的不足之处）。

slaver仅仅提供读的功能，不能写，我们的项目查询的需求能够去连slaver节点，这样就大大减轻了primary主节点的负载。

下面是Replica Set的流程图：

Replica Set的原理我们明确了，你可能会问。我们在编程的时候，对于primary、slaver这么多db。我们一定是往primary节点写数据。假设primary节点宕机了，程序应该怎么检測。怎么找到新的primary节点呢？

不用操心。mongodb已经攻克了你的疑问。mongodb提供了对各类语言的驱动的支持。你仅仅需调用Replica Set接口，然后參照说明来使用它，以下以node.js

var Db = require(‘mongodb‘).Db,

}

var db = new Db(‘blog‘, replStat);

});

上面配置了几个节点9001、9002、9003，我们无需关注哪个是主节点、备节点、冲裁节点。驱动会自己主动推断出一个健康的主节点来给node，我们仅仅需专心写数据库的操作逻辑就能够了。

但这里存在一个问题。Replica Set在切换节点的时候，会出现一个断档期，我们知道node是异步/O的，在这个断档期，假设node在运行大量操作的话，弱小的栈内存会溢出，报：RangeError: Maximum call stack size exceeded错误。这个错误是系统级错误。会导致app崩掉，即使捕获异常或等db切换完毕，程序依旧会挂死在哪里。眼下还没找到解决办法。正在研究mongo驱动的api，试图通过一个体现切换过程状态监听的事件解决，假设该事件触发，则停止db操作，待切换完毕后再恢复，这样应该能够解决这个问题。