主从结构

MongoDB的高可用和别的中间件的高可用方案基本类似。比如在MySQL里，接触了分库分表和主从同步；在Redis里，Redis也有主从结构；在Kafka里，分区也是有主从结构的。
所以先介绍启用了主从同步

我们的系统有一个关键组件 - MongoDB，但是在最开始的时候，MongoDB没有启用主从，是一个单节点的。因此每年总会有一两次，MongoDB崩溃不可用。所以我把MongoDB改成了主从同步，最开始的时候业务量不多，为了节省成本，我们用了推荐的配置一主两从。这种改变的好处是：当主节点崩溃后，从节点可以选举出一个新的主节点。

直接说用了几个主从节点，如果问到主从同步的话，回答oplog的内容。

引入仲裁节点

另一种思路是引入仲裁节点，所谓仲裁节点是指这个节点参与主从集群的主节点选举，但是只参与投票，类似于Elasticsearch里的仅投票节点。
这种机制在别的中间件也见过了，这类节点的好处在于它们只参与投票，也就是只关心主从选举，所以只需要很少的资源就可以运行起来

最开始的时候，我们只是部署了一主两从，两个从节点都会同步数据。后面为了进一步提高可用性，引入了仲裁节点。这些仲裁节点被部署在轻量级的服务器上，成本非常低。在引入了这些仲裁节点后，就算有一个从节点崩溃了，整个集群也基本没什么影响，因为这个时候还是有足够的节点可以投票

启用主从模式的配置服务器

我们MongoDB最开始部署的时候，配置服务器并没有启用主从模式，毕竟当时想节省资源。但是后面发现，配置服务器这个对集群的影响太大了，一旦不可用，整个集群就基本不可用了。这种情况下，我们只好引入了主从结构的配置服务器。目前配置服务器本身就有一主两从。