深入剖析 MongoDB 架構

近日，軟件工程師Ricky Ho的在 他的博客里發表了一篇關于MongoDB架構（ MongoDB Architecture）的博文，雖然這是一個聽起來感覺很寬泛的話題，但是作者在文章中確實對MongoDB由內至外的架構進行了剖析。本文截取了其文章中的幾張重點架構示意圖進行簡要描述。

1、MongoDB數據文件內部結構

• MongoDB在數據存儲上按命名空間來劃分，一個Collection是一個命名空間，一個索引也是一個命名空間。

• 同一個命名空間的數據被分成很多個Extent，Extent之間使用雙向鏈表連接。

• 在每一個Extent中，保存了具體每一行的數據，這些數據也是通過雙向鏈接來連接的。

• 每一行數據存儲空間不僅包括數據占用空間，還可能包含一部分附加空間，這使得在數據Update變大后可以不移動位置。

• 索引以BTree結構實現。

2、在MongoDB中實現事務

眾所周知， MongoDB只支持對單行記錄的原子性修改，并不支持對多行數據的原子操作。但是通過上圖中的不可思議的操作步驟，實際上你也可以自己實現該事務。 其步驟如下：

• 第1步：先記錄一條事務記錄，將要修改的多行記錄的修改值寫到里面，并設置其狀態為init（如果這時候操作中斷，那么在重新啟動時，會判斷到它處于init狀態，從而將其保存的多行修改操作應用到具體的行上）。

• 第2步：然后更新具體要修改的行，將剛才寫的事務記錄的標識寫到它的tran字段中。

• 第3步：將事務記錄的狀態從init變成pending（如果在這時候操作中斷，那么在重新啟動時，會判斷到它的狀態是pending， 這時查 看其所有對應的多條要修改的記錄，如果其tran值不為空，那么就進行第4步；如果值為空，說明第4步已經執行過了，直接將其狀態從pending變成 commited就行）。

• 第4步：將需要修改的多條記錄的相應值加以修改，并且unset掉之前的tran字段。

• 第5步：將事務記錄那一條的狀態從pending變成commited，事務至此完成。

其實上面的步驟并不罕見，在支持事務的DBMS中，其事務原子性提交的保證大多都與上面類似。而事務記錄的tran那條記錄，就類似于這些DBMS中的redolog。

3、MongoDB數據同步

MongoDB采用Replica Sets模式的同步流程

本流程可簡要描述如下：

• 紅色箭頭表示寫操作可以寫到Primary上，然后異步同步到多個Secondary上。

• 藍色箭頭表示讀操作可以從Primary或Secondary任意一個中讀取。

• 各個Primary與Secondary之間一直保持心跳同步檢測，用于判斷Replica Sets的狀態。

4、分片機制

• MongoDB的分片是指定一個分片key來進行，數據按范圍分成不同的chunk，每個chunk的大小有限制。

• 有多個分片節點保存這些chunk，每個節點保存一部分的chunk。

• 每一個分片節點都是一個Replica Sets，這樣保證數據的安全性。

• 當一個chunk超過其限制的最大體積時，會分裂成兩個小的chunk。

• 當chunk在分片節點中分布不均衡時，會引發chunk遷移操作。

5、服務器角色

前面講了分片的機制，下面是具體在分片時幾種節點的角色：

• 客戶端訪問路由節點mongos來進行數據讀寫。

• config服務器保存了兩個映射關系，一個是key值的區間對應哪一個chunk的映射關系，另一個是chunk存在哪一個分片節點的映射關系。

• 路由節點通過config服務器獲取數據信息，通過這些信息，找到真正存放數據的分片節點進行對應操作。

• 路由節點還會在寫操作時判斷當前chunk是否超出限定大小。如果超出，就分列成兩個chunk。

• 對于按分片key進行的查詢和update操作來說，路由節點會查到具體的chunk然后再進行相關的工作。

• 對于不按分片key進行的查詢和update操作來說，mongos會對所有下屬節點發送請求然后再對返回結果進行合并。