《MongoDB高手課》學習記錄（第十七天）

寫在前面

最近有新項目上線，實在太忙了，學習的進度有點拖沓，但會堅持。

第十七天

今天要學的是《20 | 事務開發：讀操做事務之一》章節。主要講解的是怎麼哪裏讀取數據的問題。

readRreference 參數

值有5個，以下圖，默認爲primary，即從主結點讀數據。

應用場景場景舉例

以電商訂單，舉了一個實際的例子，乾貨。

• 用戶下訂單後立刻將用戶轉到訂單詳情頁——primary/primaryPreferred。由於此時從節點可能還沒複製到新訂單；
• 用戶查詢本身下過的訂單——secondary/secondaryPreferred。查詢歷史訂單對時效性一般沒有過高要求；
• 生成報表——secondary。報表對時效性要求不高，但資源需求大，能夠在從節點單獨處理，避免對線上用戶形成影響；
• 將用戶上傳的圖片分發到全世界，讓各地用戶可以就近讀取——nearest。每一個地區的應用選擇最近的節點讀取數據。

控制多個結點

這部分經過給結點打標籤，能夠控制從哪一組來讀。

readPreference 配置

經過 MongoDB 的鏈接串參數：

• mongodb://host1:27107,host2:27107,host3:27017/?replicaSet=rs&readPreference=secondary

經過 MongoDB 驅動程序 API：

• MongoCollection.withReadPreference(ReadPreference readPref)

Mongo Shell：

• db.collection.find({}).readPref( 「secondary」 )

readPreference 實驗: 從節點讀

• 主節點寫入 {x:1}, 觀察該條數據在各個節點都可見

• 在兩個從節點分別執行 db.fsyncLock() 來鎖定寫入（同步）

• 主節點寫入 {x:2}

• db.test.find({a: 123})
• db.test.find({a: 123}).readPref(「secondary」)

• 解除從節點鎖定 db.fsyncUnlock()

• db.test.find({a: 123}).readPref(「secondary」)

注意事項

• 指定 readPreference 時也應注意高可用問題。例如將 readPreference 指定 primary，則發生故障轉移不存在 primary 期間將沒有節點可讀。若是業務容許，則應選擇 primaryPreferred；

• 使用 Tag 時也會遇到一樣的問題，若是隻有一個節點擁有一個特定 Tag，則在這個節點失效時將無節點可讀。這在有時候是指望的結果，有時候不是。例如：

  • 若是報表使用的節點失效，即便不生成報表，一般也不但願將報表負載轉移到其餘節點上，此時只有一個節點有報表 Tag 是合理的選擇；
  • 若是線上節點失效，一般但願有替代節點，因此應該保持多個節點有一樣的 Tag；
• Tag 有時須要與優先級、選舉權綜合考慮。例如作報表的節點一般不會但願它成爲主節點，則優先級應爲 0。

最後

今天內容就這些，明天繼續。