SpringCloud 注冊中心 Eureka 集群是怎么保持?jǐn)?shù)據(jù)一致的？

服務(wù)注冊中心不可能是單點(diǎn)的，一定會有一個(gè)集群，那么集群中的服務(wù)注冊信息如何在集群中保持一致的呢？

首先要明確的是 Eureka 是弱數(shù)據(jù)一致性的。

下面從2個(gè)方面來說明：

1. 什么是弱數(shù)據(jù)一致性
2. Eureka 是如何同步數(shù)據(jù)的

1. 弱數(shù)據(jù)一致性

我們知道 ZooKeeper 也可以實(shí)現(xiàn)數(shù)據(jù)中心，ZooKeeper 就是強(qiáng)一致性的。

分布式系統(tǒng)中有一個(gè)重要理論：CAP。

該理論提到了分布式系統(tǒng)中的3個(gè)特性：

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

分布式系統(tǒng)中，數(shù)據(jù)會存在多個(gè)副本中，有一些問題會導(dǎo)致寫入數(shù)據(jù)時(shí)，一部分副本成功、一部分副本失敗，造成數(shù)據(jù)不一致。

滿足一致性就要求對數(shù)據(jù)的更新操作成功后，多副本的數(shù)據(jù)必須保持一致。

• Availability 可用性

在任何時(shí)候客戶端對集群進(jìn)行讀寫操作時(shí)，請求能夠正常響應(yīng)。

• Partition Tolerance 分區(qū)容忍性

發(fā)生通信故障時(shí)，集群被分割為多個(gè)無法通信的分區(qū)時(shí)，集群仍然可用。

CAP 理論指出：這3個(gè)特性不可能同時(shí)滿足，最多滿足2個(gè)。

P?是客觀存在的，不可繞過，那么就是選擇?C?還是選擇?A。

ZooKeeper 選擇了?C，就是盡可能的保證數(shù)據(jù)一致性，某些情況下可以犧牲可用性。

Eureka 則選擇了?A，所以 Eureka 具有高可用性，在任何時(shí)候，服務(wù)消費(fèi)者都能正常獲取服務(wù)列表，但不保證數(shù)據(jù)的強(qiáng)一致性，消費(fèi)者可能會拿到過期的服務(wù)列表。

Eureka 的設(shè)計(jì)理念：保留可用及過期的數(shù)據(jù)總比丟掉可用的數(shù)據(jù)好。

2. Eureka 的數(shù)據(jù)同步方式

2.1 復(fù)制方式

分布式系統(tǒng)的數(shù)據(jù)在多個(gè)副本之間的復(fù)制方式，主要有：

• 主從復(fù)制

就是?Master-Slave?模式，有一個(gè)主副本，其他為從副本，所有寫操作都提交到主副本，再由主副本更新到其他從副本。

寫壓力都集中在主副本上，是系統(tǒng)的瓶頸，從副本可以分擔(dān)讀請求。

• 對等復(fù)制

就是?Peer to Peer?模式，副本間不分主從，任何副本都可以接收寫操作，然后每個(gè)副本間互相進(jìn)行數(shù)據(jù)更新。

對等復(fù)制模式，任何副本都可以接收寫請求，不存在寫壓力瓶頸，但各個(gè)副本間數(shù)據(jù)同步時(shí)可能產(chǎn)生數(shù)據(jù)沖突。

Eureka 采用的就是?Peer to Peer?模式。

2.2 同步過程

Eureka Server 本身依賴了 Eureka Client，也就是每個(gè) Eureka Server 是作為其他 Eureka Server 的 Client。

Eureka Server 啟動后，會通過 Eureka Client 請求其他 Eureka Server 節(jié)點(diǎn)中的一個(gè)節(jié)點(diǎn)，獲取注冊的服務(wù)信息，然后復(fù)制到其他 peer 節(jié)點(diǎn)。

Eureka Server 每當(dāng)自己的信息變更后，例如 Client 向自己發(fā)起注冊、續(xù)約、注銷請求， 就會把自己的最新信息通知給其他 Eureka Server，保持?jǐn)?shù)據(jù)同步。

如果自己的信息變更是另一個(gè)Eureka Server同步過來的，這是再同步回去的話就出現(xiàn)數(shù)據(jù)同步死循環(huán)了。

Eureka Server 在執(zhí)行復(fù)制操作的時(shí)候，使用?HEADER_REPLICATION?這個(gè) http header 來區(qū)分普通應(yīng)用實(shí)例的正常請求，說明這是一個(gè)復(fù)制請求，這樣其他 peer 節(jié)點(diǎn)收到請求時(shí)，就不會再對其進(jìn)行復(fù)制操作，從而避免死循環(huán)。

還有一個(gè)問題，就是數(shù)據(jù)沖突，比如 server A 向 server B 發(fā)起同步請求，如果 A 的數(shù)據(jù)比 B 的還舊，B 不可能接受 A 的數(shù)據(jù)，那么 B 是如何知道 A 的數(shù)據(jù)是舊的呢？這時(shí) A 又應(yīng)該怎么辦呢？

數(shù)據(jù)的新舊一般是通過版本號來定義的，Eureka 是通過?lastDirtyTimestamp?這個(gè)類似版本號的屬性來實(shí)現(xiàn)的。

lastDirtyTimestamp?是注冊中心里面服務(wù)實(shí)例的一個(gè)屬性，表示此服務(wù)實(shí)例最近一次變更時(shí)間。

比如 Eureka Server A 向 Eureka Server B 復(fù)制數(shù)據(jù)，數(shù)據(jù)沖突有2種情況：

（1）A 的數(shù)據(jù)比 B 的新，B 返回 404，A 重新把這個(gè)應(yīng)用實(shí)例注冊到 B。

（2）A 的數(shù)據(jù)比 B 的舊，B 返回 409，要求 A 同步 B 的數(shù)據(jù)。

還有一個(gè)重要的機(jī)制：hearbeat 心跳，即續(xù)約操作，來進(jìn)行數(shù)據(jù)的最終修復(fù)，因?yàn)楣?jié)點(diǎn)間的復(fù)制可能會出錯(cuò)，通過心跳就可以發(fā)現(xiàn)錯(cuò)誤，進(jìn)行彌補(bǔ)。

例如發(fā)現(xiàn)某個(gè)應(yīng)用實(shí)例數(shù)據(jù)與某個(gè)server不一致，則server放回404，實(shí)例重新注冊即可。

3. 小結(jié)

• Eureka 是弱數(shù)據(jù)一致性，選擇了 CAP 中的 AP。
• Eureka 采用 Peer to Peer 模式進(jìn)行數(shù)據(jù)復(fù)制。
• Eureka 通過 lastDirtyTimestamp 來解決復(fù)制沖突。
• Eureka 通過心跳機(jī)制實(shí)現(xiàn)數(shù)據(jù)修復(fù)。