MongoDB的內部架構，實現事務的原理以及資料同步和分片機制各是什麼?

MongoDB 資料檔案內部結構圖見如下：


1. MongoDB 在資料儲存上按名稱空間來劃分，一個 collection 是一個名稱空間，一個索引也是一個名稱空間
2. 同一個名稱空間的資料被分成很多個 Extent，Extent 之間使用雙向連結串列連線
3. 在每一個 Extent 中，儲存了具體每一行的資料，這些資料也是透過雙向連結連線的
4. 每一行資料儲存空間不僅包括資料佔用空間，還可能包含一部分附加空間，這使得在資料 update 變大後可以不移動位置
5. 索引以 BTree 結構實現

在 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 一樣。

MongoDB 資料如何同步？


MongoDB 採用 Replica Sets 模式的同步流程:
紅色箭頭表示寫操作寫到 Primary 上，然後非同步同步到多個 Secondary 上
藍色箭頭表示讀操作可以從 Primary 或 Secondary 任意一個上讀
各個 Primary 與 Secondary 之間一直保持心跳同步檢測，用於判斷 Replica Sets 的狀態

分片機制見如下圖：


MongoDB 的分片是指定一個分片 key 來進行，資料按範圍分成不同的 chunk，每個 chunk 的大小有限制
有多個分片節點儲存這些 chunk，每個節點儲存一部分的 chunk
每一個分片節點都是一個 Replica Sets，這樣保證資料的安全性
當一個 chunk 超過其限制的最大體積時，會分裂成兩個小的 chunk
當 chunk 在分片節點中分佈不均衡時，會引發 chunk 遷移操作