mongo的选举策略

1.primary 为mongo client提供读写操作

2.secondary 作为primary的热备节点 不提供读写操作  读取primary的oplog，始终与primary保持一致。也可以提供读操作  但是不一定准确  这里涉及到读写分离的问题

3.arbitor 不提供读写操作 负责在primary节点down掉以后，提供选举操作。

arbitor也会参与投票  为了避免僵局出现 就是有两个secondary节点 这是arbitor参与后就可以执行其中一个变为primary。

hadoop无法实行选举策略的主要原因是  数据库的主从之间是数据都是一致的，可以通过选举重新建立一个primary

但是hadoop的namenode 数据跟datanode是不同的  不能采取选举机制  但是hadoop的namenode可以有一个secondary namenode  通过日志的形式  不断append 到 checkpoint文件中  当namenode挂掉以后  将该checkpoint文件拷贝过去 然后执行 bin/hadoop namenode -importCheckpoint 即可。

hadoop 还可以用zookeeper来保持同步  有个线上namenode节点  有个standby节点  这两个节点都需要在zookeeper中注册，一个为active状态，一个为standby状态，两个NameNode为了数据同步，会通过一组称作JournalNodes的独立进程进行相互通信。当active状态的NameNode的命名空间有任何修改时，会告知大部分的JournalNodes进程。standby状态的NameNode有能力读取JNs中的变更信息，并且一直监控edit log的变化，把变化应用于自己的命名空间。这样就会出现完全相同的两个namenode  当zookeeper发现其中一个挂掉以后  会将另外一个standby变为active