心跳機(jī)制在1.x和2.x版本的實(shí)現(xiàn)也是不一樣的

1.x心跳實(shí)現(xiàn)

在1.x中，心跳機(jī)制實(shí)現(xiàn)是通過客戶端和服務(wù)端各存在的一個(gè)定時(shí)任務(wù)來完成的

在服務(wù)注冊時(shí)，發(fā)現(xiàn)是臨時(shí)實(shí)例，客戶端會(huì)開啟一個(gè)5s執(zhí)行一次的定時(shí)任務(wù)

這個(gè)定時(shí)任務(wù)會(huì)構(gòu)建一個(gè)Http請求，攜帶這個(gè)服務(wù)實(shí)例的信息，然后發(fā)送到服務(wù)端

在Nacos服務(wù)端也會(huì)開啟一個(gè)定時(shí)任務(wù)，默認(rèn)也是5s執(zhí)行一次，去檢查這些服務(wù)實(shí)例最后一次心跳的時(shí)間，也就是客戶端最后一次發(fā)送Http請求的時(shí)間

• 當(dāng)最后一次心跳時(shí)間超過15s，但沒有超過30s，會(huì)把這服務(wù)實(shí)例標(biāo)記成不健康
• 當(dāng)最后一次心跳超過30s，直接把服務(wù)從服務(wù)注冊表中剔除

這就是1.x版本的心跳機(jī)制，本質(zhì)就是兩個(gè)定時(shí)任務(wù)

其實(shí)1.x的這個(gè)心跳還有一個(gè)作用，就是跟上一節(jié)說的gRPC時(shí)Redo操作的作用是一樣的

服務(wù)在處理心跳的時(shí)候，發(fā)現(xiàn)心跳攜帶這個(gè)服務(wù)實(shí)例的信息在注冊表中沒有，此時(shí)就會(huì)添加到服務(wù)注冊表

所以心跳也有Redo的類似效果

2.x心跳實(shí)現(xiàn)

在2.x版本之后，由于通信協(xié)議改成了gRPC，客戶端與服務(wù)端保持長連接，所以2.x版本之后它是利用這個(gè)gRPC長連接本身的心跳來?；?/p>

一旦這個(gè)連接斷開，服務(wù)端就會(huì)認(rèn)為這個(gè)連接注冊的服務(wù)實(shí)例不可用，之后就會(huì)將這個(gè)服務(wù)實(shí)例從服務(wù)注冊表中提出剔除

除了連接本身的心跳之外，Nacos還有服務(wù)端的一個(gè)主動(dòng)檢測機(jī)制

Nacos服務(wù)端也會(huì)啟動(dòng)一個(gè)定時(shí)任務(wù)，默認(rèn)每隔3s執(zhí)行一次

這個(gè)任務(wù)會(huì)去檢查超過20s沒有發(fā)送請求數(shù)據(jù)的連接

一旦發(fā)現(xiàn)有連接已經(jīng)超過20s沒發(fā)送請求，那么就會(huì)向這個(gè)連接對應(yīng)的客戶端發(fā)送一個(gè)請求

如果請求不通或者響應(yīng)失敗，此時(shí)服務(wù)端也會(huì)認(rèn)為與客戶端的這個(gè)連接異常，從而將這個(gè)客戶端注冊的服務(wù)實(shí)例從服務(wù)注冊表中剔除

所以對于2.x版本，主要是兩種機(jī)制來進(jìn)行?；睿?/p>

• 連接本身的心跳機(jī)制，斷開就直接剔除服務(wù)實(shí)例
• Nacos主動(dòng)檢查機(jī)制，服務(wù)端會(huì)對20s沒有發(fā)送數(shù)據(jù)的連接進(jìn)行檢查，出現(xiàn)異常時(shí)也會(huì)主動(dòng)斷開連接，剔除服務(wù)實(shí)例

小總結(jié)

心跳機(jī)制僅僅針對臨時(shí)實(shí)例而言

1.x心跳機(jī)制是通過客戶端和服務(wù)端兩個(gè)定時(shí)任務(wù)來完成的，客戶端定時(shí)上報(bào)心跳信息，服務(wù)端定時(shí)檢查心跳時(shí)間，超過15s標(biāo)記不健康，超過30s直接剔除

1.x心跳機(jī)制還有類似2.x的Redo作用，服務(wù)端發(fā)現(xiàn)心跳的服務(wù)信息不存在會(huì)，會(huì)將服務(wù)信息添加到注冊表，相當(dāng)于重新注冊了

2.x是基于gRPC長連接本身的心跳機(jī)制和服務(wù)端的定時(shí)檢查機(jī)制來的，出現(xiàn)異常直接剔除

健康檢查

前面說了，心跳機(jī)制僅僅是臨時(shí)實(shí)例用來保護(hù)的機(jī)制

而對于永久實(shí)例來說，一般來說無法主動(dòng)上報(bào)心跳

就比如說MySQL實(shí)例，肯定是不會(huì)主動(dòng)上報(bào)心跳到Nacos的，所以這就導(dǎo)致無法通過心跳機(jī)制來?；?/p>

所以針對永久實(shí)例的情況，Nacos通過一種叫健康檢查的機(jī)制去判斷服務(wù)實(shí)例是否活著

健康檢查跟心跳機(jī)制剛好相反，心跳機(jī)制是服務(wù)實(shí)例向服務(wù)端發(fā)送請求

而所謂的健康檢查就是服務(wù)端主動(dòng)向服務(wù)實(shí)例發(fā)送請求，去探測服務(wù)實(shí)例是否活著

健康檢查機(jī)制在1.x和2.x的實(shí)現(xiàn)機(jī)制是一樣的

Nacos服務(wù)端在會(huì)去創(chuàng)建一個(gè)健康檢查任務(wù)，這個(gè)任務(wù)每次執(zhí)行時(shí)間間隔會(huì)在2000~7000毫秒之間

當(dāng)任務(wù)觸發(fā)的時(shí)候，會(huì)根據(jù)設(shè)置的健康檢查的方式執(zhí)行不同的邏輯，目前主要有以下三種方式：

• TCP
• HTTP
• MySQL

TCP的方式就是根據(jù)服務(wù)實(shí)例的ip和端口去判斷是否能連接成功，如果連接成功，就認(rèn)為健康，反之就任務(wù)不健康

HTTP的方式就是向服務(wù)實(shí)例的ip和端口發(fā)送一個(gè)Http請求，請求路徑是需要設(shè)置的，如果能正常請求，說明實(shí)例健康，反之就不健康

MySQL的方式是一種特殊的檢查方式，他可以執(zhí)行下面這條Sql來判斷數(shù)據(jù)庫是不是主庫

默認(rèn)情況下，都是通過TCP的方式來探測服務(wù)實(shí)例是否還活著

服務(wù)發(fā)現(xiàn)

所謂的服務(wù)發(fā)現(xiàn)就是指當(dāng)有服務(wù)實(shí)例注冊成功之后，其它服務(wù)可以發(fā)現(xiàn)這些服務(wù)實(shí)例

Nacos提供了兩種發(fā)現(xiàn)方式：

• 主動(dòng)查詢
• 服務(wù)訂閱

主動(dòng)查詢就是指客戶端主動(dòng)向服務(wù)端查詢需要關(guān)注的服務(wù)實(shí)例，也就是拉（pull）的模式

服務(wù)訂閱就是指客戶端向服務(wù)端發(fā)送一個(gè)訂閱服務(wù)的請求，當(dāng)被訂閱的服務(wù)有信息變動(dòng)就會(huì)主動(dòng)將服務(wù)實(shí)例的信息推送給訂閱的客戶端，本質(zhì)就是推（push）模式

在我們平時(shí)使用時(shí)，一般來說都是選擇使用訂閱的方式，這樣一旦有服務(wù)實(shí)例數(shù)據(jù)的變動(dòng)，客戶端能夠第一時(shí)間感知

并且Nacos在整合SpringCloud的時(shí)候，默認(rèn)就是使用訂閱的方式

對于這兩種服務(wù)發(fā)現(xiàn)方式，1.x和2.x版本實(shí)現(xiàn)也是不一樣

服務(wù)查詢其實(shí)兩者實(shí)現(xiàn)都很簡單

1.x整體就是發(fā)送Http請求去查詢服務(wù)實(shí)例，2.x只不過是將Http請求換成了gRPC的請求

服務(wù)端對于查詢的處理過程都是一樣的，從服務(wù)注冊表中查出符合查詢條件的服務(wù)實(shí)例進(jìn)行返回

不過對于服務(wù)訂閱，兩者的機(jī)制就稍微復(fù)雜一點(diǎn)

在Nacos客戶端，不論是1.x還是2.x都是通過SDK中的NamingService#subscribe方法來發(fā)起訂閱的

當(dāng)有服務(wù)實(shí)例數(shù)據(jù)變動(dòng)的時(shí)，客戶端就會(huì)回調(diào)EventListener，就可以拿到最新的服務(wù)實(shí)例數(shù)據(jù)了

雖然1.x還是2.x都是同樣的方法，但是具體的實(shí)現(xiàn)邏輯是不一樣的

1.x服務(wù)訂閱實(shí)現(xiàn)

在1.x版本的時(shí)候，服務(wù)訂閱的處理邏輯大致會(huì)有以下三步：

第一步，客戶端在啟動(dòng)的時(shí)候，會(huì)去構(gòu)建一個(gè)叫PushReceiver的類

這個(gè)類會(huì)去創(chuàng)建一個(gè)UDP Socket，端口是隨機(jī)的

其實(shí)通過名字就可以知道這個(gè)類的作用，就是通過UDP的方式接收服務(wù)端推送的數(shù)據(jù)的

第二步，調(diào)用NamingService#subscribe來發(fā)起訂閱時(shí)，會(huì)先去服務(wù)端查詢需要訂閱服務(wù)的所有實(shí)例信息

之后會(huì)將所有服務(wù)實(shí)例數(shù)據(jù)存到客戶端的一個(gè)內(nèi)部緩存中

并且在查詢的時(shí)候，會(huì)將這個(gè)UDP Socket的端口作為一個(gè)參數(shù)傳到服務(wù)端

服務(wù)端接收到這個(gè)UDP端口后，后續(xù)就通過這個(gè)端口給客戶端推送服務(wù)實(shí)例數(shù)據(jù)

第三步，會(huì)為這次訂閱開啟一個(gè)不定時(shí)執(zhí)行的任務(wù)

之所以不定時(shí)，是因?yàn)檫@個(gè)當(dāng)執(zhí)行異常的時(shí)候，下次執(zhí)行的時(shí)間間隔就會(huì)變長，但是最多不超過60s，正常是10s，這個(gè)10s是查詢服務(wù)實(shí)例是服務(wù)端返回的

這個(gè)任務(wù)會(huì)去從服務(wù)端查詢訂閱的服務(wù)實(shí)例信息，然后更新內(nèi)部緩存

這里你可能會(huì)有個(gè)疑問

既然有了服務(wù)變動(dòng)推送的功能，為什么還要定時(shí)去查詢更新服務(wù)實(shí)例信息呢?

其實(shí)很簡單，那就是因?yàn)閁DP通信不穩(wěn)定導(dǎo)致的

雖然有Push，但是由于UDP通信自身的不確定性，有可能會(huì)導(dǎo)致客戶端接收變動(dòng)信息失敗

所以這里就加了一個(gè)定時(shí)任務(wù)，彌補(bǔ)這種可能性，屬于一個(gè)兜底的方案。

這就是1.x版本的服務(wù)訂閱的實(shí)現(xiàn)

2.x服務(wù)訂閱的實(shí)現(xiàn)

講完1.x的版本實(shí)現(xiàn)，接下來就講一講2.x版本的實(shí)現(xiàn)

由于2.x版本換成了gRPC長連接的方式，所以2.x版本服務(wù)數(shù)據(jù)變更推送已經(jīng)完全拋棄了1.x的UDP做法

當(dāng)有服務(wù)實(shí)例變動(dòng)的時(shí)候，服務(wù)端直接通過這個(gè)長連接將服務(wù)信息發(fā)送給客戶端

客戶端拿到最新服務(wù)實(shí)例數(shù)據(jù)之后的處理方式就跟1.x是一樣了

除了處理方式一樣，2.x也繼承了1.x的其他的東西

比如客戶端依然會(huì)有服務(wù)實(shí)例的緩存

定時(shí)對比機(jī)制也保留了，只不過這個(gè)定時(shí)對比的機(jī)制默認(rèn)是關(guān)閉狀態(tài)

之所以默認(rèn)關(guān)閉，主要還是因?yàn)殚L連接還是比較穩(wěn)定的原因

當(dāng)客戶端出現(xiàn)異常，接收不到請求，那么服務(wù)端會(huì)直接跟客戶端斷開連接

當(dāng)恢復(fù)正常，由于有Redo操作，所以還是能拿到最新的實(shí)例信息的

所以2.x版本的服務(wù)訂閱功能的實(shí)現(xiàn)大致如下圖所示

這里還有個(gè)細(xì)節(jié)需要注意

在1.x版本的時(shí)候，任何服務(wù)都是可以被訂閱的

但是在2.x版本中，只支持訂閱臨時(shí)服務(wù)，對于永久服務(wù)，已經(jīng)不支持訂閱了

小總結(jié)

服務(wù)查詢1.x是通過Http請求；2.x通過gRPC請求

服務(wù)訂閱1.x是通過UDP來推送的；2.x就基于gRPC長連接來實(shí)現(xiàn)的

1.x和2.x客戶端都有服務(wù)實(shí)例的緩存，也有定時(shí)對比機(jī)制，只不過1.x會(huì)自動(dòng)開啟；2.x提供了一個(gè)開個(gè)，可以手動(dòng)選擇是否開啟，默認(rèn)不開啟

數(shù)據(jù)一致性

由于Nacos是支持集群模式的，所以一定會(huì)涉及到分布式系統(tǒng)中不可避免的數(shù)據(jù)一致性問題

1、服務(wù)實(shí)例的責(zé)任機(jī)制

再說數(shù)據(jù)一致性問題之前，先來討論一下服務(wù)實(shí)例的責(zé)任機(jī)制

什么是服務(wù)實(shí)例的責(zé)任機(jī)制？

比如上面提到的服務(wù)注冊、心跳管理、監(jiān)控檢查機(jī)制，當(dāng)只有一個(gè)Nacos服務(wù)時(shí)，那么自然而言這個(gè)服務(wù)會(huì)去檢查所有的服務(wù)實(shí)例的心跳時(shí)間，執(zhí)行所有服務(wù)實(shí)例的健康檢查任務(wù)

但是當(dāng)出現(xiàn)Nacos服務(wù)出現(xiàn)集群時(shí)，為了平衡各Nacos服務(wù)的壓力，Nacos會(huì)根據(jù)一定的規(guī)則讓每個(gè)Nacos服務(wù)只管理一部分服務(wù)實(shí)例的

當(dāng)然每個(gè)Nacos服務(wù)的注冊表還是全部的服務(wù)實(shí)例數(shù)據(jù)

這個(gè)管理機(jī)制我給他起了一個(gè)名字，就叫做責(zé)任機(jī)制，因?yàn)槲以?.x和2.x都提到了responsible這個(gè)單詞

本質(zhì)就是Nacos服務(wù)對哪些服務(wù)實(shí)例負(fù)有心跳監(jiān)測，健康檢查的責(zé)任。

2、CAP定理和BASE理論

談到數(shù)據(jù)一致性問題，一定離不開兩個(gè)著名分布式理論

• CAP定理
• BASE理論

CAP定理中，三個(gè)字母分別代表這些含義：

• C，Consistency單詞的縮寫，代表一致性，指分布式系統(tǒng)中各個(gè)節(jié)點(diǎn)的數(shù)據(jù)保持強(qiáng)一致，也就是每個(gè)時(shí)刻都必須一樣，不一樣整個(gè)系統(tǒng)就不能對外提供服務(wù)
• A，Availability單詞的縮寫，代表可用性，指整個(gè)分布式系統(tǒng)保持對外可用，即使從每個(gè)節(jié)點(diǎn)獲取的數(shù)據(jù)可能都不一樣，只要能獲取到就行
• P，Partition tolerance單詞的縮寫，代表分區(qū)容錯(cuò)性。

所謂的CAP定理，就是指在一個(gè)分布式系統(tǒng)中，CAP這三個(gè)指標(biāo)，最多同時(shí)只能滿足其中的兩個(gè)，不可能三個(gè)都同時(shí)滿足

為什么三者不能同時(shí)滿足？

對于一個(gè)分布式系統(tǒng)，網(wǎng)絡(luò)分區(qū)是一定需要滿足的

而所謂分區(qū)指的是系統(tǒng)中的服務(wù)部署在不同的網(wǎng)絡(luò)區(qū)域中

比如，同一套系統(tǒng)可能同時(shí)在北京和上海都有部署，那么他們就處于不同的網(wǎng)絡(luò)分區(qū)，就可能出現(xiàn)無法互相訪問的情況

當(dāng)然，你也可以把所有的服務(wù)都放在一個(gè)網(wǎng)絡(luò)分區(qū)，但是當(dāng)網(wǎng)絡(luò)出現(xiàn)故障時(shí)，整個(gè)系統(tǒng)都無法對外提供服務(wù)，那這還有什么意義呢？

所以分布式系統(tǒng)一定需要滿足分區(qū)容錯(cuò)性，把系統(tǒng)部署在不同的區(qū)域網(wǎng)絡(luò)中

此時(shí)只剩下了一致性和可用性，它們?yōu)槭裁床荒芡瑫r(shí)滿足？

其實(shí)答案很簡單，就因?yàn)榭赡艹霈F(xiàn)網(wǎng)絡(luò)分區(qū)導(dǎo)致的通信失敗。

比如說，現(xiàn)在出現(xiàn)了網(wǎng)絡(luò)分區(qū)的問題，上圖中的A網(wǎng)絡(luò)區(qū)域和B網(wǎng)絡(luò)區(qū)域無法相互訪問

此時(shí)假設(shè)往上圖中的A網(wǎng)絡(luò)區(qū)域發(fā)送請求，將服務(wù)中的一個(gè)值 i 屬性設(shè)置成 1

如果保證可用性，此時(shí)由于A和B網(wǎng)絡(luò)不通，此時(shí)只有A中的服務(wù)修改成功，B無法修改成功，此時(shí)數(shù)據(jù)AB區(qū)域數(shù)據(jù)就不一致性，也就沒有保證數(shù)據(jù)一致性

如果保證一致性，此時(shí)由于A和B網(wǎng)絡(luò)不通，所以此時(shí)A也不能修改成功，必須修改失敗，否則就會(huì)導(dǎo)致AB數(shù)據(jù)不一致

雖然A沒修改成功，保證了數(shù)據(jù)一致性，AB還是之前相同的數(shù)據(jù)，但是此時(shí)整個(gè)系統(tǒng)已經(jīng)沒有寫可用性了，無法成功寫數(shù)據(jù)了。

所以從上面分析可以看出，在有分區(qū)容錯(cuò)性的前提下，可用性和一致性是無法同時(shí)保證的。

雖然無法同時(shí)一致性和可用性，但是能不能換種思路來思考一下這個(gè)問題

首先我們可以先保證系統(tǒng)的可用性，也就是先讓系統(tǒng)能夠?qū)憯?shù)據(jù)，將A區(qū)域服務(wù)中的i修改成1

之后當(dāng)AB區(qū)域之間網(wǎng)絡(luò)恢復(fù)之后，將A區(qū)域的i值復(fù)制給B區(qū)域，這樣就能夠保證AB區(qū)域間的數(shù)據(jù)最終是一致的了

這不就皆大歡喜了么

這種思路其實(shí)就是BASE理論的核心要點(diǎn)，優(yōu)先保證可用性，數(shù)據(jù)最終達(dá)成一致性。

BASE理論主要是包括以下三點(diǎn)：

• 基本可用（Basically Available）：系統(tǒng)出現(xiàn)故障還是能夠?qū)ν馓峁┓?wù)，不至于直接無法用了
• 軟狀態(tài)（Soft State）：允許各個(gè)節(jié)點(diǎn)的數(shù)據(jù)不一致
• 最終一致性，（Eventually Consistent）：雖然允許各個(gè)節(jié)點(diǎn)的數(shù)據(jù)不一致，但是在一定時(shí)間之后，各個(gè)節(jié)點(diǎn)的數(shù)據(jù)最終需要一致的

BASE理論其實(shí)就是妥協(xié)之后的產(chǎn)物。

3、Nacos的AP和CP

Nacos其實(shí)目前是同時(shí)支持AP和CP的

具體使用AP還是CP得取決于Nacos內(nèi)部的具體功能，并不是有的文章說的可以通過一個(gè)配置*切換。

就以服務(wù)注冊舉例來說，對于臨時(shí)實(shí)例來說，Nacos會(huì)優(yōu)先保證可用性，也就是AP

對于永久實(shí)例，Nacos會(huì)優(yōu)先保證數(shù)據(jù)的一致性，也就是CP

接下來我們就來講一講Nacos的CP和AP的實(shí)現(xiàn)原理

3.1、Nacos的AP實(shí)現(xiàn)

對于AP來說，Nacos使用的是阿里自研的Distro協(xié)議

在這個(gè)協(xié)議中，每個(gè)服務(wù)端節(jié)點(diǎn)是一個(gè)平等的狀態(tài)，每個(gè)服務(wù)端節(jié)點(diǎn)正常情況下數(shù)據(jù)是一樣的，每個(gè)服務(wù)端節(jié)點(diǎn)都可以接收來自客戶端的讀寫請求

當(dāng)某個(gè)節(jié)點(diǎn)剛啟動(dòng)時(shí)，他會(huì)向集群中的某個(gè)節(jié)點(diǎn)發(fā)送請求，拉取所有的服務(wù)實(shí)例數(shù)據(jù)到自己的服務(wù)注冊表中

這樣其它客戶端就可以從這個(gè)服務(wù)節(jié)點(diǎn)中獲取到服務(wù)實(shí)例數(shù)據(jù)了

當(dāng)某個(gè)服務(wù)端節(jié)點(diǎn)接收到注冊臨時(shí)服務(wù)實(shí)例的請求，不僅僅會(huì)將這個(gè)服務(wù)實(shí)例存到自身的服務(wù)注冊表，同時(shí)也會(huì)向其它所有服務(wù)節(jié)點(diǎn)發(fā)送請求，將這個(gè)服務(wù)數(shù)據(jù)同步到其它所有節(jié)點(diǎn)

所以此時(shí)從任意一個(gè)節(jié)點(diǎn)都是可以獲取到所有的服務(wù)實(shí)例數(shù)據(jù)的。

即使數(shù)據(jù)同步的過程發(fā)生異常，服務(wù)實(shí)例也成功注冊到一個(gè)Nacos服務(wù)中，對外部而言，整個(gè)Nacos集群是可用的，也就達(dá)到了AP的效果

同時(shí)為了滿足BASE理論，Nacos也有下面兩種機(jī)制保證最終節(jié)點(diǎn)間數(shù)據(jù)最終是一致的：

• 失敗重試機(jī)制
• 定時(shí)對比機(jī)制

失敗重試機(jī)制是指當(dāng)數(shù)據(jù)同步給其它節(jié)點(diǎn)失敗時(shí)，會(huì)每隔3s重試一次，直到成功

定時(shí)對比機(jī)制就是指，每個(gè)Nacos服務(wù)節(jié)點(diǎn)會(huì)定時(shí)向所有的其它服務(wù)節(jié)點(diǎn)發(fā)送一些認(rèn)證的請求

這個(gè)請求會(huì)告訴每個(gè)服務(wù)節(jié)點(diǎn)自己負(fù)責(zé)的服務(wù)實(shí)例的對應(yīng)的版本號，這個(gè)版本號隨著服務(wù)實(shí)例的變動(dòng)就會(huì)變動(dòng)

如果其它服務(wù)節(jié)點(diǎn)的數(shù)據(jù)的版本號跟自己的對不上，那就說明其它服務(wù)節(jié)點(diǎn)的數(shù)據(jù)不是最新的

此時(shí)這個(gè)Nacos服務(wù)節(jié)點(diǎn)就會(huì)將自己負(fù)責(zé)的服務(wù)實(shí)例數(shù)據(jù)發(fā)給不是最新數(shù)據(jù)的節(jié)點(diǎn)，這樣就保證了每個(gè)節(jié)點(diǎn)的數(shù)據(jù)是一樣的了。

3.2、Nacos的CP實(shí)現(xiàn)

Nacos的CP實(shí)現(xiàn)是基于Raft算法來實(shí)現(xiàn)的

在1.x版本早期，Nacos是自己手動(dòng)實(shí)現(xiàn)Raft算法

在2.x版本，Nacos移除了手動(dòng)實(shí)現(xiàn)Raft算法，轉(zhuǎn)而擁抱基于螞蟻開源的JRaft框架

在Raft算法，每個(gè)節(jié)點(diǎn)主要有三個(gè)狀態(tài)

• Leader，負(fù)責(zé)所有的讀寫請求，一個(gè)集群只有一個(gè)
• Follower，從節(jié)點(diǎn)，主要是負(fù)責(zé)復(fù)制Leader的數(shù)據(jù)，保證數(shù)據(jù)的一致性
• Candidate，候選節(jié)點(diǎn)，最終會(huì)變成Leader或者Follower

集群啟動(dòng)時(shí)都是節(jié)點(diǎn)Follower，經(jīng)過一段時(shí)間會(huì)轉(zhuǎn)換成Candidate狀態(tài)，再經(jīng)過一系列復(fù)雜的選擇算法，選出一個(gè)Leader

這個(gè)選舉算法比較復(fù)雜，完全值得另寫一篇文章，這里就不細(xì)說了。不過立個(gè)flag，如果本篇文章點(diǎn)贊量超過28個(gè)，我連夜爆肝，再來一篇。

當(dāng)有寫請求時(shí)，如果請求的節(jié)點(diǎn)不是Leader節(jié)點(diǎn)時(shí)，會(huì)將請求轉(zhuǎn)給Leader節(jié)點(diǎn)，由Leader節(jié)點(diǎn)處理寫請求

比如，有個(gè)客戶端連到的上圖中的Nacos服務(wù)2節(jié)點(diǎn)，之后向Nacos服務(wù)2注冊服務(wù)

Nacos服務(wù)2接收到請求之后，會(huì)判斷自己是不是Leader節(jié)點(diǎn)，發(fā)現(xiàn)自己不是

此時(shí)Nacos服務(wù)2就會(huì)向Leader節(jié)點(diǎn)發(fā)送請求，Leader節(jié)點(diǎn)接收到請求之后，會(huì)處理服務(wù)注冊的過程

為什么說Raft是保證CP的呢？

主要是因?yàn)镽aft在處理寫的時(shí)候有一個(gè)判斷過程

• 首先，Leader在處理寫請求時(shí)，不會(huì)直接數(shù)據(jù)應(yīng)用到自己的系統(tǒng)，而是先向所有的Follower發(fā)送請求，讓他們先處理這個(gè)請求
• 當(dāng)超過半數(shù)的Follower成功處理了這個(gè)寫請求之后，Leader才會(huì)寫數(shù)據(jù)，并返回給客戶端請求處理成功
• 如果超過一定時(shí)間未收到超過半數(shù)處理成功Follower的信號，此時(shí)Leader認(rèn)為這次寫數(shù)據(jù)是失敗的，就不會(huì)處理寫請求，直接返回給客戶端請求失敗

所以，一旦發(fā)生故障，導(dǎo)致接收不到半數(shù)的Follower寫成功的響應(yīng)，整個(gè)集群就直接寫失敗，這就很符合CP的概念了。

不過這里還有一個(gè)小細(xì)節(jié)需要注意

Nacos在處理查詢服務(wù)實(shí)例的請求直接時(shí)，并不會(huì)將請求轉(zhuǎn)發(fā)給Leader節(jié)點(diǎn)處理，而是直接查當(dāng)前Nacos服務(wù)實(shí)例的注冊表

這其實(shí)就會(huì)引發(fā)一個(gè)問題

如果客戶端查詢的Follower節(jié)點(diǎn)沒有及時(shí)處理Leader同步過來的寫請求（過半響應(yīng)的節(jié)點(diǎn)中不包括這個(gè)節(jié)點(diǎn)），此時(shí)在這個(gè)Follower其實(shí)是查不到最新的數(shù)據(jù)的，這就會(huì)導(dǎo)致數(shù)據(jù)的不一致

所以說，雖然Raft協(xié)議規(guī)定要求從Leader節(jié)點(diǎn)查最新的數(shù)據(jù)，但是Nacos至少在讀服務(wù)實(shí)例數(shù)據(jù)時(shí)并沒有遵守這個(gè)協(xié)議

當(dāng)然對于其它的一些數(shù)據(jù)的讀寫請求有的還是遵守了這個(gè)協(xié)議。

JRaft對于讀請求其實(shí)是做了很多優(yōu)化的，其實(shí)從Follower節(jié)點(diǎn)通過一定的機(jī)制也是能夠保證讀到最新的數(shù)據(jù)

數(shù)據(jù)模型

在Nacos中，一個(gè)服務(wù)的確定是由三部分信息確定

• 命名空間（Namespace）：多租戶隔離用的，默認(rèn)是public
• 分組（Group）：這個(gè)其實(shí)可以用來做環(huán)境隔離，服務(wù)注冊時(shí)可以指定服務(wù)的分組，比如是測試環(huán)境或者是開發(fā)環(huán)境，默認(rèn)是DEFAULT_GROUP
• 服務(wù)名（ServiceName）：這個(gè)就不用多說了

通過上面三者就可以確定同一個(gè)服務(wù)了

在服務(wù)注冊和訂閱的時(shí)候，必須要指定上述三部分信息，如果不指定，Nacos就會(huì)提供默認(rèn)的信息

不過，在Nacos中，在服務(wù)里面其實(shí)還是有一個(gè)集群的概念

在服務(wù)注冊的時(shí)候，可以指定這個(gè)服務(wù)實(shí)例在哪個(gè)集體的集群中，默認(rèn)是在DEFAULT集群下

在SpringCloud環(huán)境底下可以通過如下配置去設(shè)置

spring
??cloud:
????nacos:
??????discovery:
????????cluster-name:?sanyoujavaCluster

在服務(wù)訂閱的時(shí)候，可以指定訂閱哪些集群下的服務(wù)實(shí)例

當(dāng)然，也可以不指定，如果不指定話，默認(rèn)就是訂閱這個(gè)服務(wù)下的所有集群的服務(wù)實(shí)例

我們?nèi)粘Ｊ褂弥锌梢詫⒉渴鹪谙嗤瑓^(qū)域的服務(wù)劃分為同一個(gè)集群，比如杭州屬于一個(gè)集群，上海屬于一個(gè)集群

這樣服務(wù)調(diào)用的時(shí)候，就可以優(yōu)先使用同一個(gè)地區(qū)的服務(wù)了，比跨區(qū)域調(diào)用速度更快。

總結(jié)

到這，終終終于總算是講完了Nacos作為注冊中心核心的實(shí)現(xiàn)原理

這篇文章從最開始的翻源碼、查資料到最終完成，前前后后也肝了大半個(gè)月的時(shí)間，橫跨了2023和2024，碼了上萬字

不知道你讀完整篇文章是否有所收貨

不過有一點(diǎn)可以確定的是，能夠看到這里的那一定都是真愛粉了

2024年到了，這里也祝大家身體健康，升職加薪，今年我也會(huì)繼續(xù)輸出硬核干貨文章

好了，本文就講到這里，如果覺得本篇對你有點(diǎn)幫助，歡迎點(diǎn)贊、在看、收藏、轉(zhuǎn)發(fā)分享給其他需要的人，你的支持就是我更新的最大動(dòng)力，感謝感謝！

往期熱門文章推薦

如何去閱讀源碼，我總結(jié)了18條心法

如何寫出漂亮代碼，我總結(jié)了45個(gè)小技巧

三萬字盤點(diǎn)Spring/Boot的那些常用擴(kuò)展點(diǎn)

三萬字盤點(diǎn)Spring 9大核心基礎(chǔ)功能

兩萬字盤點(diǎn)那些被玩爛了的設(shè)計(jì)模式

萬字+20張圖剖析Spring啟動(dòng)時(shí)12個(gè)核心步驟

1.5萬字+30張圖盤點(diǎn)索引常見的11個(gè)知識(shí)點(diǎn)

1.5萬字+25張圖盤點(diǎn)RocketMQ 11種消息類型

掃碼或者搜索關(guān)注公眾號 三友的java日記 ，及時(shí)干貨不錯(cuò)過，公眾號致力于通過畫圖加上通俗易懂的語言講解技術(shù)，讓技術(shù)更加容易學(xué)習(xí)，回復(fù) 面試 即可獲得一套面試真題。