mongodb高可用部署有主從複製和複製集
Master-Slave 主從複製：
只需要在某一個服務啟動時加上–master 引數，而另一個服務加上–slave 與–source 引數，
即可實現同步。MongoDB 的最新版本已不再推薦此方案。主從複製雖然可以承受一定的負載壓力，但這種方式仍然是一個單點，如果主庫掛了，資料寫入就成了風險。
MongoDB 在 1.6 版本對開發了新功能replica set，這比之前的replication 功能要強大一
些，增加了故障自動切換和自動修復成員節點，各個DB 之間資料完全一致，大大降低了維
護成功。auto shard 已經明確說明不支援replication paris，建議使用replica set，replica set
故障切換完全自動。
要構建一個 MongoDB Sharding Cluster，需要三種角色：
Shard Server
即儲存實際資料的分片，每個Shard 可以是一個mongod 例項，也可以是一組mongod 例項
構成的Replica Set。為了實現每個Shard 內部的auto-failover，MongoDB 官方建議每個Shard
為一組Replica Set。
Config Server
為了將一個特定的collection 儲存在多個shard 中，需要為該collection 指定一個shard key，
例如{age: 1} ，shard key 可以決定該條記錄屬於哪個chunk。Config Servers 就是用來儲存：
所有shard 節點的配置資訊、每個chunk 的shard key 範圍、chunk 在各shard 的分佈情況、
該叢集中所有DB 和collection 的sharding 配置資訊。
Route Process
這是一個前端路由，客戶端由此接入，然後詢問Config Servers 需要到哪個Shard 上查詢或
儲存記錄，再連線相應的Shard 進行操作，最後將結果返回給客戶端。客戶端只需要將原本
發給mongod 的查詢或更新請求原封不動地發給Routing Process，而不必關心所操作的記錄
儲存在哪個Shard 上。
關於複製集配置架構官網給了建議：(https://docs.mongodb.com/manual/core/replica-set-members/)
The minimum recommended configuration for a replica set is: A primary,
a secondary,
and an arbiter.
Most deployments, however, will keep three members that store data: A primary and
two secondary
members.
大意是：最少配置複製集是一個主，一個從，一個仲裁節點。但是比較多的部署方案是部署是一個主和兩個從節點。所以說是可以沒有仲裁節點的。