Nacos支持兩種模式來滿足不同場景下的需求:AP模式(強調可用性)和CP模式(強調一致性)。
這兩種模式的選擇主要基于CAP理論,該理論指出在一個分布式系統中,無法同時保證一致性(Consistency)、可用性(Availability)和分區容忍性(Partition Tolerance),只能在三者之間做出權衡。
1、AP模式(Available and Partition Tolerant)
核心原理:
AP模式強調高可用性(Availability)和分區容錯性(Partition Tolerance),采用Distro協議實現最終一致性(Eventual Consistency),適用于臨時實例(如微服務實例)。
特點:
- 可用性優先:在AP模式下,Nacos側重于保證系統的高可用性和響應速度。這意味著即使在網絡分區的情況下,系統仍然能夠提供服務。
- 最終一致性:雖然犧牲了一部分即時的一致性,但通過異步復制或事件驅動的方式,確保所有節點的數據最終會達到一致狀態。
- 數據同步:Nacos在AP模式下通常采用異步復制策略,即一個節點上的更新不會立即同步到其他所有節點,而是經過一段時間后才完成全網同步。
Nacos的實現細節:
- 注冊中心功能:當作為服務注冊中心使用時,AP模式非常適合,因為它能確保即使某個區域的服務實例不可達,其余區域的服務仍可正常運行,并且可以發現并訪問最近的服務實例。
- 健康檢查機制:為了維護服務列表的準確性,Nacos使用了客戶端的心跳檢測機制來判斷服務實例是否存活。如果某個實例長時間未發送心跳,則會被標記為不健康并從服務列表中移除。
實現機制:
(1)、數據分片與責任機制
- 每個Nacos節點負責一部分數據(基于服務名或實例IP的哈希計算)。
- 寫請求會被路由到負責該數據的節點(稱為責任節點),處理完成后異步同步給其他節點。
- 示例:假設服務名為order- service,其哈希值決定由節點A負責。所有對該服務的寫操作(如注冊實例)都會由節點A處理。
(2)、異步數據同步
- 責任節點處理寫請求后,通過增量同步方式廣播給其他節點。
- 若同步失敗,會進行重試,但不阻塞主流程,保證高可用性。
- 最終一致性:數據同步可能存在短暫延遲,但最終所有節點數據會達成一致。
(3)、臨時實例管理
- 臨時實例數據僅存儲在內存,不會持久化到磁盤。
- 客戶端通過心跳機制(HTTP/gRPC)保活,超時(默認15s不健康,30s剔除)后自動清理。
- 示例:微服務實例每隔5秒向Nacos發送心跳,若15秒未收到心跳,則標記為不健康;若30秒未收到,則從注冊表中剔除。
(4)、健康檢查
- 客戶端主動上報心跳(HTTP或gRPC長連接)。
- 服務端定時檢查心跳,超時則標記為不健康或剔除。
適用場景:
- 服務發現:微服務注冊與發現(如Spring Cloud應用),允許短暫數據不一致。
- 高可用性要求高:電商大促時,服務注冊的輕微延遲不影響整體功能。
- 容忍臨時錯誤:例如,服務實例短暫不可用時,AP模式仍能提供服務列表。
優勢:
- 高可用性:即使部分節點故障,仍能響應請求。
- 適合動態環境:適用于實例頻繁變動的場景(如彈性伸縮)。
局限性:
- 最終一致性:數據同步存在延遲,可能讀取到舊數據。
- 無法保證強一致性:不適合對數據一致性要求極高的場景(如金融交易配置)。
2、CP模式(Consistent and Partition Tolerant)
核心原理:
CP模式強調一致性(Consistency)和分區容錯性(Partition Tolerance),采用Raft協議保證強一致性(Strong Consistency),適用于持久實例(如數據庫、Redis等)。
特點:
- 一致性優先:在CP模式下,Nacos更加注重數據的一致性。這意味著在網絡分區發生時,系統可能會暫時拒絕某些請求以保持數據的一致性。
- 強一致性模型:采用類似于Raft算法的共識協議來實現強一致性,確保所有操作都是原子性的,并且每個操作的結果都會被正確地傳播到集群中的每一個節點。
- 讀寫性能影響:由于需要等待多個副本確認,因此在寫入操作上會有一定的延遲,這可能會影響整體的讀寫性能。
Nacos實現細節:
- 配置管理功能:對于配置管理而言,CP模式是非常重要的,因為任何配置的變化都需要確保在整個集群范圍內立即生效,避免因配置不一致導致的問題。
- 選舉機制:在CP模式下,Nacos集群中的節點會進行領導者選舉,只有當前領導者才能處理寫請求,而其他跟隨者則負責復制數據并響應讀請求。
實現機制:
(1)、Leader選舉
- 集群通過Raft協議選舉Leader,只有Leader能處理寫請求。
- Follower節點轉發寫請求到Leader。
- 示例:Nacos集群啟動時,節點間通過投票選舉Leader,確保集群中只有一個Leader。
(2)、日志復制
- Leader將寫操作記錄到日志,并同步給Follower。
- 需半數以上節點ACK才算成功,確保數據強一致性。
- 示例:當客戶端更新配置時,Leader將更新操作寫入日志,同步給Follower,收到超過半數節點確認后,才返回成功。
(3)、持久化存儲
- 數據會持久化到磁盤,即使節點重啟也能恢復。
- 適用于永久實例(如MySQL 注冊信息)。
(4)、健康檢查
- 服務端主動探測(TCP/HTTP/MySQL檢查)。
- 不依賴客戶端心跳,適合無法主動上報的服務。
適用場景:
- 配置管理:如數據庫連接串、關鍵參數配置,要求數據絕對一致。
- 元數據管理:如服務注冊中心的元數據(服務列表、權重等)。
- 強一致性需求:金融系統中的交易配置,不允許出現配置不一致導致的資金錯誤。
優勢:
- 強一致性:所有節點在同一時間看到相同的數據。
- 數據持久化:防止節點重啟導致數據丟失。
- 適合靜態資源:適用于數據變更較少的場景(如數據庫實例)。
局限性:
- 可用性妥協:當發生網絡分區或Leader選舉時,可能暫時不可用。
- 高延遲:日志復制和半數確認機制可能增加請求延遲。
3、AP模式與CP模式的對比
4、Nacos的行為和建議
1、配置同步和通知(推薦使用CP模式)
(1)、配置同步的核心需求
- 強一致性加粗樣式:配置中心的核心目標是確保所有客戶端獲取的配置數據完全一致。例如,數據庫連接、限流規則等配置如果存在不一致,可能導致業務邏輯錯誤或系統異常。
- 持久化:配置通常需要持久化存儲(如數據庫或磁盤),以防止節點重啟后數據丟失。
(2)、CP模式下的配置同步
- Raft協議:在CP模式下,Nacos通過Raft協議保證配置的強一致性。所有配置的寫操作必須經過Raft日志復制,確保半數以上節點確認后才提交。
- 數據同步機制:
- 長輪詢(Long Polling):客戶端定期向服務端發起請求,攜帶本地配置的 MD5 值。服務端檢測到配置變更后,立即返回新配置。
- 事件監聽(Event Listener):客戶端注冊監聽器,當配置變更時,服務端主動推送更新。
- 容錯與緩存:
- 客戶端本地緩存配置,即使服務端不可用也能降級使用舊配置。
- 服務端通過Raft協議確保配置數據的持久化和一致性。
(3)、AP模式下的配置同步
- 最終一致性:AP模式下,配置同步依賴Distro協議的異步復制機制,可能存在短暫延遲。
- 適用場景:對配置一致性要求不高的場景(如非核心功能的動態參數),但通常不建議在AP模式下使用配置中心。
結論:
- 配置同步推薦使用CP模式:保證強一致性,避免因配置不一致導致業務異常。
- AP模式下的配置同步:僅適用于容忍短暫不一致的非關鍵場景。
2、節點狀態同步和通知(默認使用AP模式)
(1)、節點狀態的核心需求
- 高可用性:服務注冊與發現需要保證在節點故障或網絡分區時仍能正常提供服務。
- 動態性:服務實例頻繁變動(如彈性擴縮容、實例重啟),需要快速響應。
(2)、AP模式下的節點狀態同步
- Distro協議:每個節點負責一部分服務實例的注冊和同步,寫操作本地提交后異步同步到其他節點。
- 心跳機制:客戶端通過心跳(HTTP/gRPC)保活,服務端檢測心跳超時后標記實例為不健康或剔除。
- 最終一致性:節點間數據同步可能存在延遲,但最終達成一致。
(3)、CP模式下的節點狀態同步
- Raft協議:CP模式下注冊的持久化實例(ephemeral=false)需要通過Raft協議保證強一致性,但會犧牲部分可用性。
- 適用場景:需要強一致性的關鍵服務注冊(如數據庫、Redis等靜態資源)。
結論:
- 節點狀態同步默認使用AP模式:適用于臨時實例(ephemeral=true),保證高可用性和動態性。
- CP模式下的節點狀態同步:僅適用于持久化實例(ephemeral=false),需顯式啟用。
5、如何選擇AP模式或CP模式?
Nacos允許用戶根據自己的需求選擇使用AP(可用性優先)或CP(一致性優先)模式,這主要體現在服務發現和配置管理的不同場景中。這種靈活性使得Nacos能夠適應不同的業務需求。
(1)、選擇依據
1、數據一致性要求
- CP模式:需要數據絕對一致(如金融、配置管理)。
- AP模式:允許短暫不一致(如微服務注冊發現)。
2、實例類型
- CP模式:持久實例(persistent),如數據庫實例。
- AP模式:臨時實例(ephemeral),如微服務實例。
3、可用性需求
- CP模式:可容忍短暫不可用(如配置更新)。
- AP模式:需要高可用性(如電商大促)。
(2)、切換方式
AP模式(默認):
代碼示例:
// 默認使用AP模式
NacosNamingService naming = NamingFactory.createNamingService(serverAddr);
Naming.registerInstance("serviceName", "192.168.1.1", 8080);
CP模式:
代碼示例:
// 注冊服務時指定使用CP模式
NacosNamingService naming = NamingFactory.createNamingService(serverAddr);
naming.registerInstance("serviceName", "192.168.1.1", 8080, "DEFAULT", true); // 最后參數為true表示CP模式
切換模式:
方式1:修改配置文件
- 配置文件路徑:conf/application.properties
- 修改參數:
# 切換為AP模式(Distro協議)
nacos.core.protocol=distro# 切換為 CP 模式(Raft 協議)
nacos.core.protocol=raft
注意:
修改后需重啟 Nacos 服務生效。
方式2:通過API動態切換
- API調用:
bash示例:
# 切換為CP模式
curl - X PUT "http://<nacos- server>:8848/nacos/v1/ns/operator/switches?entry=serverMode&value=CP"# 切換為AP模式
curl - X PUT "http://<nacos- server>:8848/nacos/v1/ns/operator/switches?entry=serverMode&value=AP"
- 無需重啟:API切換是動態的,無需重啟服務,但需注意切換時的集群狀態。
(3)、實際建議
配置中心需要使用強一致性CP模式。
服務注冊,通常配置AP模式。
彈性部署應用建議AP模式。
6、總結
- AP模式:適合高可用性、容忍短暫不一致的場景,如微服務注冊與發現。
- CP模式:適合強一致性、數據持久化的場景,如配置管理和金融系統。
- 核心區別:AP模式通過Distro協議實現最終一致性,CP模式通過Raft協議實現強一致性。
通過合理選擇模式,Nacos能夠滿足不同業務場景的需求,在一致性和可用性之間取得平衡。
向陽前行,Dare To Be!!!