MONGODB 讀寫佇列增高與寫延遲與多粒度鎖

這個問題來自於我們內部的一個專案，本身MONGODB 並沒有特別的大，只是偶發有讀寫佇列瞬時增高的情況。在發生這個情況的時候，會出現global lock 同時會出現寫入緩慢的問題。

所以這個問題出現後我發現我對MOGNODB 的鎖真的不瞭解，所以解決問題之前必須弄明白。

首先根據我們的認知，mongodb是一個高速型的資料庫產品，也就是說MONGODB 和傳統資料庫不一樣，如果你的查詢在 500ms 已經可以算為慢查詢了，而在很多傳統資料庫中，這是正常的。那麼一個mongodb中的效能的好壞與mongodb的鎖的百分比有很大的關係。

在不少人的頭腦中，感覺mongodb是一個無事務的資料庫產品，實際上MONGODB 與傳統資料庫在這部分是一致的，具有mvcc，具有多版本控制，以及併發等功能，同時接受成百上千的.

實際上mongodb的鎖也是多粒度的，透過鎖來阻止同一個docuemnt在同一個時間被修改。而在讀取的過程中，是不會對資料進行鎖定的但是會跟蹤你的鎖定的頻率，作為一個指標來對你的資料庫進行跟蹤。而這個鎖定的頻率統計是在兩個層面，database 和 global . 在鎖這個層面上，對於資料庫層，只會對不同的使用者進行加鎖，而不會對在上層進行加鎖。

實際上從mongodb的角度來看，mognodb的本身也將一些在寫庫上的鎖進行了分離，如MONGODB本身的多節點，讀寫分離的方式，讓讀和寫在物理上就進行了分離。所以如果一個利用了MONGODB 的從節點的部分的應用可能在鎖方面產生的問題就比較少了。

如果遇到了鎖定的部分比較多的情況，一般是系統響應的問題，具體可能有效能較差的 mongodb 的查詢或者系統無法滿足當前訴求產生的問題。

1  globalLock

4.4

5.0

2 locks 

4.4

5.0

透過上面的兩個命令，可以檢視MONGODB 鎖的部分的資訊和內容，那麼我們怎麼解讀這些指標和資料來對應我們對於MONGODB 的觀測和問題的發現

1 globalLock.currentQueue.total

這個部分主要體現了兩個問題   1併發性，如果系統中併發較多，則這個部分的totoal 會有波動，同時如果有需求等待鎖的情況下，這個位置的數字會上升。

剩下的readers  ，writers 兩種是分別表達你的鎖的需求來自於 read 還是 write 

2 globalLock.totalTime

 這個部分的數值需要和你的實際的伺服器的執行的時間進行比較，如果你的這部分時間和實際的伺服器的執行時間之間差距較大。

4.4

5.0 

在4.4的版本中，我們可以透過acquireWaitCount 部分，來獲取等待獲取資源的等待時間，如果在短期這個數值上升的很高，那麼說明系統正在存在大量的系統資源的。

所以撰寫一個程式，在發現問題的情況下，快速的收集資料並將這些資料進行比對，可以快速的發現系統中出現的問題。如果後面我們寫出這樣的程式，也會和大家分享。

同時遇到這個問題，需要綜合的去分析和收集資料，global lock 高的原因還需要更詳細的分析。