Change Stream是MongoDB從3.6開始支持的新特性。這個新特性有哪些奇妙之處，會給我們帶來什麼便利？本次的文章將就這個主題進行初步討論。
Change Stream是什麼？
顧名思義，Change Stream即變更流，是MongoDB嚮應用發佈數據變更的一種方式。即當數據庫中有任何數據發生變化，應用端都可以得到通知。我們可以將其理解爲在應用中執行的觸發器。至於應用想得到什麼數據，以什麼形式得到數據，則可以通過聚合框架加以過濾和轉換。這點將在後文中討論。
Change Stream的原理
我們先來回顧一下MongoDB複製集大致是如何工作的：
- 應用通過驅動向數據庫發起寫入請求；
- 在同一個事務中，MongoDB完成oplog和集合的修改；
- oplog被其他從節點拉走；
- 從節點應用得到的oplog，同樣在一個事務中完成對oplog和集合的修改；
至此，複製集同步完成。可以發現，整個同步過程是依賴於oplog來進行的。也就是說oplog實際上已經包含了我們需要的所有變更數據。如果觀測oplog的變化，是否就能夠得到所有變更的數據了呢？對，change stream正是基於這個原理實現的。但事情並沒有這麼簡單！我們來看一下問題有可能出在什麼地方。
如何從斷點恢復
現實世界中，沒有哪個應用是可以不間斷運行的。不考慮bug導致的問題，正常的應用升級也會導致應用中斷運行。那麼在應用恢復的時候，從哪裏開始繼續獲取變更呢？oplog當然是可以幫我們做到這點的，但你必須對MongoDB足夠了解，才知道有oplogReplay這樣的參數，以及其他一些問題。
如何有效地處理訂閱
假設在一個應用中需要訂閱10個不同集合的變更情況，是否需要開10個tailable cursor去獲取oplog的變更呢？如果是100個集合呢？出於效率考慮顯然不應該這麼做。那麼整個過程就會變成一個生產者-消費者模式，由一個線程負責從oplog獲取變更，由訂閱的線程負責消費這些變更。雖然實現也不是那麼複雜，並且多半可以找到開源實現，但是涉及多線程就已經足夠讓初學者頭疼一陣的了。
公平地說，上面這些還不算嚴重的問題，下面這些問題可能會更讓人頭疼。
如何管理權限
想要tail oplog，必須對local.oplog.rs有讀權限。實際上這相當於對整個數據庫都有了讀權限，因爲所有的變更都會在這裏體現出來。DBA可能會阻止你這麼做，因爲這實在不是一個很安全的做法。
如何數據回滾
極端情況下，如果應用處理不當，MongoDB中可能發生數據回滾rollback的問題。如果僅僅通過跟蹤oplog，則會出現已經通知出去的變更被回滾的情況。
幸運的是上面這些問題現在都不是問題了，因爲change stream幫我們規避了這些複雜的細節。
使用方法
由於各種驅動都會有不同的語法和API，從shell中嘗試使用change stream可能是最簡便的方法。這並不妨礙你隨後在各種驅動中的使用，因爲shell中能實現的功能在驅動中一定有對應的語法。下面就以shell爲例看看change stream應該如何使用。
打開一個shell，訂閱你需要關注的集合
比如：
var cursor = db.bar.watch();爲了便於演示，我們在這個shell中不斷遍歷這個遊標以獲取新數據：
while(true) {
if (cursor.hasNext()) {
print(JSON.stringify(cursor.next()));
}
}打開另一個shell，向bar集合中插入一條數據：
db.bar.insert({y: 1})此時第一個shell中會立即輸出變更數據：
{"_id":{"_data":{"$binary":"glzquiIAAAACRmRfaWQAZFzquiK0lDNo+K0DpwBaEARUMrm0ruVACoftuxjt1RtCBA==","$type":"00"}},"operationType":"insert","fullDocument":{"_id":{"$oid":"5ceaba22b4943368f8ad03a7"},"y":1},"ns":{"db":"test","coll":"bar"},"documentKey":{"_id":{"$oid":"5ceaba22b4943368f8ad03a7"}}}這裏的一些字段的簡單介紹。更完整的介紹請查閱文檔change events：
-
_id: 用於恢復斷點時使用。即知道這個值，應用斷開後下次重啓裏就可以從這個斷點之後開始恢復獲得變更； -
operationType: 操作類型，常見的值包括：insertupdatedelete
-
ns: 正在操作的命名空間 -
fullDocument: 完整的文檔
從斷點恢復
var cursor = db.bar.watch([], {resumeAfter: <\_id>})此時使用hasNext()/next()即可獲取到隨後的變更。
注意事項
{readConcern: 'majority'}
爲了避免被回滾的更新被髮布出去，change stream選擇只在一個變更到達大多數節點（不可能被回滾）時，纔會將這些變更發佈到應用。使用的方式即{readConcern: "majority"}。因此以下這些情況下change stream都是不會嚮應用通知任何變更的：
- 禁用了
readConcern； - 從舊版本升級，但沒有更新
featureCompatibilityVersion； - PSA架構中S宕機；
斷點可恢復時間
因爲change stream是依賴於oplog工作的，自然也會面臨oplog面臨的所有問題。問題之一就是oplog被覆蓋。因此想要保證斷點可以恢復，必須保證應用在oplog window的時間內請求斷點。
刪除集合
如果在訂閱集合變更過程中集合被刪除，則會收到一條invalid信息通知，表示集合已不再可用：
{
"_id" : {
"_data" : BinData(0,"glzqxCcAAAACFFoQBFQyubSu5UAKh+27GO3VG0IE")
},
"operationType" : "invalidate"
}參考資料
- Tailable cursor: https://docs.mongodb.com/manual/core/tailable-cursors/
- 生產者-消費者模式: https://zh.wikipedia.org/wiki/%E7%94%9F%E4%BA%A7%E8%80%85%E6%B6%88%E8%B4%B9%E8%80%85%E9%97%AE%E9%A2%98
- 關於回滾: https://docs.mongodb.com/manual/core/replica-set-rollbacks/
- 變更事件: https://docs.mongodb.com/manual/reference/change-events/
- Change Stream介紹文檔：https://docs.mongodb.com/manual/changeStreams/
作者簡介
張耀星，MongoDB亞太區首席技術諮詢服務顧問。在MongoDB的開發、應用和諮詢服務上有多年實踐經驗。作爲MongoDB認證專家，曾經爲不同行業的各類大型客戶提供過培訓、性能調優、架構設計等各類MongoDB相關技術服務。