前言

本篇文章會通過在MongoDB中的主從集群，以及集群之間同步機制和選舉，以及如何達到讀寫分離、CAP分布式理論在mongodb中如何實現，如何使用主從集群等方面去詳細解釋mongodb應對高并發，分片集群中的概念 ? ，如何使用分片集群等多方面去解析應對海量數據的解決方法。

主從集群

首先mongodb 集群 ：分為主從集群、和分片集群 ，部署多個MongoDB，集群。分為有狀態集群、無狀態集群。 從是否存放數據來區分。

無狀態集群

無需存放數據，所有的訪問的數據，都在數據庫上的。 并且不用管數據是否一致，數據安全等。

有狀態集群（衍生出主從節點）

?數據存在集群本身的，數據的狀態，需要與其他節點進行交互，維護狀態。而要解決問題的方案也就是主從集群，master? 用來處理寫 操作? 從節點? ，并且 主節點掛點時，會讀從節點上的數據。一旦遇到這個問題就會出現CAP分布式理論。數據一致性理論。 也是主從集群基礎起來的分片集群。

概念

主從集群由一組mongod維護相同數據集的實例。一個副本集包含多個數據承載節點和一個仲裁器節點（可選）。在數據承載節點中，只有一個成員被視為主要節點，而其他節點則被視為次節點。

主從復制集群提供冗余并提高數據可用性。使用不同數據庫服務器上的多個數據副本，復制可提供一定程度的容錯能力，以防止丟失單個數據庫服務器。 其中會涉及到 heartbeat心跳檢測，來保證應用之間是否正常。

集群同步機制和選舉

同步機制Oplog 以及 心跳機制 選舉機制 副本回滾? 這都是 在主從集群 需要考慮到的事情 數據進行回滾。 從CAP出發 保證 A? ?這都是 在 mongodb中需要涉及到的。 主從集群由一組mongod維護相同數據集的實例。一個副本集包含多個數據承載節點和一個仲裁器節點（可 選）。在數據承載節點中，只有一個成員被視為主要節點，而其他節點則被視為次節點。

主從復制集群提供冗余并提高數據可用性。使用不同數據庫服務器上的多個數據副本，復制可提供一定程度的容錯能力，以防止丟失單個數據庫服務器。 同步機制Oplog 在所有節點上 有 local.oplog.rs集合??，默認硬盤5% 如果寫并發非常大，超過預定大小，怎么處理？

?總的來說? 這個 oplog上是個圓環。

oplogSizeMB，考慮并發大小來定義

通過下面的指令指定同步方式 use admin db.adminCommand({replSetSyncFrom:"ip:port"}) 指定來同步方式。 心跳機制 默認2s，超過認為不可用 settings.heartbeatIntervalMillis 選舉機制策略 并在主節點掛了過后，也有自己的一套選舉機制?? 主節點與其他次節點，electionTimeoutMillis，默認10s 用大多數機制：n/2+1=3/2+1=2 vote:0 表示不參加投票選舉，只作為負載 priority: 0-1000, 數值越高，具有優先權成為主節點

當主節點不可用，則選舉符合要求的次節點為主節點 如果副本集成員數為偶數，添加仲裁器來進行選舉主節點。 仲裁器是mongod進程，但不維護數據集，通過響應其他副本集成員的心跳和選舉請求來維護集群中的仲裁機制。 仲裁節點的角色不會變化，而主節點可降級并成為一個次節點，一個次節點選舉過程中可能成為主節點 為什么不建議使用偶數個節點

大多數機制 大多數機制下，是不會出現腦裂的。 n/2+1=4/2+1=3 一旦出現 斷開的場景，另外兩臺是不能寫入的。不能選取主節點 偶數個節點是為了解決什么問 題？推薦使用奇數個？ 為了避免，機房，網段分區，出現網絡不通的情況，導致整個服 務不可用解決高可用的問題 誤解： 節省資源、為了防止出現腦裂

讀寫分離

默認情況下，客戶端從主節點讀取數據；客戶端可以指定讀取首選項，以將讀取操作發送到次節點。

集群搭建?

構建集群

通過命令方式

配置 集群的三個節點通過下面的命令方式啟動。 # 創建備用目錄sudo mkdir -p /mongodb/data01 /mongodb/data02 /mongodb/data03 啟動集群成員 # 第一個節點 sudo mongod --replSet "rs1" --bind_ip 0.0.0.0 --dbpath /mongodb/data01 --port 28018 --oplogSize 128 # 第二個節點 sudo mongod --replSet "rs1" --bind_ip 0.0.0.0 --dbpath /mongodb/data02 --port 28019 --oplogSize 128 # 第三個節點 sudo mongod --replSet "rs1" --bind_ip 0.0.0.0 --dbpath /mongodb/data03 --port 28020 --oplogSize 128

• --replSet用來指定同一個集群中的集群名稱，集群成員通過集群名字來找到組織。
• --bind_ip表示對集群成員的ip地址進行開放，集群成員之間需要網絡通訊，多個地址用逗號分隔。? 這里 我們用0.0.0.0來允許所有地址訪問，實際環境不建議這么做。
• --dbpath指定數據目錄的路徑
• --port同一臺機器上的偽集群，需要用不同的端口號來啟動
• --oplogSize限制每個mongod實例使用的磁盤空間

初始化集群成員 進入到前面的任意端口shell窗口，比如28019 sudo mongo --port 28019 在shell界面中，使用下面的配置來啟動

這樣我們就成功通過命令的方式啟動了一個主從集群。 ip地址不要配置為127.0.0.1的原因：Java客戶端驅動程序連接的時候會報下面的異常： Exception in monitor thread while connecting to server 127.0.0.1:28019 因為java客戶端，從上面的配置中獲取了集群成員的列表信息，客戶端以127.0.0.1發起訪問，客戶端本地沒有這個端口，所以報錯。

配置文件方式

配置文件方式，其實就是講命令方式中的配置挪到了配置文件中。 配置 # 如果是yum安裝方式，可以將默認配置文件復制出三個配置文件 sudo cp /etc/mongod.conf /etc/rep-mongod01.conf sudo cp /etc/mongod.conf /etc/rep-mongod02.conf sudo cp /etc/mongod.conf /etc/rep-mongod03.conf # 如果不是，則創建，準備三個配置文件 sudo vim /etc/rep-mongod01.conf sudo vim /etc/rep-mongod02.conf sudo vim /etc/rep-mongod03.conf # 準備目錄 sudo mkdir -p /mongodb/dataOne /mongodb/dataTwo /mongodb/dataThree 配置文件中的配置內容如下： systemLog: destination: file logAppend: true path: /var/log/mongodb/mongod.log # Where and how to store data.storage: dbPath: /mongodb/dataOne journal: enabled: true# engine: # wiredTiger:# how the process runs processManagement: fork: true # fork and run in background pidFilePath: /var/run/mongodb/mongod.pid # 不同的實例 timeZoneInfo: /usr/share/zoneinfo # network interfaces net:port: 38017 bindIpAll: true # replication: replication: oplogSizeMB: 128 replSetName: "rs0" 配置文件需要修改的三個地方，數據目錄、端口號、集群配置，三個配置文件的屬性配置如下：

?

?具體的可以參考下面的搭建方式包括 分片集群等。

?MongoDB集群搭建搭建的pdf 提取碼：9h46

?使用主從集群

在使用時，不要直接master

?并且在使用時，

• 驗證主從集群可用性 關閉主節點，集群能否正常提供服務？
• 讀寫分離 將寫操作應用在主節點、讀操作應用在次節點
• 讀策略 local、available、majority、linearizable、snapshot

local，只從主節點讀取數據、可能會發生 臟讀，數據可能發生回滾。 available, 從次節點讀取數據，讀取本地。 可能導致臟讀，沒有得到大多數節點認可。 majority，需要大多數節點的認可的數 據。 linearizable，只允許主節點讀取，寫策略 是大多數，得到認可的數據。 snapshot，多文檔事務，多數節點從內存 認可的數據

• 寫策略? { w: <value>, j: <boolean>, wtimeout: <number> }

?并用關心寫的結果，寫進去了，不需要響應的話。

檢查點： 每隔60s將內存數據持久化到磁盤上 j： false/true? true，在檢查點與最新操作之間，預寫日志 預估時間， 默認的需要直接寫入才能確定。

MongoDB分片

本質在于 數據塊太大 ，從而使用分片，把數據塊拆小；包括根據日期或者 hash? ?去拆分開

?分片集群中得角色：

mongos:mongs充當查詢路由器 ，在客戶端應用程序和分片群集之間提供接口。

config? server:配置 服務器 存儲集群得元數據和配置設置。從mongodb 3.4開始 必須將服務器部署為副本?

shard :每個shard 包含共享數據的子集，每個shard 可以部署為主副本集。

可以帶來分而治之的思想。

為什么需要 分片集群，也是存儲分布式，數據量大量增加， 單臺cpu有瓶頸。

分片集群是個雙刃劍,在提高系統可擴展性和性能的同時,增大了系統的復雜性,所以在實施之前請確定是必須的。

分片集群工作原理

除了分片，還有自帶的數據塊進行分區的效果

MongoDB分片集群推薦的模式是：分片集合,它是一種基于分片鍵的邏輯對文檔進行分組，分片鍵的選擇對分片非常重要，分片鍵一旦確定，MongoDB對數據的分片對應用是透明的； Tips：隨著數據量的的增大，分片會分割和遷移，以滿足數據的均勻分布。

• 請求分流：通過路由節點將請求分發到對應的分片和塊中
• 數據分流：內部提供平衡器保證數據的均勻分布，數據平均分布式請求平均分布的前提
• 塊的拆分：3.4版本塊的最大容量為64M或者10w的數據，當到達這個閾值，觸發塊的拆分，一分為二
• 塊的遷移：為保證數據在分片節點服務器分片節點服務器均勻分布，塊會在節點之間遷移。一般相差8個分塊的時候觸發

?

?不斷拆分，根據不同的數據塊大小進行遷移

搭建方式 采用下面進行就行

??MongoDB集群搭建搭建的pdf 提取碼：9h46

?

在安裝過程中 可以使用help查看對應的命令。

分片注意點與建議

分片注意點:

• 熱點 :某些分片鍵會導致所有的讀或者寫請求都操作在單個數據塊或者分片上,導致單個分片服務器嚴重不堪重負。自增長的分片鍵容易導致寫熱點問題；
• 不可分割數據塊:過于粗粒度的分片鍵可能導致許多文檔使用相同的分片鍵,這意味著這些文檔不能被分割為多個數據塊,限制了mongoDB均勻分布數據的能力；
• 查詢障礙:分片鍵與查詢沒有關聯,造成糟糕的查詢性能。

建議：

• 不要使用自增長的字段作為分片鍵,避免熱點問題；
• 不能使用粗粒度的分片鍵,避免數據塊無法分割；
• 不能使用完全隨機的分片鍵值,造成查詢性能低下；
• 使用與常用查詢相關的字段作為分片鍵,而且包含唯一字段（如業務主鍵,id等）；
• 索引對于分區同樣重要,每個分片集合上要有同樣的索引,分片鍵默認成為索引；分片集合只允許在 id和分片鍵上創建唯一索引；

?WiredTiger引擎

MongoDB從3.0引入了可插拔存儲引擎的概念。目前主要有WiredTiger、inMemory存儲引擎可供選擇。在 3.2版本之前MMAPV1是默認的存儲引擎,其采用linux操作系統內存映射技術,但一直飽受詬病；3.4以上版本默認的存儲引擎是WiredTiger,相對于MMAPV1,WiredTiger有如下優勢:

• 讀寫操作性能更好,WiredTiger能更好的發揮多核系統的處理能力；
• MMAPV1引擎使用表級鎖,當某個單表上有并發的操作,吞吐將受到限制。WiredTiger使用文檔級 鎖,由此帶來并發及吞吐的提高
• 相比MMAPV1存儲索引時WiredTiger使用前綴壓縮,更節省對內存空間的損耗；
• 提供壓縮算法,可以大大降低對硬盤資源的消耗,節省約60%以上的硬盤資源；

寫入原理

Journaling類似于關系數據庫中的事務日志。Journaling能夠使MongoDB數據庫由于意外故障后快速恢復。 MongoDB2.4版本后默認開啟了Journaling日志功能,mongod實例每次啟動時都會檢查journal日志文件看是否需要恢復。 由于提交journal日志會產生寫入阻塞,所以它對寫入的操作有性能影響,但對于讀沒有影響。在生產環境中開啟Journaling是很有必要的。

配置項?

?

InMemory存儲引擎

InMemory存儲引擎，MongoDB Enterprise中可用。它不是將文檔存儲在磁盤上，而是將它們保留在內存中。 默認情況下，內存存儲引擎使用50％的物理RAM減去1 GB。 使用場景： ?內存中存儲引擎是非持久性的，不會將數據寫入持久性存儲。非持久數據包括應用程序數據和系統數據，例如用戶，權限，索引，副本集配置，分片群集配置等。 ?高性能的讀取：副本集中的用來提供高性能查詢的次要節點，可以從其他節點恢復數據，不太適用于副本集的主要節點。 配置文件： storage: engine: inmemory

大文件存儲GridFS

在MongoDB中，使用GridFS存儲大于16 MB的文件，GridFS是用于存儲和檢索超過16 MB的BSON文檔。 GridFS不支持多文檔事務。 GridFS不會將文件存儲在單個文檔中，而是將文件分為多個部分或大塊，并將每個大塊存儲為單獨的文檔。默認情況下，GridFS使用默認的塊大小為255 kB；默認值為255 kB。也就是說，除了最后一個塊，GridFS會將文件劃分為255 kB的塊。最后一塊只有必要的大小。類似地，不大于塊大小的文件僅具有最終塊，僅使用所需的空間以及一些其他元數據。 GridFS使用兩個集合來存儲文件。fs.chunks集合存儲文件塊，fs.files集合存儲文件元數據 使用GridFS很簡單，通過mongofiles工具就能直接對文檔進行增刪改查操作。 mongofiles工具包含的功能參考幫助 mongofiles –help 上傳文件：put 查看文件列表：list 下載文件：get 刪除文件：delete 查找文件：search

總結

以上是生活随笔為你收集整理的MongoDB分片存储集群支撑海量数据的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。