偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

ETCD對(duì)比Consul和zooKeeper如何選型

開(kāi)發(fā) 前端
ETCD是一個(gè)分布式、可靠的key-value存儲(chǔ)的分布式系統(tǒng),用于存儲(chǔ)分布式系統(tǒng)中的關(guān)鍵數(shù)據(jù);當(dāng)然,它不僅僅用于存儲(chǔ),還提供配置共享及服務(wù)發(fā)現(xiàn);基于Go語(yǔ)言實(shí)現(xiàn) 。

 [[424540]]

etcd選型對(duì)比

前言

對(duì)比 Consul, ZooKeeper。選型etcd有那些好處呢?

基本架構(gòu)和原理

etcd

ETCD是一個(gè)分布式、可靠的key-value存儲(chǔ)的分布式系統(tǒng),用于存儲(chǔ)分布式系統(tǒng)中的關(guān)鍵數(shù)據(jù);當(dāng)然,它不僅僅用于存儲(chǔ),還提供配置共享及服務(wù)發(fā)現(xiàn);基于Go語(yǔ)言實(shí)現(xiàn) 。

etcd的特點(diǎn)

  • 完全復(fù)制:集群中的每個(gè)節(jié)點(diǎn)都可以使用完整的存檔

  • 高可用性:Etcd可用于避免硬件的單點(diǎn)故障或網(wǎng)絡(luò)問(wèn)題

  • 一致性:每次讀取都會(huì)返回跨多主機(jī)的最新寫(xiě)入

  • 簡(jiǎn)單:包括一個(gè)定義良好、面向用戶(hù)的API(gRPC)

  • 安全:實(shí)現(xiàn)了帶有可選的客戶(hù)端證書(shū)身份驗(yàn)證的自動(dòng)化TLS

  • 可靠:使用Raft算法實(shí)現(xiàn)了強(qiáng)一致、高可用的服務(wù)存儲(chǔ)目錄

etcd 是基于 raft 算法實(shí)現(xiàn)的,具體的實(shí)現(xiàn)可參見(jiàn) etcd實(shí)現(xiàn)raft源碼解讀

Consul

先放一張 consul 的架構(gòu)圖

consul 使用的是 Gossip 協(xié)議

Gossip 中文名稱(chēng)叫流言協(xié)議,它是一種消息傳播協(xié)議。它的核心思想其實(shí)源自我們生活中的八卦、閑聊。我們?cè)谌粘I钪兴吹降膭疟⑵鋵?shí)源于兩類(lèi),一類(lèi)是權(quán)威機(jī)構(gòu)如國(guó)家新聞媒體發(fā)布的消息,另一類(lèi)則是大家通過(guò)微信等社交聊天軟件相互八卦,一傳十,十傳百的結(jié)果。

Gossip 協(xié)議的基本工作原理與我們八卦類(lèi)似,在 Gossip 協(xié)議中,如下圖所示,各個(gè)節(jié)點(diǎn)會(huì)周期性地選擇一定數(shù)量節(jié)點(diǎn),然后將消息同步給這些節(jié)點(diǎn)。收到消息后的節(jié)點(diǎn)同樣做出類(lèi)似的動(dòng)作,隨機(jī)的選擇節(jié)點(diǎn),繼續(xù)擴(kuò)散給其他節(jié)點(diǎn)。

Gossip 協(xié)議的基本工作原理與我們八卦類(lèi)似,在 Gossip 協(xié)議中,如下圖所示,各個(gè)節(jié)點(diǎn)會(huì)周期性地選擇一定數(shù)量節(jié)點(diǎn),然后將消息同步給這些節(jié)點(diǎn)。收到消息后的節(jié)點(diǎn)同樣做出類(lèi)似的動(dòng)作,隨機(jī)的選擇節(jié)點(diǎn),繼續(xù)擴(kuò)散給其他節(jié)點(diǎn)。

最終經(jīng)過(guò)一定次數(shù)的擴(kuò)散、傳播,整個(gè)集群的各個(gè)節(jié)點(diǎn)都能感知到此消息,各個(gè)節(jié)點(diǎn)的數(shù)據(jù)趨于一致。Gossip 協(xié)議被廣泛應(yīng)用在多個(gè)知名項(xiàng)目中,比如 Redis Cluster 集群版,Apache Cassandra,AWS Dynamo。

Consul 天然支持多數(shù)據(jù)中心,但是多數(shù)據(jù)中心內(nèi)的服務(wù)數(shù)據(jù)并不會(huì)跨數(shù)據(jù)中心同步,各個(gè)數(shù)據(jù)中心的 Server 集群是獨(dú)立的,Consul 提供了 Prepared Query 功能,它支持根據(jù)一定的策略返回多數(shù)據(jù)中心下的最佳的服務(wù)實(shí)例地址,使你的服務(wù)具備跨數(shù)據(jù)中心容災(zāi)。

這里來(lái)看下 Prepared Query 查詢(xún)的過(guò)程:

比如當(dāng)你的 API 網(wǎng)關(guān)收到用戶(hù)請(qǐng)求查詢(xún) A 服務(wù),API 網(wǎng)關(guān)服務(wù)優(yōu)先從緩存中查找 A 服務(wù)對(duì)應(yīng)的最佳實(shí)例。若無(wú)緩存則向 Consul 發(fā)起一個(gè) Prepared Query 請(qǐng)求查詢(xún) A 服務(wù)實(shí)例,Consul 收到請(qǐng)求后,優(yōu)先返回本數(shù)據(jù)中心下的服務(wù)實(shí)例。如果本數(shù)據(jù)中心沒(méi)有或異常則根據(jù)數(shù)據(jù)中心間 RTT 由近到遠(yuǎn)查詢(xún)其它數(shù)據(jù)中心數(shù)據(jù),最終網(wǎng)關(guān)可將用戶(hù)請(qǐng)求轉(zhuǎn)發(fā)給最佳的數(shù)據(jù)中心下的實(shí)例地址。

Consul 支持以下三種模式的讀請(qǐng)求:

  • 默認(rèn)(default)。默認(rèn)是此模式,絕大部分場(chǎng)景下它能保證數(shù)據(jù)的強(qiáng)一致性。但在老的 Leader 出現(xiàn)網(wǎng)絡(luò)分區(qū)被隔離、新的 Leader 被選舉出來(lái)的一個(gè)極小時(shí)間窗口內(nèi),可能會(huì)導(dǎo)致 stale read。這是因?yàn)?Consul 為了提高讀性能,使用的是基于 Lease 機(jī)制來(lái)維持 Leader 身份,避免了與其他節(jié)點(diǎn)進(jìn)行交互確認(rèn)的開(kāi)銷(xiāo)。

  • 強(qiáng)一致性(consistent)。強(qiáng)一致性讀與 etcd 默認(rèn)線性讀模式一樣,每次請(qǐng)求需要集群多數(shù)節(jié)點(diǎn)確認(rèn) Leader 身份,因此相比 default 模式讀,性能會(huì)有所下降。

  • 弱一致性(stale)。任何節(jié)點(diǎn)都可以讀,無(wú)論它是否 Leader??赡茏x取到陳舊的數(shù)據(jù),類(lèi)似 etcd 的串行讀。這種讀模式不要求集群有 Leader,因此當(dāng)集群不可用時(shí),只要有節(jié)點(diǎn)存活,它依然可以響應(yīng)讀請(qǐng)求。

ZooKeeper

ZooKeeper 是一個(gè)典型的分布式數(shù)據(jù)一致性解決方案,分布式應(yīng)用程序可以基于 ZooKeeper 實(shí)現(xiàn)諸如數(shù)據(jù)發(fā)布/訂閱、負(fù)載均衡、命名服務(wù)、分布式協(xié)調(diào)/通知、集群管理、Master 選舉、分布式鎖和分布式隊(duì)列等功能。

ZooKeeper 的有點(diǎn):

  • 順序一致性: 從同一客戶(hù)端發(fā)起的事務(wù)請(qǐng)求,最終將會(huì)嚴(yán)格地按照順序被應(yīng)用到 ZooKeeper 中去。

  • 原子性: 所有事務(wù)請(qǐng)求的處理結(jié)果在整個(gè)集群中所有機(jī)器上的應(yīng)用情況是一致的,也就是說(shuō),要么整個(gè)集群中所有的機(jī)器都成功應(yīng)用了某一個(gè)事務(wù),要么都沒(méi)有應(yīng)用。

  • 單一系統(tǒng)映像 : 無(wú)論客戶(hù)端連到哪一個(gè) ZooKeeper 服務(wù)器上,其看到的服務(wù)端數(shù)據(jù)模型都是一致的。

  • 可靠性: 一旦一次更改請(qǐng)求被應(yīng)用,更改的結(jié)果就會(huì)被持久化,直到被下一次更改覆蓋。

再來(lái)看下 ZooKeeper 的架構(gòu)圖,圖片摘自 etcd實(shí)戰(zhàn)課

ZooKeeper 集群中的所有機(jī)器通過(guò)一個(gè) Leader 選舉過(guò)程來(lái)選定一臺(tái)稱(chēng)為 “Leader” 的機(jī)器,Leader 既可以為客戶(hù)端提供寫(xiě)服務(wù)又能提供讀服務(wù)。

除了 Leader 外,F(xiàn)ollower 和 Observer 都只能提供讀服務(wù)。Follower 和 Observer 唯一的區(qū)別在于 Observer 機(jī)器不參與 Leader 的選舉過(guò)程,也不參與寫(xiě)操作的“過(guò)半寫(xiě)成功”策略,因此 Observer 機(jī)器可以在不影響寫(xiě)性能的情況下提升集群的讀性能。

ZooKeeper 使用的是 Zab 協(xié)議

ZAB(ZooKeeper Atomic Broadcast 原子廣播) 協(xié)議是為分布式協(xié)調(diào)服務(wù) ZooKeeper 專(zhuān)門(mén)設(shè)計(jì)的一種支持崩潰恢復(fù)的原子廣播協(xié)議。 在 ZooKeeper 中,主要依賴(lài) ZAB 協(xié)議來(lái)實(shí)現(xiàn)分布式數(shù)據(jù)一致性,基于該協(xié)議,ZooKeeper 實(shí)現(xiàn)了一種主備模式的系統(tǒng)架構(gòu)來(lái)保持集群中各個(gè)副本之間的數(shù)據(jù)一致性。

Zab 協(xié)議可以分為以下階段:

  • Phase 0,Leader 選舉(Leader Election)。一個(gè)節(jié)點(diǎn)只要求獲得半數(shù)以上投票,就可以當(dāng)選為準(zhǔn) Leader;

  • Phase 1,發(fā)現(xiàn)(Discovery)。準(zhǔn) Leader 收集其他節(jié)點(diǎn)的數(shù)據(jù)信息,并將最新的數(shù)據(jù)復(fù)制到自身;

  • Phase 2,同步(Synchronization)。準(zhǔn) Leader 將自身最新數(shù)據(jù)復(fù)制給其他落后的節(jié)點(diǎn),并告知其他節(jié)點(diǎn)自己正式當(dāng)選為 Leader;

  • Phase 3,廣播(Broadcast)。Leader 正式對(duì)外服務(wù),處理客戶(hù)端寫(xiě)請(qǐng)求,對(duì)消息進(jìn)行廣播。當(dāng)收到一個(gè)寫(xiě)請(qǐng)求后,它會(huì)生成 Proposal 廣播給各個(gè) Follower 節(jié)點(diǎn),一半以上 Follower 節(jié)點(diǎn)應(yīng)答之后,Leader 再發(fā)送 Commit 命令給各個(gè) Follower,告知它們提交相關(guān)提案;

關(guān)于 ZAB 中的兩種模式:崩潰恢復(fù)和消息廣播

崩潰恢復(fù)

當(dāng)整個(gè)服務(wù)框架在啟動(dòng)過(guò)程中,或是當(dāng) Leader 服務(wù)器出現(xiàn)網(wǎng)絡(luò)中斷、崩潰退出與重啟等異常情況時(shí),ZAB 協(xié)議就會(huì)進(jìn)人恢復(fù)模式并選舉產(chǎn)生新的Leader服務(wù)器。

當(dāng)選出 leader ,并且完成了上面 Phase 2 的同步過(guò)程,就退出崩潰恢復(fù)模式

消息廣播

當(dāng)準(zhǔn) Leader 將自身最新數(shù)據(jù)復(fù)制給其他落后的節(jié)點(diǎn),并告知其他節(jié)點(diǎn)自己正式當(dāng)選為 Leader。這時(shí)候就可以進(jìn)入廣播模式,當(dāng)有客戶(hù)端進(jìn)行數(shù)據(jù)寫(xiě)入操作的時(shí)候,就可以通過(guò)廣播模式通知所有的 follower 了。

當(dāng)集群中已經(jīng)有過(guò)半的Follower服務(wù)器完成了和Leader服務(wù)器的狀態(tài)同步,那么整個(gè)服務(wù)框架就可以進(jìn)人消息廣播模式了。

選型對(duì)比

  • 1、并發(fā)原語(yǔ):etcd 和 ZooKeeper 并未提供原生的分布式鎖、Leader 選舉支持,只提供了核心的基本數(shù)據(jù)讀寫(xiě)、并發(fā)控制 API,由應(yīng)用上層去封裝,consul 就簡(jiǎn)單多了,提供了原生的支持,通過(guò)簡(jiǎn)單點(diǎn)命令就能使用;

  • 2、服務(wù)發(fā)現(xiàn):etcd 和 ZooKeeper 并未提供原生的服務(wù)發(fā)現(xiàn)支持,Consul 在服務(wù)發(fā)現(xiàn)方面做了很多解放用戶(hù)雙手的工作,提供了服務(wù)發(fā)現(xiàn)的框架,幫助你的業(yè)務(wù)快速接入,并提供了 HTTP 和 DNS 兩種獲取服務(wù)方式;

  • 3、健康檢查:consul 的健康檢查機(jī)制,是一種基于 client、Gossip 協(xié)議、分布式的健康檢查機(jī)制,具備低延時(shí)、可擴(kuò)展的特點(diǎn)。業(yè)務(wù)可通過(guò) Consul 的健康檢查機(jī)制,實(shí)現(xiàn) HTTP 接口返回碼、內(nèi)存乃至磁盤(pán)空間的檢測(cè),相比 etcd、ZooKeeper 它們提供的健康檢查機(jī)制和能力就非常有限了;

etcd 提供了 Lease 機(jī)制來(lái)實(shí)現(xiàn)活性檢測(cè)。它是一種中心化的健康檢查,依賴(lài)用戶(hù)不斷地發(fā)送心跳續(xù)租、更新 TTL

ZooKeeper 使用的是一種名為臨時(shí)節(jié)點(diǎn)的狀態(tài)來(lái)實(shí)現(xiàn)健康檢查。當(dāng) client 與 ZooKeeper 節(jié)點(diǎn)連接斷掉時(shí),ZooKeeper 就會(huì)刪除此臨時(shí)節(jié)點(diǎn)的 key-value 數(shù)據(jù)。它比基于心跳機(jī)制更復(fù)雜,也給 client 帶去了更多的復(fù)雜性,所有 client 必須維持與 ZooKeeper server 的活躍連接并保持存活。

  • 4、watch 特性:相比于 etcd , Consul 存儲(chǔ)引擎是基于Radix Tree實(shí)現(xiàn)的,因此它不支持范圍查詢(xún)和監(jiān)聽(tīng),只支持前綴查詢(xún)和監(jiān)聽(tīng),而 etcd 都支持, ZooKeeper 的 Watch 特性有更多的局限性,它是個(gè)一次性觸發(fā)器;

  • 5、線性讀。etcd 和 Consul 都支持線性讀,而 ZooKeeper 并不具備。

  • 6、權(quán)限機(jī)制比較。etcd 實(shí)現(xiàn)了 RBAC 的權(quán)限校驗(yàn),而 ZooKeeper 和 Consul 實(shí)現(xiàn)的 ACL。

  • 7、事務(wù)比較。etcd 和 Consul 都提供了簡(jiǎn)易的事務(wù)能力,支持對(duì)字段進(jìn)行比較,而 ZooKeeper 只提供了版本號(hào)檢查能力,功能較弱。

  • 8、多數(shù)據(jù)中心。在多數(shù)據(jù)中心支持上,只有 Consul 是天然支持的,雖然它本身不支持?jǐn)?shù)據(jù)自動(dòng)跨數(shù)據(jù)中心同步,但是它提供的服務(wù)發(fā)現(xiàn)機(jī)制、Prepared Query功能,賦予了業(yè)務(wù)在一個(gè)可用區(qū)后端實(shí)例故障時(shí),可將請(qǐng)求轉(zhuǎn)發(fā)到最近的數(shù)據(jù)中心實(shí)例。而 etcd 和 ZooKeeper 并不支持。

總結(jié)

總的看下來(lái),consul 提供了原生的分布式鎖、健康檢查、服務(wù)發(fā)現(xiàn)機(jī)制支持,讓業(yè)務(wù)可以更省心,同時(shí)也對(duì)多數(shù)據(jù)中心進(jìn)行了支持;

當(dāng)然 etcd 和 ZooKeeper 也都有相應(yīng)的庫(kù),也能很好的進(jìn)行支持,但是這兩者不支持多數(shù)據(jù)中心;

ZooKeeper 在 Java 業(yè)務(wù)中選型使用的較多,etcd 因?yàn)槭?go 語(yǔ)言開(kāi)發(fā)的,所以如果本身就是 go 的技術(shù)棧,使用這個(gè)也是個(gè)不錯(cuò)的選擇,Consul 在國(guó)外應(yīng)用比較多,中文文檔及實(shí)踐案例相比 etcd 較少;

參考

【服務(wù)發(fā)現(xiàn)框架選型: Consul、Zookeeper還是etcd ?】https://www.cnblogs.com/sunsky303/p/11127324.html

【23 | 選型:etcd/ZooKeeper/Consul等我們?cè)撊绾芜x擇?】https://time.geekbang.org/column/article/351898

【服務(wù)發(fā)現(xiàn)比較】https://developer.aliyun.com/article/759139

【ZooKeeper講解】https://juejin.cn/post/6844903677367418893

責(zé)任編輯:張燕妮 來(lái)源: boilingfrog'blog
相關(guān)推薦

2020-06-29 07:58:18

ZooKeeperConsul 注冊(cè)中心

2021-05-28 06:19:22

ZooKeeperConsulNacos

2021-12-06 20:39:34

AI

2019-11-13 14:43:12

容器云平臺(tái)軟件

2021-10-19 07:27:07

邊緣集群管理

2017-03-28 10:20:24

Docker通信分析

2023-03-10 15:03:37

Web 應(yīng)用程序API開(kāi)發(fā)

2023-03-16 18:04:00

APIWeb 應(yīng)用程序開(kāi)發(fā)

2015-04-16 11:13:27

云平臺(tái)開(kāi)發(fā)者云計(jì)算選型

2022-05-31 08:21:07

MQ使用場(chǎng)景消費(fèi)消息

2024-12-25 16:12:18

2023-12-21 08:35:30

注冊(cè)中心EurakaEtcd

2021-01-27 05:44:00

Consul術(shù)語(yǔ)命令

2020-03-26 10:05:18

大數(shù)據(jù)IT互聯(lián)網(wǎng)

2021-01-21 10:02:45

Consul架構(gòu)安裝

2023-02-09 18:00:00

日志工具

2021-01-26 13:27:11

分布 Raft 算法

2021-09-02 09:51:32

監(jiān)控系統(tǒng)分布式

2021-09-26 10:22:12

工具選型軟件ERP軟件

2023-03-31 13:53:00

低代碼平臺(tái)選型
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)