創(chuàng)新互聯(lián)建站-專(zhuān)業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性?xún)r(jià)比江陵網(wǎng)站開(kāi)發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫(kù),直接使用。一站式江陵網(wǎng)站制作公司更省心,省錢(qián),快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋江陵地區(qū)。費(fèi)用合理售后完善，十載實(shí)體公司更值得信賴(lài)。

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

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

下面從2個(gè)方面來(lái)說(shuō)明：

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ù)會(huì)存在多個(gè)副本中，有一些問(wèn)題會(huì)導(dǎo)致寫(xiě)入數(shù)據(jù)時(shí)，一部分副本成功、一部分副本失敗，造成數(shù)據(jù)不一致。

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

• Availability 可用性

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

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

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

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

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

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

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

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

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

2.1 復(fù)制方式

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

• 主從復(fù)制

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

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

• 對(duì)等復(fù)制

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

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

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

2.2 同步過(guò)程

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

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

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

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

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

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

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

lastDirtyTimestamp?是注冊(cè)中心里面服務(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í)例注冊(cè)到 B。

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

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

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

3. 小結(jié)

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