MongoDB原生高可用及分布式能力解析

1、MongoDB 原生高可用及分布式能力解析技術(shù)創(chuàng)新，變革未來大綱MongoDB 原生高可用能力：多副本（Replication）故障恢復(fù)（Failover）MongoDB 原生分布式能力副本集 writeConcern/readConcern 實(shí)現(xiàn)原理分片集群 - 核心架構(gòu)，關(guān)鍵原理解析1. MongoDB 原生高可用能力MongoDB 副本集基本架構(gòu)及優(yōu)勢副本集帶來：更高的可用性更強(qiáng)的擴(kuò)展性更好的維護(hù)性高可用要解決的關(guān)鍵問題MongoDB 復(fù)制機(jī)制 oploglocal 庫下的一個(gè)集合：用來保存寫操作所產(chǎn)生的增量日志（類似于MySQL 中的 Binlog）Capped Collection：

2、即超出配置的最大值后，會(huì)自動(dòng)刪除最老的歷史數(shù) 據(jù)，針對 Oplog 的刪除有特殊優(yōu)化（oplog stones），以提升刪除效率主節(jié)點(diǎn)產(chǎn)生新的 Oplog Entry，從節(jié)點(diǎn)通過復(fù)制 Oplog 并應(yīng)用來保持和 主節(jié)點(diǎn)的狀態(tài)一致Oplog 中包含的有：o 插入或更新的內(nèi)容；op 操作類型；ns 操作執(zhí)行的 DB 和集合；ts 操作發(fā)生的時(shí)間等MongoDB 復(fù)制機(jī)制 全量同步發(fā)生時(shí)機(jī)：新節(jié)點(diǎn)剛加入副本集時(shí)老的節(jié)點(diǎn)因?yàn)橥綔蠖M(jìn)入 Recovering 狀態(tài)時(shí)全量同步包含兩個(gè)階段：數(shù)據(jù)克隆階段：記錄開始時(shí)間 T1，從源端拉取所有的集 合數(shù)據(jù)，不保證數(shù)據(jù)和源的一致性，記錄結(jié)束時(shí)間 T2增量應(yīng)用階

3、段：應(yīng)用從 T1 - T2 期間的 Oplog，達(dá)到一 致性狀態(tài)，全量同步結(jié)束MongoDB 復(fù)制機(jī)制 全量斷點(diǎn)續(xù)傳（4.4）4.4 之前：全量同步期間，如果發(fā)生網(wǎng)絡(luò)異常，導(dǎo)致同步中斷，需要重頭開始網(wǎng)絡(luò)環(huán)境比較差時(shí)，大數(shù)據(jù)量很難完成全量同步；可用節(jié)點(diǎn)數(shù)變少， 實(shí)例可用性存在隱患4.4 : 基于 resume token機(jī)制，記錄全量拉取的位點(diǎn)， 網(wǎng)絡(luò)異常導(dǎo)致同步中斷后，重連時(shí)帶上 resume tokenreplication.initialSyncTransientErrorRetryPeriodSeconds參數(shù)決定了，同步中斷后，重試的超時(shí)時(shí)間，默認(rèn) 24hMongoDB 復(fù)制機(jī)制 增量

4、同步發(fā)生時(shí)機(jī)：全量同步結(jié)束后，持續(xù)同步，保持和主節(jié)點(diǎn)數(shù)據(jù)一致Oplog Fetcher 線程負(fù)責(zé)拉取 oplog：find 命令創(chuàng)建 tailable cursor，getMore 命令 批量從同步源拉取 oplog，單個(gè) batch 最大 16MB拉取的 oplog batch 放到內(nèi)存中的 blocking queue 中replBatcher 線程負(fù)責(zé)從 blocking queue 中取出 batch 生成新的可 apply 的 batch， 放到 deque 中，這里主要是因?yàn)樾枰刂撇l(fā)，有些操作需要放到一個(gè)單獨(dú)的 batchoplogApplier 線程負(fù)責(zé)從 deque 中取出

5、 batch，寫 oplog，然后把 batch 拆分，分 發(fā)到多個(gè) worker 線程進(jìn)行并發(fā) applyfrom 張友東為了保持一致性，中間需要保存多個(gè)不同的 oplog 應(yīng)用位點(diǎn)信息（appliedThrough，minValid，oplogTruncateAfterPoint），詳細(xì)流程可參考：Replication InternalsMongoDB 故障恢復(fù) 心跳機(jī)制副本集成員間兩兩發(fā)送repSetHeartbeat命令保持心跳，默認(rèn)頻率 2s 一次心跳數(shù)量 = N2 ，N = 成員數(shù)量，這個(gè)是副本集規(guī)模（上限 50 個(gè)成員）的主要原因心跳包包含的關(guān)鍵信息：副本集配置的版本和 Ter

6、m、發(fā)送者在副本集配置 members 數(shù)組中的 idx 和 host:port、副本集名心跳回包包含的關(guān)鍵信息：接收者的副本集配置版本和 Term、 lastAppliedOpTime/lastDurableOpTime、是否是 Primary 等MongoDB 通過心跳機(jī)制來保證：新的拓?fù)洹⒊蓡T狀態(tài)和配置信息可以廣播到集群中的每個(gè)節(jié)點(diǎn)，集群中的成員根據(jù)心跳來決定是否中止選舉，發(fā)起選舉，reconfig，更新成員狀態(tài)心跳：副本集成員間的溝通渠道MongoDB 故障恢復(fù) 選舉機(jī)制觸發(fā)時(shí)機(jī)：主節(jié)點(diǎn)不可用新增節(jié)點(diǎn)（更高的 Priority，priority takeover）主動(dòng)運(yùn)維，rs.ste

7、pDown() or rs.reconfig()如果超出 electionTimeoutMillis （默認(rèn) 10 秒）沒有探測到主節(jié)點(diǎn)，Secondary 節(jié)點(diǎn)會(huì)發(fā)起選 舉，發(fā)起前，檢查自身?xiàng)l件：priority 是否大于 0當(dāng)前狀態(tài)是否夠新在真正選舉前，會(huì)先進(jìn)行一輪空投（dry-run），避免當(dāng)前 primary 無意義的降級（stepDown）通過 replSetStepDown 主動(dòng)交接（electionHandoff）的情況下，無需進(jìn)行空投dry-run 成功后，會(huì)增加自身的 term，發(fā)起真正的選舉，如果收到多數(shù)派的選票，那么選舉成功， 把新的拓?fù)湫畔⑼ㄟ^心跳廣播到整個(gè)副本集Mon

8、goDB 故障恢復(fù) 回滾機(jī)制對比 Raft，MongoDB 在日志復(fù)制到多數(shù)派節(jié)點(diǎn)前就直接 apply RSM，導(dǎo)致重新選主后，部分節(jié)點(diǎn)（比如舊主）需要對狀態(tài)機(jī)（DB）進(jìn)行回滾MongoDB 的回滾機(jī)制伴隨存儲(chǔ)引擎能力的提升而進(jìn)化：邏輯回滾 - 物理回滾V.S.MongoDB 故障恢復(fù) 回滾機(jī)制邏輯回滾：Refetch Based Rollback物理回滾（4.0+）：Recover To Timestamp RollbackMongoDB 故障恢復(fù) Catchup 機(jī)制即使具備了物理回滾能力，回滾仍然是一項(xiàng)代價(jià)比較大的動(dòng)作，catchup 機(jī)制可以進(jìn)一步降低需要回滾的概率Catchup 機(jī)制

9、：當(dāng)選的 Primary 節(jié)點(diǎn)在打開寫之前，會(huì)通過心跳獲 取其他成員的 lastAppliedOptime，如果比自己新，從該節(jié)點(diǎn)進(jìn)行 增量同步Catchup 的超時(shí)時(shí)間由 settings.catchUpTimeoutMillis 決定，默 認(rèn)不超時(shí)但為了避免無限 catchup，被 catchup 的節(jié)點(diǎn)在settings.catchUpTakeoverDelayMillis 時(shí)間后會(huì)主動(dòng)發(fā)起投票2. MongoDB 原生分布式能力PACELC 理論P(yáng)ACELC 理論是對 CAP 的延伸，說明即使在網(wǎng)絡(luò)分區(qū)暫不存在的情況下，分布式環(huán)境中，實(shí)際應(yīng)用仍然需要在 Latency 和 Consis

10、tency 之間做選擇Consistency 除了包括 Recency ，也包括 DurabilityMongoDB 通過 writeConcern 和 readConcern 給應(yīng)用提供這種選擇 Tunable Consistency ModelwriteConcern 持久性和延遲間的選擇defaultw : 1w : majorityw ： majority 確保讀到的數(shù)據(jù)不會(huì)被回滾，w 1 時(shí)強(qiáng)調(diào)數(shù)據(jù)在整個(gè)副本集層面的持久性j : true 時(shí)還要求寫操作對應(yīng)的日志必須刷盤，確保在 majority 同時(shí)故障的情況，成功的寫操作不會(huì)丟失實(shí)現(xiàn)原理：寫操作在返回前阻塞，記錄本條寫操作對應(yīng)的

11、 lastOpTime等待備庫匯報(bào)的 appliedOpTime /durableOpTime 滿足 w 要求，使用 applied 還 是 durable 取決于 j 是否為 true備庫匯報(bào)機(jī)制：replSetUpdatePosition ，在 一個(gè) oplog batch apply 完時(shí)觸發(fā)，具備轉(zhuǎn)發(fā)機(jī)制心跳（replSetHeartbeat）readConcern 一致性和延遲間的選擇不同的節(jié)點(diǎn)復(fù)制進(jìn)度可能不同，導(dǎo)致 majority 視圖不一樣snapshot：只適用于多文檔事務(wù)，提供 majority 語義的同時(shí)，保證真正的 point in time snapshot 的語義l

12、inearizable：只能在主節(jié)點(diǎn)上執(zhí)行讀操作Tradeoffs between different readConcern levelsreadConcern 實(shí)現(xiàn)原理majority：依賴 WiredTiger 引擎快照的實(shí)現(xiàn)方式（4.0）：WT 維護(hù) mcp（majority commit point） 對應(yīng)的快照，majority read 直接讀取該快照副本集各節(jié)點(diǎn)通過oplog fetch 和心跳持續(xù)推進(jìn) mcpServer 層通過 WT 3.0 提供的 Application Timestamp API 更新 mcp 對應(yīng)的快 照，降低內(nèi)存壓力對于 long query，需要應(yīng)

13、用 query yielding來避免 WT cache 壓力過大Speculative Read（未決讀） 實(shí)現(xiàn)方式，不依賴快照：類似于 majority writeConcern， 讀返回前顯式等待 mcp 推進(jìn)snapshot：在 MongoDB 中的實(shí)現(xiàn)總是 speculative 的，即讀操作返回前進(jìn)行顯式等待，目的是降低事務(wù)沖突的概率不會(huì)應(yīng)用 query yielding，所以可以提供真正的 snapshot isolation 語義Query Yielding算法mcp 位點(diǎn)推進(jìn)MongoDB 分片集群 核心架構(gòu)chunksmongos：分片集群的訪問入口，對請求進(jìn)行路由、分發(fā)、

14、合并。無狀態(tài)，可方便的進(jìn)行橫向擴(kuò)展config server：本身為副本集來保證高可用，存儲(chǔ)元信息和 集群配置，負(fù)責(zé)數(shù)據(jù)在 shard 間的均衡shard：每個(gè) shard 為一個(gè)副本集，承載用戶數(shù)據(jù)，支持讀擴(kuò)展，shard 層面可橫向擴(kuò)展，通過 chunk 遷移達(dá)到數(shù)據(jù)在新 增 shard 上的均衡MongoDB 分片集群 范圍分片 v.s. 哈希分片MongoDB 分片集群 Shard Key約束MongoDB 分片集群 Refinable Shard Keys（4.4）動(dòng)畫來自于 MongoDB 官方：https:/www.mong/blog/post/scale-without-fea

15、r-or-friction4.0：Shard Key 及其 Value 均無法修改4.2：可修改文檔的 Shard Key 對應(yīng)的 Value，但基于分布 式事務(wù)實(shí)現(xiàn)，開銷大，且無法完全解決負(fù)載不均的問題4.4：在現(xiàn)有的 Shard Key 上增加一個(gè)或多個(gè) Suffix Field性能開銷很低：只修改 chunk 元數(shù)據(jù)原理：單純的添加 Suffix 并不會(huì)立刻改變現(xiàn)有 Chunk 在 Shard 上的分布，新的索引也完全能覆蓋老的索引 需求需要提前創(chuàng)建新的 Shard Key 對應(yīng)的索引隱含支持了Missing Shard Key的功能MongoDB 分片集群 特定分片操作 v.s. 廣播操作MongoDB 分片集群 Chunk 分裂MongoDB 分片集群 Chunk 遷移MongoDB 分片集群 Jumbo Chunk 的形成及治理總結(jié)和很多傳統(tǒng)的開源數(shù)據(jù)庫，比如 MySQL，PG 不同，MongoDB 從一開始