MongoDB仲裁节点的理解以及memcached,zookeeper,redis,故障恢复方案思考．

　　　在进行副本集部署时我们会添加一个或多个仲裁节点，仲裁节点不用于备份数据，由于它职责的职责是负责选举主节点，所以对硬件没有太高要求，可以将它部署在单独的服务器上，这个服务器可以是监听服务器，也可以部署在虚拟机上，但是有一点仲裁节点一定不能备份数据．仲裁节点和注解点都可以参与选举，而选举对象是各个非投票成员，也就是需要备份数据的从节点．

　　　　图列

　　这让我想起了以前了解过的zookeeper集群中的选举方案,它和MongoDB有所不同．

　　ZooKeeper采用一种称为Leader election的选举算法。在整个集群运行过程中，只有一个Leader，其他的都是Follower，如果ZooKeeper集群在运行过程中Leader出了问题，系统会采用该算法重新选出一个Leader。因此，各个结点之间要能够保证互相连接，必须配置上述映射。

ZooKeeper集群启动的时候，会首先选出一个Leader，在Leader election过程中，某一个满足选举算的结点就能成为Leader。

　　而对于memcached不提供分布式方案，我们可以利用代理服务器来实现分布式部署．而Magent就是一个memcached代理服务器，但是它不存在什么leader,secondary,所有的命令入口都是magent这个代理服务器，当某个节点出现done机时，而请求数据找不到，它会从备份节点上获取．当让我们可用通过zookeeper来管理memcached分布式集群．

　　而对于redis  当设置好slave服务器后，slave会建立和master的连接，然后发送sync命令。无论是第一次同步建立的连接还是连接断开后的重新连 接，master都会启动一个后台进程，将数据库快照保存到文件中，同时master主进程会开始收集新的写命令并缓存起来。后台进程完成写文件 后，master就发送文件给slave，slave将文件保存到磁盘上，然后加载到内存恢复数据库快照到slave上。接着master就会把缓存的命 令转发给slave。而且后续master收到的写命令都会通过开始建立的连接发送给slave。从master到slave的同步数据的命令和从 client发送的命令使用相同的协议格式。当master和slave的连接断开时slave可以自动重新建立连接。如果master同时收到多个 slave发来的同步连接命令，只会使用启动一个进程来写数据库镜像，然后发送给所有slave。对于master出现故障时，我们可以通过持久化数据来恢复，而对于salve出现故障那么它会和master重新连接然后将所有的内从快照写入slave.可见这样恢复一定是很慢的．