實現MongoDB讀寫分離的“讀偏好”介紹
在某些情況下，將讀請求傳送給副本集的備份節點是合理的，例如，單個伺服器無法處理應用的讀壓力，就可以把查詢請求路由到可複製集中的多臺伺服器上。現在絕大部分MongoDB驅動支援讀偏好設定（read preference；或翻譯為讀取首選項），用來告訴驅動從特定的節點讀取資料。
1 讀偏好選項
primary — 這是預設的設定，表明只從可複製集的主節點讀取資料，因此具有強一致性。如果可複製集有問題，並且沒有可選舉的從節點，就表示出現錯誤。
premaryPreferred — 設定了此引數的驅動會從主節點讀取資料，除非某些原因使主節點不可用或者沒有主節點，此時它會從從節點讀取資料。此種設定下，讀請求無法保證一致性。
secondary — 這個設定告訴驅動應該一直從從節點讀取資料。這種設定對於我們想確保讀請求不會影響主節點的寫入請求時非常有用。如果沒有可用的從節點，讀請求會丟擲異常。
secondarypreferred—讀請求會發出到從節點，除非沒有從節點可用，此時才會從主節點讀取。
nearest –驅動會嘗試從最近的可複製整合員節點讀取讀取資料，通過網路延遲判斷。可以是主節點也可以是從節點。因此讀請求只會傳送給驅動認為最快通訊的節點。
primary是唯一一個可以確保讀一致的模式。因為寫請求首先在主節點完成，從伺服器的更新會有些延遲，所以可能在從節點無法找到剛剛在主節點寫入的文件資料。
彙總以上知識，各偏好設定下讀取資料請求所發往的節點如下所示：
2 最大過期時間
MongoDB 3.4及更新的版本新增了maxStalenessSeconds設定。
副本集的從節點可能因為網路阻塞、磁碟吞吐低、長時間執行操作等，導致其落後於主節點。讀設定maxStalenessSeconds選項讓你對從節點讀取定義了最大落後或“過期”時間。當從節點估計過期時間超過了maxStalenessSeconds,客戶端會停止使用它進行讀操作。
最大過期和primary模式不匹配，只有選擇從節點成員讀取操作才能應用。
當選擇了使用maxStalenessSeconds進行讀操作的服務端，客戶端會通過比較從節點和主節點的最後一次寫時間來估計從節點的過期程度。客戶端會把連線指向估計落後小於等於maxStalenessSeconds的從節點。如果沒有主節點，客戶端使用從節點間的最近一次寫操作來比較。
預設是沒有最大過期時間並且客戶端也不會在指向讀操作時考慮從節點的落後。
必須定義maxStalenessSeconds的值大於等於90秒：定義一個更小的值會丟擲異常。客戶端通過定期檢查每個副本整合員最後一次寫時間來估計副本集過期程度。因為檢查不頻繁，所以估計是粗略的。 因此，客戶端 不能 強制maxStalenessSecconds小於90秒。
3 連線字串格式
副本集連線字串格式
mongodb://username:password@host1:port1,host2:port2[,...,hostN:portN]/database?options
options是連線配置中的可選項，replicaSet、readPreference、maxStalenessSeconds是其中的一個子項。
下面我們舉一個例子來說明字串是怎麼配置的，測試環境的副本集資訊如下：
副本集名稱 |
節點角色 |
節點IP |
埠 |
| Reptest |
主伺服器 |
172.171.X.XX1 |
27017 |
| 副本節點 |
172.171.X.XX2 |
27017 |
|
| 仲裁節點 |
172.171.X.XX3 |
27017 |
賬號資訊如下：
Username |
Password |
DBName |
| mongousertest |
testuserpwd |
mongotestdb |
如果希望程式讀請求路由到從節點secondary，100秒為節點資料失效時間，此時C#程式中connectionStr的字串可以設定如下：
stringconnectionStr = "mongodb://mongousertest:[email protected]:27017,172. 171.x. xx2: 27017 /mongotestdb?replicaSet=reptest&readPreference=secondary&maxStalenessSeconds=100";
本文版權歸作者所有，未經作者同意不得轉載,謝謝配合！！！