1 mongoDB副本集
1 副本集簡介
前邊我們介紹都是單機MongoDB的使用，在實際開發中很少會用單機MongoDB，因為使用單機會有數據丟失的風險，同時單台服務器無法做到高可用性(即當服務器宕機時，沒有替代的服務器頂上來，我們的業務也就掛了)，MongoDB中的副本集可以完美地解決上邊的兩個問題。
MongoDB的副本集本質上就是一組mongod進程。復制集的成員有:
1.Primary:主節點，負責所有的寫操作；
2.Secondaries:從節點，同步主節點的數據，保存數據副本；
3.Arbiter:仲裁節點，不保存數據，只有一個投票的作用；
副本集運行過程：主節點是集群中唯一一個負責寫操作的節點，主節點的寫操作都會記錄在其操作日志(oplog，是一個 capped collection)中，從節點復制主節點的oplog日志並執行日志中的命令，以此保持數據和主節點一致。副本集的所有節點都可以進行讀操作，但是應用程序默認從主節點讀取數據。當主節點一段時間(當前默認為10s)不和從節點通信,集群就會開始投票選取新的主節點。下圖來自官網，描述了一個一主兩從的副本集的結構，應用程序的讀寫操作默認都是通過主節點進行的。
2 副本集搭建
MongoDB的副本集搭建並不復雜，這里簡單演示一下搭建過程。搭建mongoDB副本集時，節點的個數最好是奇數，這主要是為了保證投票順利進行。這里演示搭建一個一主兩從的副本集，搭建副本集時，每個節點最好部署在不同的設備上，因為我沒有那么多電腦，所以就采用三台centos7虛擬機來搭建。
第一步 安裝mongoDB
為了方便幾台設備通信，我們在每台設備上使用 vim /etc/hosts 命令注冊一下主機信息(注意要改成自己設備的ip)，配置如下：
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 192.168.70.129 mongo01 192.168.70.131 mongo02 192.168.70.133 mongo03
在三台centos虛擬機上都安裝mongoDB，安裝可以參考第一篇中的安裝方法，注意副本集的配置相比單機多了一個replication節點，這里設置副本集的名字為MongoXset，使用命令 vim /usr/local/mongodb/bin/mongodb.conf 編輯配置文件如下：
systemLog: destination: file logAppend: true path: /usr/local/mongodb/logs/mongodb.log storage: dbPath: /usr/local/mongodb/data journal: enabled: true processManagement: fork: true net: port: 27017 bindIp: 0.0.0.0 replication: replSetName: MongoXset
第二步 初始化副本集
安裝完成后，在Robomongo中連接任意一個節點，執行以下命令初始化副本集：
//配置 config = { _id:"MongoXset", members:[ {_id:0,host:"192.168.70.129:27017"}, {_id:1,host:"192.168.70.131:27017"}, {_id:2,host:"192.168.70.133:27017"}] }
use admin //初始化 rs.initiate(config)
執行上邊的命令后，我們的副本集就搭建完成了，執行 rs.status() 查看副本集的狀態，我們看到192.168.70.133:27017的mongodb是primary（主節點）,其他兩個節點為secondary（從節點）:
{ "set" : "MongoXset", "date" : ISODate("2019-06-30T08:13:34.677Z"), "myState" : 1, "term" : NumberLong(1), "syncingTo" : "", "syncSourceHost" : "", "syncSourceId" : -1, "heartbeatIntervalMillis" : NumberLong(2000), "optimes" : { "lastCommittedOpTime" : { "ts" : Timestamp(1561882407, 1), "t" : NumberLong(1) }, "readConcernMajorityOpTime" : { "ts" : Timestamp(1561882407, 1), "t" : NumberLong(1) }, "appliedOpTime" : { "ts" : Timestamp(1561882407, 1), "t" : NumberLong(1) }, "durableOpTime" : { "ts" : Timestamp(1561882407, 1), "t" : NumberLong(1) } }, "lastStableCheckpointTimestamp" : Timestamp(1561882387, 1), "members" : [ { "_id" : 0, "name" : "192.168.70.129:27017", "health" : 1, "state" : 2, "stateStr" : "SECONDARY", "uptime" : 219, "optime" : { "ts" : Timestamp(1561882407, 1), "t" : NumberLong(1) }, "optimeDurable" : { "ts" : Timestamp(1561882407, 1), "t" : NumberLong(1) }, "optimeDate" : ISODate("2019-06-30T08:13:27Z"), "optimeDurableDate" : ISODate("2019-06-30T08:13:27Z"), "lastHeartbeat" : ISODate("2019-06-30T08:13:33.585Z"), "lastHeartbeatRecv" : ISODate("2019-06-30T08:13:34.465Z"), "pingMs" : NumberLong(0), "lastHeartbeatMessage" : "", "syncingTo" : "192.168.70.133:27017", "syncSourceHost" : "192.168.70.133:27017", "syncSourceId" : 2, "infoMessage" : "", "configVersion" : 1 }, { "_id" : 1, "name" : "192.168.70.131:27017", "health" : 1, "state" : 2, "stateStr" : "SECONDARY", "uptime" : 219, "optime" : { "ts" : Timestamp(1561882407, 1), "t" : NumberLong(1) }, "optimeDurable" : { "ts" : Timestamp(1561882407, 1), "t" : NumberLong(1) }, "optimeDate" : ISODate("2019-06-30T08:13:27Z"), "optimeDurableDate" : ISODate("2019-06-30T08:13:27Z"), "lastHeartbeat" : ISODate("2019-06-30T08:13:33.604Z"), "lastHeartbeatRecv" : ISODate("2019-06-30T08:13:34.458Z"), "pingMs" : NumberLong(0), "lastHeartbeatMessage" : "", "syncingTo" : "192.168.70.133:27017", "syncSourceHost" : "192.168.70.133:27017", "syncSourceId" : 2, "infoMessage" : "", "configVersion" : 1 }, { "_id" : 2, "name" : "192.168.70.133:27017", "health" : 1, "state" : 1, "stateStr" : "PRIMARY", "uptime" : 1281, "optime" : { "ts" : Timestamp(1561882407, 1), "t" : NumberLong(1) }, "optimeDate" : ISODate("2019-06-30T08:13:27Z"), "syncingTo" : "", "syncSourceHost" : "", "syncSourceId" : -1, "infoMessage" : "", "electionTime" : Timestamp(1561882205, 1), "electionDate" : ISODate("2019-06-30T08:10:05Z"), "configVersion" : 1, "self" : true, "lastHeartbeatMessage" : "" } ], "ok" : 1, "operationTime" : Timestamp(1561882407, 1), "$clusterTime" : { "clusterTime" : Timestamp(1561882407, 1), "signature" : { "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="), "keyId" : NumberLong(0) } } }
3 測試副本集
我們知道副本集的主節點負責所有寫操作，從節點不能執行寫操作，只會同步主節點的數據。這里簡單測試一下：連接主節點192.168.70.133:27017，執行以下命令插入一條命令：
連接從節點192.168.70.129:27017，上執行下邊的命令，我們看到從節點是不能插入數據的，但是我們可以從從節點查到主節點插入的數據（注意：必須先執行 rs.slaveOk() 后才能進行read操作)：
測試高可用性：連接主節點192.168.70.133:27017，執行命令 use admin db.shutdownServer() 關閉主節點，然后連接一個其他節點執行 rs.status() 查看副本集狀態如下，我們看到192.168.70.133:27017節點顯示不可用，而192.168.70.129:27017被選舉為新的主節點：
"members" : [ { "_id" : 0, "name" : "192.168.70.129:27017", "health" : 1, "state" : 1, "stateStr" : "PRIMARY", "uptime" : 2919, "optime" : { "ts" : Timestamp(1561885110, 1), "t" : NumberLong(2) }, "optimeDurable" : { "ts" : Timestamp(1561885110, 1), "t" : NumberLong(2) }, "optimeDate" : ISODate("2019-06-30T08:58:30Z"), "optimeDurableDate" : ISODate("2019-06-30T08:58:30Z"), "lastHeartbeat" : ISODate("2019-06-30T08:58:35.900Z"), "lastHeartbeatRecv" : ISODate("2019-06-30T08:58:34.979Z"), "pingMs" : NumberLong(0), "lastHeartbeatMessage" : "", "syncingTo" : "", "syncSourceHost" : "", "syncSourceId" : -1, "infoMessage" : "", "electionTime" : Timestamp(1561884658, 1), "electionDate" : ISODate("2019-06-30T08:50:58Z"), "configVersion" : 1 }, { "_id" : 1, "name" : "192.168.70.131:27017", "health" : 1, "state" : 2, "stateStr" : "SECONDARY", "uptime" : 3892, "optime" : { "ts" : Timestamp(1561885110, 1), "t" : NumberLong(2) }, "optimeDate" : ISODate("2019-06-30T08:58:30Z"), "syncingTo" : "192.168.70.129:27017", "syncSourceHost" : "192.168.70.129:27017", "syncSourceId" : 0, "infoMessage" : "", "configVersion" : 1, "self" : true, "lastHeartbeatMessage" : "" }, { "_id" : 2, "name" : "192.168.70.133:27017", "health" : 0, "state" : 8, "stateStr" : "(not reachable/healthy)", "uptime" : 0, "optime" : { "ts" : Timestamp(0, 0), "t" : NumberLong(-1) }, "optimeDurable" : { "ts" : Timestamp(0, 0), "t" : NumberLong(-1) }, "optimeDate" : ISODate("1970-01-01T00:00:00Z"), "optimeDurableDate" : ISODate("1970-01-01T00:00:00Z"), "lastHeartbeat" : ISODate("2019-06-30T08:58:36.291Z"), "lastHeartbeatRecv" : ISODate("2019-06-30T08:50:59.539Z"), "pingMs" : NumberLong(0), "lastHeartbeatMessage" : "Error connecting to 192.168.70.133:27017 :: caused by :: Connection refused", "syncingTo" : "", "syncSourceHost" : "", "syncSourceId" : -1, "infoMessage" : "", "configVersion" : -1 } ]
4 設置節點的優先級
在部署的時候，我們一般更願意讓穩定且性能好的設備在選舉時優先作為主節點，讓性能差的服務器不能被選舉為主節點。這就要用到優先級了，各個節點的默認優先級都是1，我們可以更改各個節點的優先級，優先級越高，被選舉為主節點的幾率就越大，優先級為0的節點不能被選舉為主節點。使用mongo shell執行下邊的命令就可以更改各個節點的優先級，這里就不再具體演示了。
//獲取集群配置 cfg=rs.config() //設置優先級 cfg.members[0].priority=1 cfg.members[1].priority=100 cfg.members[1].priority=0 //重新加載配置 rs.reconfig(cfg)
3 副本集管理的常用函數
這里匯總了一些管理副本集的相關命令，有興趣的小伙伴可以自己測試一下：
| 方法 | 描述 |
| rs.status() | 查看副本集狀態 |
| rs.initiate(cfg) |
初始化副本集 |
| rs.conf() | 獲取副本集的配置 |
| rs.reconfig(cfg) | 重新加載配置 |
| rs.add(ip:port) | 添加一個節點 |
| rs.addArb(ip:port) | 添加一個仲裁節點 |
| rs.remove(ip:port) | 刪除一個節點 |
| rs.isMaster() | 查看是否是主節點 |
| rs.slaveOk() | 讓從節點可以執行read操作 |
| rs.printReplicationInfo() | 查看oplog的大小和時間 |
| rs.printSlaveReplicationInfo() | 查看從節點的數據同步情況 |
4 C#驅動之讀寫分離實現
前邊我們已經搭建了一個一主兩從的副本集，狀態為：192.168.70.129:27017(主節點)，192.168.70.131:27017(從節點)，192.168.70.133:27017(從節點)，現在我們簡單演示一下怎么使用C#操作副本集，並實現讀寫分離。
首先添加一些測試數據：連接主節點192.168.70.129:27017，執行以下命令插入一些測試數據，接着到兩個從節點分別執行命令 rs.slaveOk() 讓節點可以進行read操作：
use myDb //清空students中的記錄 db.students.drop() //在students集合中添加測試數據 db.students.insertMany([ {"no":1, "stuName":"jack", "age":23, "classNo":1}, {"no":2, "stuName":"tom", "age":20, "classNo":2}, {"no":3, "stuName":"hanmeimei", "age":22, "classNo":1}, {"no":4, "stuName":"lilei", "age":24, "classNo":2} ])
然后寫一個控制台程序，使用 Install-Package MongoDB.Driver 添加驅動包，具體代碼如下：
class Program { static void Main(string[] args) { //連接數據庫 var client = new MongoClient("mongodb://192.168.70.133:27017, 192.168.70.131:27017, 192.168.70.129:27017"); //獲取database var mydb = client.GetDatabase("myDb"); //設置優先從從節點讀取數據 mydb.WithReadPreference(ReadPreference.Secondary); //mydb.WithReadConcern(ReadConcern.Majority); //mydb.WithWriteConcern(WriteConcern.WMajority);//這里可以設置寫入確認級別 //獲取collection var stuCollection = mydb.GetCollection<Student>("students"); //插入一條數據 stuCollection.InsertOne(new Student() { no = 5, stuName = "jim", age = 25 }); //讀取學生列表 List<Student> stuList = stuCollection.AsQueryable().ToList(); stuList.ForEach(s => Console.WriteLine($"學號:{s.no} ,姓名：{s.stuName} ,年齡：{s.age}")); Console.ReadKey(); } } /// <summary> /// 學生類 /// </summary public class Student { public int no { get; set; }//學號 public string stuName { get; set; }//姓名 public int age { get; set; }//年齡 [BsonExtraElements] public BsonDocument others { get; set; } }
注意一點：使用 var client = new MongoClient("mongodb://192.168.70.133:27017, 192.168.70.131:27017, 192.168.70.129:27017"); 獲取client時，驅動程序能夠自動判斷哪個節點是主節點。執行結果如下：
2 Sharing分片簡介
除了副本集，在Mongodb里面存在另一種集群：分片集群。所謂分片簡單來說就是將一個完整的數據分割后存儲在不同的節點上。當MongoDB存儲海量的數據時，一台機器不足以存儲數據，或者數據過多造成讀寫吞吐量不能滿足我們的需求時，可以考慮使用分片集群。
舉一個栗子：例如我們有1個億的用戶信息，選擇用戶的name列作為分片鍵(shard key),將用戶信息存儲到兩個Shard Server中，mongoDB會自動根據分片鍵將用戶數據進行分片，假如分片后第一個片(shard1)存儲了名字首字母為a~m的用戶信息，第二個片(shard2)存儲了名字首字母為n~z的用戶信息。當我們要查詢name=jack的用戶時，因為jack的首字母j在a和m之間，所以分片集群會直接到shard1中查找，這樣查詢效率就會提高很多；如果我們要插入一個name=tom的用戶，因為t在n~z之間，所以tom的信息會插入shard2中。這個栗子的分片鍵是name，當我們要查詢生日為某一天的用戶時(出生日期不是分片鍵)，mongoDB還是會去查詢所有分片服務器的數據。
分片集群的基本結構如下：
分片集群主要包含三個組件(都是mongod進程)：
1 Shard Server
存儲角色，真實的業務數據都保存在該角色中。在生產環境中每一個shard server都應該使用副本集，用於防止數據丟失，實現高可用。
2 Config Server
配置角色，存儲sharing集群的元數據和配置信息。分片集群判斷我們查詢的數據在哪個shard中，或者要將數據插入到哪一個shard中就是由Config Server中的配置決定的。Config Server也要使用副本集充當，不然Config Server宕機，配置信息就無從獲取了。
3 mongos
路由角色，這是應用程序訪問分片集群的入口，我們通過連接mongos來訪問分片集群，mongos讓整個集群看起來就像一個單獨的數據庫。mongos同樣推薦配置成副本集，不然路由角色宕機，應用程序就無法訪問集群。
分片集群各個角色一般都要配置為副本集，所以需要較多的mongod進程，如sharing 集群中的三個角色都使用一主兩從的副本集就需要9個mongod進程，這里就不再具體演示怎么去搭建分片集群，有興趣的小伙伴可以按照官網文檔搭建，或者參考園友努力哥的文章。
對於中小型應用，使用副本集就可以滿足業務需求，沒必要使用分片集群。當數據量非常大時我們可以考慮使用分片技術。在開發中使用分片集群時，只需要把mongos作為一個簡單的mongoDB實例連接即可，至於怎么去分片存儲和分片查詢會由集群自動完成。關於mongoDB的副本集和分片技術就簡單介紹到這里，本節也是mongoDB的最后一篇，更深入的應用以后在業務需要時繼續研究。如果文中有錯誤的話，希望大家可以指出，我會及時修改，謝謝！