然後這壹節將談論MongoDB如何實現其高可用性，然後給出這些功能可以在多大程度上實現高可用性。
我相信，壹旦提到高可用性，您就會想到以下問題:
然後，帶著這些問題，讓我們繼續閱讀，閱讀後，每個人都應該了解這些問題。
MongoDB高可用性的基礎是復制集群，它本質上是存儲在多個副本中的數據的副本，以確保機器在掛起時不會丟失數據。
副本集至少由3個節點組成:
從上面的節點類型可以看出，三節點復制集群可能是PSS或PSA結構。
PSA結構的優點是節省成本，但缺點是在Primary掛斷後，壹些依賴於majority特性的write函數會出現問題，因此壹般不建議使用。
復制集群確保數據壹致性的核心設計是:
根據以上四點，我們可以得出以下結論:MongoDB具有高可用性:
MongoDB關閉並重新啟動後，您可以通過checkpoint快速恢復最後60秒之前的數據。
從MongoDB的最後壹個檢查點到停機時間的數據可以通過日誌回放來恢復。
因為日誌日誌在100毫秒刷新壹次，所以最多會丟失100毫秒的數據。
（這可以通過WriteConcern的參數進行控制，但性能會受到影響，適用於可靠性要求非常嚴格的場景。)
如果大部分寫入是為了寫入數據而開始的，那麽即使主服務器宕機，最多也將丟失100毫秒的數據（可避免，同上）。
分布式系統必須面對的問題之壹是數據的壹致性和高可用性，壹個非常著名的理論是CAP理論。
CAP理論的核心結論是:壹個分布式系統最多只能滿足壹致性、可用性和分區容忍度三項中的兩項。
網上有很多關於CAP理論的討論，這裏就不贅述了。
CAP理論提出了分布式系統必須面對的問題，但我們不可能因為這個問題而不使用分布式系統。
因此，基礎理論（基本可用、柔軟狀態、最終壹致的最終壹致性）被提出。
基礎理論是壹致性和可用性之間的平衡。現在大多數分布式系統都是基於BASE理論設計的，當然MongoDB也遵循這壹理論。
為了保證可用性和分區容錯性，MongoDB采用副本集。該模型必須解決的壹個問題是，當系統啟動且主節點異常時，如何快速選擇合適的主節點。
這裏有幾個潛在的問題:
MongoDB的選舉算法基於對Raft協議的改進，使分布式集群中的節點具有三種狀態:
Leader:是主節點，負責整個集群的寫操作。
候選節點:候選節點，主節點掛機後參與選舉的節點。它只會在選舉期間存在，而且是暫時的狀態。
Follower:它是從節點，被動地從主節點拉取更新的數據。
節點的狀態變化是:正常情況下，只有壹個leader和多個flowers。當領導者掛斷電話時，鮮花中的壹些節點將成為參加選舉的候選人。
當壹名候選人贏得選舉時，他將成為新的領導人，而其他候選人則回到“花之州”。
具體的狀態機如下:
Raft協議中有兩個核心RPC協議，分別用於選舉階段和正常階段:
請求投票:在選舉階段，候選人向其他節點發送請求，要求它們為自己投票。
附加條目:在正常階段，leader節點向follower節點發送請求，告訴對方有數據更新，同時作為心跳機制，向所有follower聲明其狀態。
如果follower在壹定時間內沒有收到請求，它將開始新壹輪的選舉投票。
Raft協議規定了選舉階段的投票規則:
壹個節點在壹個選舉周期（election period，簡稱$ Term）內只能為壹個候選節點投票，采用先到先得的原則。
只有當候選節點的oplog領先或與自身相同時，您才會投贊成票。
壹個完整的選舉過程包括以下內容:
以上是MongoDB的選舉機制，還有壹個問題還沒有回答，就是最後壹個。如何確保所選的初選是最合適的初選？
因為，從之前的協議來看，存在壹個邏輯bug:因為從follower到candidate的轉換是隨機和並行的，並且先到先得的投票機制將導致選擇壹個次優節點成為Primary。
針對Raft協議的這個問題，我搜索了壹些資料並得出結論:
Raft協議不能保證選出的主節點是最優的。
MongoDB通過在選舉成功和新的初選登上王位之前添加壹個catchup操作來解決這個問題。
也就是說，在節點贏得投票後，它將首先檢查其他節點是否更新了oplog，如果沒有，它將直接即位，如果有，它將在即位前同步數據。
MongoDB的主從同步機制是保證數據壹致性和可靠性的重要機制。其同步的基礎是oplog，類似於MySQL的binlog，但也有壹些區別。雖然名為日誌，但操作日誌不是文件，而是集合。
同時，由於oplog的並行寫入，存在尾部無序和漏洞，具體而言，oplog中的數據順序可能與實際數據順序不壹致，存在時間不連續問題。
為了解決這個問題，MongoDB采用了混合邏輯時鐘（HLC），它不僅解決了無序和空虛的問題，還解決了分布式系統中的事務壹致性問題。
事實上，主從同步的本質是主節點接收客戶端的請求，將更新操作寫入oplog，然後從同步源拉取oplog並在本地播放，以實現數據同步。
同步源是指節點從中提取操作日誌的源節點。該節點可能不是主節點，但可以是鏈復制模式下的任何節點。
節點同步源的選擇是壹個非常復雜的過程，大致如下:
選擇同步源時有壹些特殊情況:
用戶可以為節點指定同步源。
如果鏈復制關閉，所有輔助節點的同步源都是主節點。
如果不正確地從同步源中提取，它將在短時間內被列入黑名單。
整個拉取和回放的邏輯非常復雜，所以根據我自己的理解進行簡化解釋。如果您想了解更多信息，可以參考MongoDB復制技術的內幕。
該節點有壹個特殊的線程來拉取操作日誌，並通過耗盡的遊標從同步源拉取操作日誌。它被拉下來後，不會被回放，而是被扔到壹個地方。
在的阻塞隊列中。
然後有幾個特定的執行線程，它們從阻塞隊列中取出操作日誌並執行它。
在獲取過程中，同壹集合的操作日誌將由同壹線程獲取並執行，該線程將盡可能合並連續的插入命令。
整個回放的執行過程大致如下:先鎖定，然後寫我們的oplog，再刷oplog（WAL機制），最後更新妳最新的opTime。
MongoDB全方位知識圖譜
/s/bhxpnlotuoqyji 61 EOR CFA