SpringCloud注冊(cè)中心Eureka集群是怎么保持?jǐn)?shù)據(jù)一致的？-創(chuàng)新互聯(lián)
服務(wù)注冊(cè)中心不可能是單點(diǎn)的，一定會(huì)有一個(gè)集群，那么集群中的服務(wù)注冊(cè)信息如何在集群中保持一致的呢？
首先要明確的是 Eureka 是弱數(shù)據(jù)一致性的。
下面從2個(gè)方面來說明：
- 什么是弱數(shù)據(jù)一致性
- 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è)副本中，有一些問題會(huì)導(dǎo)致寫入數(shù)據(jù)時(shí)，一部分副本成功、一部分副本失敗，造成數(shù)據(jù)不一致。
滿足一致性就要求對(duì)數(shù)據(jù)的更新操作成功后，多副本的數(shù)據(jù)必須保持一致。
- Availability 可用性
在任何時(shí)候客戶端對(duì)集群進(jìn)行讀寫操作時(shí)，請(qǐng)求能夠正常響應(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)者可能會(huì)拿到過期的服務(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)讀請(qǐng)求。
- 對(duì)等復(fù)制
就是?Peer to Peer模式，副本間不分主從，任何副本都可以接收寫操作，然后每個(gè)副本間互相進(jìn)行數(shù)據(jù)更新。
對(duì)等復(fù)制模式，任何副本都可以接收寫請(qǐng)求，不存在寫壓力瓶頸，但各個(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 啟動(dòng)后，會(huì)通過 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ù)約、注銷請(qǐng)求， 就會(huì)把自己的最新信息通知給其他 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í)例的正常請(qǐng)求，說明這是一個(gè)復(fù)制請(qǐng)求，這樣其他 peer 節(jié)點(diǎn)收到請(qǐng)求時(shí)，就不會(huì)再對(duì)其進(jìn)行復(fù)制操作，從而避免死循環(huán)。
還有一個(gè)問題，就是數(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ù)的新舊一般是通過版本號(hào)來定義的，Eureka 是通過?lastDirtyTimestamp這個(gè)類似版本號(hào)的屬性來實(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ù)約操作，來進(jìn)行數(shù)據(jù)的最終修復(fù)，因?yàn)楣?jié)點(diǎn)間的復(fù)制可能會(huì)出錯(cuò)，通過心跳就可以發(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 通過 lastDirtyTimestamp 來解決復(fù)制沖突。
- Eureka 通過心跳機(jī)制實(shí)現(xiàn)數(shù)據(jù)修復(fù)。
創(chuàng)新互聯(lián)www.cdcxhl.cn，專業(yè)提供香港、美國云服務(wù)器，動(dòng)態(tài)BGP最優(yōu)骨干路由自動(dòng)選擇，持續(xù)穩(wěn)定高效的網(wǎng)絡(luò)助力業(yè)務(wù)部署。公司持有工信部辦法的idc、isp許可證， 機(jī)房獨(dú)有T級(jí)流量清洗系統(tǒng)配攻擊溯源，準(zhǔn)確進(jìn)行流量調(diào)度，確保服務(wù)器高可用性。佳節(jié)活動(dòng)現(xiàn)已開啟，新人活動(dòng)云服務(wù)器買多久送多久。
文章名稱：SpringCloud注冊(cè)中心Eureka集群是怎么保持?jǐn)?shù)據(jù)一致的？-創(chuàng)新互聯(lián)
文章分享：http://m.jiaotiyi.com/article/piihd.html