在進行副本集部署時我們會添加一個或多個仲裁節點，仲裁節點不用於備份數據，由於它職責的職責是負責選舉主節點，所以對硬件沒有太高要求，可以將它部署在單獨的服務器上，這個服務器可以是監聽服務器，也可以部署在虛擬機上，但是有一點仲裁節點一定不能備份數據．仲裁節點和注解點都可以參與選舉，而選舉對象是各個非投票成員，也就是需要備份數據的從節點．
圖列
這讓我想起了以前了解過的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.可見這樣恢復一定是很慢的．