實現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:testuserpwd@172.171.x.xx1:27017,172.171.x.xx2:27017/mongotestdb?replicaSet=reptest&readPreference=secondary&maxStalenessSeconds=100";

 本文著作權歸作者所有，未經作者同意不得,謝謝配合！！！