原文:yq.aliyun.com/articles/601745?scm=20140722.184.2.173
站在未來(lái)的路口唇聘,回望歷史的迷途,常常會(huì)很有意思柱搜,因?yàn)槲覀儠?huì)不經(jīng)意地興起瘋狂的念頭迟郎,例如如果當(dāng)年某事提前發(fā)生了,而另外一件事又沒(méi)有發(fā)生會(huì)怎樣聪蘸?一如當(dāng)年的奧匈帝國(guó)皇位繼承人斐迪南大公夫婦如果沒(méi)有被塞爾維亞族熱血青年普林西普槍殺會(huì)怎樣宪肖,又如若當(dāng)年的丘老道沒(méi)有經(jīng)過(guò)牛家村會(huì)怎樣?2008 年底健爬,淘寶開(kāi)啟一個(gè)叫做“五彩石”的內(nèi)部重構(gòu)項(xiàng)目控乾,這個(gè)項(xiàng)目后來(lái)成為了淘寶服務(wù)化、面向分布式走自研之路浑劳,走出了互聯(lián)網(wǎng)中間件體系之始阱持,而淘寶服務(wù)注冊(cè)中心 ConfigServer 于同年誕生。2008 年前后魔熏,Yahoo 這個(gè)曾經(jīng)的互聯(lián)網(wǎng)巨頭開(kāi)始逐漸在公開(kāi)場(chǎng)合宣講自己的大數(shù)據(jù)分布式協(xié)調(diào)產(chǎn)品 ZooKeeper衷咽,這個(gè)產(chǎn)品參考了 Google 發(fā)表的關(guān)于 Chubby 以及 Paxos 的論文鸽扁。2010 年11月,ZooKeeper 從 Apache Hadoop 的子項(xiàng)目發(fā)展為 Apache 的頂級(jí)項(xiàng)目镶骗,正式宣告 ZooKeeper 成為一個(gè)工業(yè)級(jí)的成熟穩(wěn)定的產(chǎn)品桶现。2011 年,阿里巴巴開(kāi)源 Dubbo鼎姊,為了更好開(kāi)源骡和,需要?jiǎng)冸x與阿里內(nèi)部系統(tǒng)的關(guān)系,Dubbo 支持了開(kāi)源的 ZooKeeper 作為其注冊(cè)中心相寇,后來(lái)在國(guó)內(nèi)慰于,在業(yè)界諸君的努力實(shí)踐下,Dubbo + ZooKeeper 的典型的服務(wù)化方案成就了 ZooKeeper 作為注冊(cè)中心的聲名唤衫。2015 年雙 11婆赠,ConfigServer 服務(wù)內(nèi)部近 8 個(gè)年頭過(guò)去了,阿里巴巴內(nèi)部“服務(wù)規(guī)募牙”超幾百萬(wàn) 休里,以及推進(jìn)“千里之外”的 IDC 容災(zāi)技術(shù)戰(zhàn)略等,共同促使阿里巴巴內(nèi)部開(kāi)啟了 ConfigServer 2.0 到 ConfigServer 3.0 的架構(gòu)升級(jí)之路赃承。時(shí)間走向 2018 年妙黍,站在 10 年的時(shí)間路口上,有多少人愿意在追逐日新月異的新潮技術(shù)概念的時(shí)候瞧剖,稍微慢一下腳步拭嫁,仔細(xì)凝視一下服務(wù)發(fā)現(xiàn)這個(gè)領(lǐng)域,有多少人想到過(guò)或者思考過(guò)一個(gè)問(wèn)題:服務(wù)發(fā)現(xiàn)筒繁,ZooKeeper 真的是最佳選擇么噩凹?而回望歷史,我們也偶有迷思毡咏,在服務(wù)發(fā)現(xiàn)這個(gè)場(chǎng)景下,如果當(dāng)年 ZooKeeper 的誕生之日比我們 HSF 的注冊(cè)中心 ConfigServer 早一點(diǎn)會(huì)怎樣逮刨?我們會(huì)不會(huì)走向先使用 ZooKeeper 然后瘋狂改造與修補(bǔ) ZooKeeper 以適應(yīng)阿里巴巴的服務(wù)化場(chǎng)景與需求的彎路呕缭?但是,站在今天和前人的肩膀上修己,我們從未如今天這樣堅(jiān)定的認(rèn)知到恢总,在服務(wù)發(fā)現(xiàn)領(lǐng)域,ZooKeeper 根本就不能算是最佳的選擇睬愤,一如這些年一直與我們同行的 Eureka 以及這篇文章 《Eureka! Why You Shouldn’t Use ZooKeeper for Service Discovery》那堅(jiān)定的闡述一樣片仿,為什么你不應(yīng)該用 ZooKeeper 做服務(wù)發(fā)現(xiàn)!吾道不孤矣尤辱。注冊(cè)中心需求分析及關(guān)鍵設(shè)計(jì)考量接下來(lái)砂豌,讓我們回歸對(duì)服務(wù)發(fā)現(xiàn)的需求分析厢岂,結(jié)合阿里巴巴在關(guān)鍵場(chǎng)景上的實(shí)踐,來(lái)一一分析阳距,一起探討為何說(shuō) ZooKeeper 并不是最合適的注冊(cè)中心解決方案塔粒。注冊(cè)中心是 CP 還是 AP 系統(tǒng)?CAP 和 BASE 理論相信讀者都已經(jīng)耳熟能詳,其業(yè)已成了指導(dǎo)分布式系統(tǒng)及互聯(lián)網(wǎng)應(yīng)用構(gòu)建的關(guān)鍵原則之一筐摘,在此不再贅述其理論卒茬,我們直接進(jìn)入對(duì)注冊(cè)中心的數(shù)據(jù)一致性和可用性需求的分析:
- 數(shù)據(jù)一致性需求分析
注冊(cè)中心最本質(zhì)的功能可以看成是一個(gè) Query 函數(shù) Si = F(service-name)
,以 service-name
為查詢參數(shù)咖熟,service-name
對(duì)應(yīng)的服務(wù)的可用的 endpoints (ip:port)
列表為返回值.
注: 后文將 service 簡(jiǎn)寫(xiě)為 svc圃酵。
先來(lái)看看關(guān)鍵數(shù)據(jù) endpoints (ip:port)
不一致性帶來(lái)的影響,即 CAP 中的 C 不滿足帶來(lái)的后果 :
如上圖所示馍管,如果一個(gè) svcB 部署了 10 個(gè)節(jié)點(diǎn) (副本 /Replica)郭赐,如果對(duì)于同一個(gè)服務(wù)名 svcB, 調(diào)用者 svcA 的 2 個(gè)節(jié)點(diǎn)的 2 次查詢返回了不一致的數(shù)據(jù),例如: S1 = { ip1,ip2,ip3...,ip9 }, S2 = { ip2,ip3,....ip10 }, 那么這次不一致帶來(lái)的影響是什么咽斧?相信你一定已經(jīng)看出來(lái)了堪置,svcB 的各個(gè)節(jié)點(diǎn)流量會(huì)有一點(diǎn)不均衡。ip1 和 ip10 相對(duì)其它 8 個(gè)節(jié)點(diǎn){ip2...ip9}张惹,請(qǐng)求流量小了一點(diǎn)舀锨,但很明顯,在分布式系統(tǒng)中宛逗,即使是對(duì)等部署的服務(wù)坎匿,因?yàn)檎?qǐng)求到達(dá)的時(shí)間,硬件的狀態(tài)雷激,操作系統(tǒng)的調(diào)度替蔬,虛擬機(jī)的 GC 等,任何一個(gè)時(shí)間點(diǎn)屎暇,這些對(duì)等部署的節(jié)點(diǎn)狀態(tài)也不可能完全一致承桥,而流量不一致的情況下,只要注冊(cè)中心在 SLA 承諾的時(shí)間內(nèi)(例如 1s 內(nèi))將數(shù)據(jù)收斂到一致?tīng)顟B(tài)(即滿足最終一致)根悼,流量將很快趨于統(tǒng)計(jì)學(xué)意義上的一致凶异,所以注冊(cè)中心以最終一致的模型設(shè)計(jì)在生產(chǎn)實(shí)踐中完全可以接受。
- 分區(qū)容忍及可用性需求分析
當(dāng)機(jī)房 3 出現(xiàn)網(wǎng)絡(luò)分區(qū) (Network Partitioned) 的時(shí)候喉恋,即機(jī)房 3 在網(wǎng)絡(luò)上成了孤島,我們知道雖然整體 ZooKeeper 服務(wù)是可用的,但是節(jié)點(diǎn) ZK5 是不可寫(xiě)的轻黑,因?yàn)槁?lián)系不上 Leader糊肤。也就是說(shuō),這時(shí)候機(jī)房 3 的應(yīng)用服務(wù) svcB 是不可以新部署苔悦,重新啟動(dòng)轩褐,擴(kuò)容或者縮容的,但是站在網(wǎng)絡(luò)和服務(wù)調(diào)用的角度看玖详,機(jī)房 3 的 svcA 雖然無(wú)法調(diào)用機(jī)房 1 和機(jī)房 2 的 svcB, 但是與機(jī)房 3 的 svcB 之間的網(wǎng)絡(luò)明明是 OK 的啊把介,為什么不讓我調(diào)用本機(jī)房的服務(wù)?現(xiàn)在因?yàn)樽?cè)中心自身為了保腦裂 (P) 下的數(shù)據(jù)一致性(C)而放棄了可用性蟋座,導(dǎo)致了同機(jī)房的服務(wù)之間出現(xiàn)了無(wú)法調(diào)用拗踢,這是絕對(duì)不允許的!可以說(shuō)在實(shí)踐中向臀,注冊(cè)中心不能因?yàn)樽陨淼娜魏卧蚱茐姆?wù)之間本身的可連通性巢墅,這是注冊(cè)中心設(shè)計(jì)應(yīng)該遵循的鐵律!后面在注冊(cè)中心客戶端災(zāi)容上我們還會(huì)繼續(xù)討論券膀。同時(shí)我們?cè)倏紤]一下這種情況下的數(shù)據(jù)不一致性君纫,如果機(jī)房 1,2芹彬,3 之間都成了孤島蓄髓,那么如果每個(gè)機(jī)房的 svcA 都只拿到本機(jī)房的 svcB 的 ip 列表,也即在各機(jī)房 svcB 的 ip 列表數(shù)據(jù)完全不一致舒帮,影響是什么会喝?其實(shí)沒(méi)啥大影響,只是這種情況下玩郊,全都變成了同機(jī)房調(diào)用肢执,我們?cè)谠O(shè)計(jì)注冊(cè)中心的時(shí)候,有時(shí)候甚至?xí)鲃?dòng)利用這種注冊(cè)中心的數(shù)據(jù)可以不一致性译红,來(lái)幫助應(yīng)用主動(dòng)做到同機(jī)房調(diào)用预茄,從而優(yōu)化服務(wù)調(diào)用鏈路 RT 的效果!通過(guò)以上我們的闡述可以看到侦厚,在 CAP 的權(quán)衡中反璃,注冊(cè)中心的可用性比數(shù)據(jù)強(qiáng)一致性更寶貴,所以整體設(shè)計(jì)更應(yīng)該偏向 AP假夺,而非 CP,數(shù)據(jù)不一致在可接受范圍斋攀,而 P 下舍棄 A 卻完全違反了注冊(cè)中心不能因?yàn)樽陨淼娜魏卧蚱茐姆?wù)本身的可連通性的原則已卷。服務(wù)規(guī)模、容量淳蔼、服務(wù)聯(lián)通性你所在公司的“微服務(wù)”規(guī)模有多大侧蘸?數(shù)百微服務(wù)裁眯?部署了上百個(gè)節(jié)點(diǎn)?那么 3 年后呢讳癌?互聯(lián)網(wǎng)是產(chǎn)生奇跡的地方穿稳,也許你的“服務(wù)”一夜之間就家喻戶曉,流量倍增晌坤,規(guī)模翻番逢艘!當(dāng)數(shù)據(jù)中心服務(wù)規(guī)模超過(guò)一定數(shù)量 (服務(wù)規(guī)模 =F{服務(wù) pub 數(shù), 服務(wù) sub 數(shù)}),作為注冊(cè)中心的 ZooKeeper 很快就會(huì)像下圖的驢子一樣不堪重負(fù)
如上圖所示温技,如果 svcB 經(jīng)歷了注冊(cè)服務(wù) (ip1) 到擴(kuò)容到 2 個(gè)節(jié)點(diǎn)(ip1,ip2)到因宕機(jī)縮容 (ip1 宕機(jī))扭粱,這個(gè)過(guò)程中舵鳞,產(chǎn)生了 3 次針對(duì) ZooKeeper 的寫(xiě)操作。但是仔細(xì)分析琢蛤,通過(guò)事務(wù)日志蜓堕,持久化連續(xù)記錄這個(gè)變化過(guò)程其實(shí)意義不大,因?yàn)樵诜?wù)發(fā)現(xiàn)中博其,服務(wù)調(diào)用發(fā)起方更關(guān)注的是其要調(diào)用的服務(wù)的實(shí)時(shí)的地址列表和實(shí)時(shí)健康狀態(tài)套才,每次發(fā)起調(diào)用時(shí),并不關(guān)心要調(diào)用的服務(wù)的歷史服務(wù)地址列表慕淡、過(guò)去的健康狀態(tài)背伴。但是為什么又說(shuō)需要呢,因?yàn)橐粋€(gè)完整的生產(chǎn)可用的注冊(cè)中心峰髓,除了服務(wù)的實(shí)時(shí)地址列表以及實(shí)時(shí)的健康狀態(tài)之外傻寂,還會(huì)存儲(chǔ)一些服務(wù)的元數(shù)據(jù)信息,例如服務(wù)的版本携兵,分組决瞳,所在的數(shù)據(jù)中心徊都,權(quán)重洗出,鑒權(quán)策略信息,service label 等元信息勒葱,這些數(shù)據(jù)需要持久化存儲(chǔ),并且注冊(cè)中心應(yīng)該提供對(duì)這些元信息的檢索的能力巴柿。Service Health Check使用 ZooKeeper 作為服務(wù)注冊(cè)中心時(shí),服務(wù)的健康檢測(cè)常利用 ZooKeeper 的 Session 活性 Track 機(jī)制 以及結(jié)合 Ephemeral ZNode 的機(jī)制死遭,簡(jiǎn)單而言广恢,就是將服務(wù)的健康監(jiān)測(cè)綁定在了 ZooKeeper 對(duì)于 Session 的健康監(jiān)測(cè)上,或者說(shuō)綁定在 TCP 長(zhǎng)鏈接活性探測(cè)上了呀潭。這在很多時(shí)候也會(huì)造成致命的問(wèn)題钉迷,ZK 與服務(wù)提供者機(jī)器之間的 TCP 長(zhǎng)鏈接活性探測(cè)正常的時(shí)候,該服務(wù)就是健康的么钠署?答案當(dāng)然是否定的糠聪!注冊(cè)中心應(yīng)該提供更豐富的健康監(jiān)測(cè)方案,服務(wù)的健康與否的邏輯應(yīng)該開(kāi)放給服務(wù)提供方自己定義谐鼎,而不是一刀切搞成了 TCP 活性檢測(cè)舰蟆!健康檢測(cè)的一大基本設(shè)計(jì)原則就是盡可能真實(shí)的反饋服務(wù)本身的真實(shí)健康狀態(tài),否則一個(gè)不敢被服務(wù)調(diào)用者相信的健康狀態(tài)判定結(jié)果還不如沒(méi)有健康檢測(cè)狸棍。注冊(cè)中心的容災(zāi)考慮前文提過(guò)身害,在實(shí)踐中,注冊(cè)中心不能因?yàn)樽陨淼娜魏卧蚱茐姆?wù)之間本身的可連通性草戈,那么在可用性上塌鸯,一個(gè)本質(zhì)的問(wèn)題,如果注冊(cè)中心(Registry)本身完全宕機(jī)了唐片,svcA 調(diào)用 svcB 鏈路應(yīng)該受到影響么丙猬?
是的,不應(yīng)該受到影響费韭。服務(wù)調(diào)用(請(qǐng)求響應(yīng)流)鏈路應(yīng)該是弱依賴注冊(cè)中心茧球,必須僅在服務(wù)發(fā)布,機(jī)器上下線揽思,服務(wù)擴(kuò)縮容等必要時(shí)才依賴注冊(cè)中心袜腥。這需要注冊(cè)中心仔細(xì)的設(shè)計(jì)自己提供的客戶端,客戶端中應(yīng)該有針對(duì)注冊(cè)中心服務(wù)完全不可用時(shí)做容災(zāi)的手段钉汗,例如設(shè)計(jì)客戶端緩存數(shù)據(jù)機(jī)制(我們稱之為 client snapshot)就是行之有效的手段羹令。另外,注冊(cè)中心的 health check 機(jī)制也要仔細(xì)設(shè)計(jì)以便在這種情況不會(huì)出現(xiàn)諸如推空等情況的出現(xiàn)损痰。ZooKeeper 的原生客戶端并沒(méi)有這種能力福侈,所以利用 ZooKeeper 實(shí)現(xiàn)注冊(cè)中心的時(shí)候我們一定要問(wèn)自己,如果把 ZooKeeper 所有節(jié)點(diǎn)全干掉卢未,你生產(chǎn)上的所有服務(wù)調(diào)用鏈路能不受任何影響么肪凛?而且應(yīng)該定期就這一點(diǎn)做故障演練堰汉。你有沒(méi)有 ZooKeeper 的專家可依靠?ZooKeeper 看似很簡(jiǎn)單的一個(gè)產(chǎn)品伟墙,但在生產(chǎn)上大規(guī)模使用并且用好翘鸭,并不是那么理所當(dāng)然的事情。如果你決定在生產(chǎn)中引入 ZooKeeper戳葵,你最好做好隨時(shí)向 ZooKeeper 技術(shù)專家尋求幫助的心理預(yù)期就乓,最典型的表現(xiàn)是在兩個(gè)方面:
- 難以掌握的 Client/Session 狀態(tài)機(jī)
但基于 ZooKeeper 的服務(wù)發(fā)現(xiàn)方案卻是依賴 ZooKeeper 提供的長(zhǎng)連接 /Session 管理戏自,Ephemeral ZNode邦投,Event&Notification, ping 機(jī)制上,所以要用好 ZooKeeper 做服務(wù)發(fā)現(xiàn)擅笔,恰恰要理解這些 ZooKeeper 核心的機(jī)制原理志衣,這有時(shí)候會(huì)讓你陷入暴躁,我只是想要個(gè)服務(wù)發(fā)現(xiàn)而已剂娄,怎么要知道這么多蠢涝?而如果這些你都理解了并且不踩坑,恭喜你阅懦,你已經(jīng)成為 ZooKeeper 的技術(shù)專家了和二。
- 難以承受的異常處理
我們?cè)诎⒗锇桶蛢?nèi)部應(yīng)用接入 ZooKeeper 時(shí),有一個(gè)《ZooKeeper 應(yīng)用接入必知必會(huì)》的 WIKI耳胎,其中關(guān)于異常處理有過(guò)如下的論述:
向左走酵使,向右走阿里巴巴是不是完全沒(méi)有使用 ZooKeeper荐吉?并不是!熟悉阿里巴巴技術(shù)體系的都知道口渔,其實(shí)阿里巴巴維護(hù)了目前國(guó)內(nèi)乃至世界上最大規(guī)模的 ZooKeeper 集群样屠,整體規(guī)模有近千臺(tái)的 ZooKeeper 服務(wù)節(jié)點(diǎn)。同時(shí)阿里巴巴中間件內(nèi)部也維護(hù)了一個(gè)面向大規(guī)模生產(chǎn)的搓劫、高可用瞧哟、更易監(jiān)控和運(yùn)維的 ZooKeeper 的代碼分支 TaoKeeper,如果以我們近 10 年在各個(gè)業(yè)務(wù)線和生產(chǎn)上使用 ZooKeeper 的實(shí)踐枪向,給 ZooKeeper 用一個(gè)短語(yǔ)評(píng)價(jià)的話勤揩,那么我們認(rèn)為 ZooKeeper 應(yīng)該是 “The King Of Coordination for Big Data”!如果說(shuō)要選出應(yīng)用開(kāi)發(fā)者在使用 ZooKeeper 的過(guò)程中惯吕,最需要了解清楚的事情?那么根據(jù)我們之前的支持經(jīng)驗(yàn)怕午,一定是異常處理废登。當(dāng)所有一切(宿主機(jī),磁盤(pán)郁惜,網(wǎng)絡(luò)等等)都很幸運(yùn)的正常工作的時(shí)候堡距,應(yīng)用與 ZooKeeper 可能也會(huì)運(yùn)行的很好,但不幸的是兆蕉,我們整天會(huì)面對(duì)各種意外羽戒,而且這遵循墨菲定律,意料之外的壞事情總是在你最擔(dān)心的時(shí)候發(fā)生虎韵。所以務(wù)必仔細(xì)了解 ZooKeeper 在一些場(chǎng)景下會(huì)出現(xiàn)的異常和錯(cuò)誤易稠,確保您正確的理解了這些異常和錯(cuò)誤,以及知道您的應(yīng)用如何正確的處理這些情況包蓝。
簡(jiǎn)單來(lái)說(shuō)驶社,這是個(gè)可以在同一個(gè) ZooKeeper Session 恢復(fù)的異常 (Recoverable), 但是應(yīng)用開(kāi)發(fā)者需要負(fù)責(zé)將應(yīng)用恢復(fù)到正確的狀態(tài)企量。發(fā)生這個(gè)異常的原因有很多,例如應(yīng)用機(jī)器與 ZooKeeper 節(jié)點(diǎn)之間網(wǎng)絡(luò)閃斷亡电,ZooKeeper 節(jié)點(diǎn)宕機(jī)届巩,服務(wù)端 Full GC 時(shí)間超長(zhǎng),甚至你的應(yīng)用進(jìn)程 Hang 死逊抡,應(yīng)用進(jìn)程 Full GC 時(shí)間超長(zhǎng)之后恢復(fù)都有可能姆泻。要理解這個(gè)異常,需要了解分布式應(yīng)用中的一個(gè)典型的問(wèn)題冒嫡,如下圖:
- ConnectionLossException 和 Disconnected 事件
在一個(gè)典型的客戶端請(qǐng)求、服務(wù)端響應(yīng)中四苇,當(dāng)它們之間的長(zhǎng)連接閃斷的時(shí)候孝凌,客戶端感知到這個(gè)閃斷事件的時(shí)候,會(huì)處在一個(gè)比較尷尬的境地月腋,那就是無(wú)法確定該事件發(fā)生時(shí)附近的那個(gè)請(qǐng)求到底處在什么狀態(tài)蟀架,Server 端到底收到這個(gè)請(qǐng)求了么?已經(jīng)處理了么榆骚?因?yàn)闊o(wú)法確定這一點(diǎn)片拍,所以當(dāng)客戶端重新連接上 Server 之后,這個(gè)請(qǐng)求是否應(yīng)該重試(Retry)就也要打一個(gè)問(wèn)號(hào)妓肢。
我們阿里巴巴的小伙伴在自行嘗試使用 ZooKeeper 做服務(wù)發(fā)現(xiàn)的過(guò)程中性宏,曾經(jīng)在我們的內(nèi)網(wǎng)技術(shù)論壇上總結(jié)過(guò)一篇自己踩坑的經(jīng)驗(yàn)分享所以在處理連接斷開(kāi)事件中捌省,應(yīng)用開(kāi)發(fā)者必須清楚處于閃斷附近的那個(gè)請(qǐng)求是什么(這常常難以判斷),該請(qǐng)求是否是冪等的碉钠,對(duì)于業(yè)務(wù)請(qǐng)求在 Server 端服務(wù)處理上對(duì)于"僅處理一次" "最多處理一次" "最少處理一次"語(yǔ)義要有選擇和預(yù)期纲缓。舉個(gè)例子,如果應(yīng)用在收到 ConnectionLossException 時(shí)喊废,之前的請(qǐng)求是 Create 操作祝高,那么應(yīng)用的 catch 到這個(gè)異常,應(yīng)用一個(gè)可能的恢復(fù)邏輯就是污筷,判斷之前請(qǐng)求創(chuàng)建的節(jié)點(diǎn)的是否已經(jīng)存在了工闺,如果存在就不要再創(chuàng)建了,否則就創(chuàng)建瓣蛀。再比如陆蟆,如果應(yīng)用使用了 exists Watch 去監(jiān)聽(tīng)一個(gè)不存在的節(jié)點(diǎn)的創(chuàng)建的事件,那么在 ConnectionLossException 的期間揪惦,有可能遇到的情況是遍搞,在這個(gè)閃斷期間,其它的客戶端進(jìn)程可能已經(jīng)創(chuàng)建了節(jié)點(diǎn)器腋,并且又已經(jīng)刪除了溪猿,那么對(duì)于當(dāng)前應(yīng)用來(lái)說(shuō)钩杰,就 miss 了一次關(guān)心的節(jié)點(diǎn)的創(chuàng)建事件,這種 miss 對(duì)應(yīng)用的影響是什么诊县?是可以忍受的還是不可接受讲弄?需要應(yīng)用開(kāi)發(fā)者自己根據(jù)業(yè)務(wù)語(yǔ)義去評(píng)估和處理。
- SessionExpiredException 和 SessionExpired 事件
Session 超時(shí)是一個(gè)不可恢復(fù)的異常依痊,這是指應(yīng)用 Catch 到這個(gè)異常的時(shí)候避除,應(yīng)用不可能在同一個(gè) Session 中恢復(fù)應(yīng)用狀態(tài),必須要重新建立新 Session胸嘁,老 Session 關(guān)聯(lián)的臨時(shí)節(jié)點(diǎn)也可能已經(jīng)失效瓶摆,擁有的鎖可能已經(jīng)失效。...
在該文中中肯的提到:... 在編碼過(guò)程中發(fā)現(xiàn)很多可能存在的陷阱群井,毛估估,第一次使用 zk 來(lái)實(shí)現(xiàn)集群管理的人應(yīng)該有 80% 以上會(huì)掉坑毫胜,有些坑比較隱蔽书斜,在網(wǎng)絡(luò)問(wèn)題或者異常的場(chǎng)景時(shí)才會(huì)出現(xiàn),可能很長(zhǎng)一段時(shí)間才會(huì)暴露出來(lái) ...
在粗粒度分布式鎖秘蛔,分布式選主陨亡,主備高可用切換等不需要高 TPS 支持的場(chǎng)景下有不可替代的作用,而這些需求往往多集中在大數(shù)據(jù)深员、離線任務(wù)等相關(guān)的業(yè)務(wù)領(lǐng)域负蠕,因?yàn)榇髷?shù)據(jù)領(lǐng)域,講究分割數(shù)據(jù)集倦畅,并且大部分時(shí)間分任務(wù)多進(jìn)程 / 線程并行處理這些數(shù)據(jù)集遮糖,但是總是有一些點(diǎn)上需要將這些任務(wù)和進(jìn)程統(tǒng)一協(xié)調(diào),這時(shí)候就是 ZooKeeper 發(fā)揮巨大作用的用武之地叠赐。但是在交易場(chǎng)景交易鏈路上欲账,在主業(yè)務(wù)數(shù)據(jù)存取屡江,大規(guī)模服務(wù)發(fā)現(xiàn)、大規(guī)模健康監(jiān)測(cè)等方面有天然的短板赛不,應(yīng)該竭力避免在這些場(chǎng)景下引入 ZooKeeper惩嘉,在阿里巴巴的生產(chǎn)實(shí)踐中,應(yīng)用對(duì) ZooKeeper 申請(qǐng)使用的時(shí)候要進(jìn)行嚴(yán)格的場(chǎng)景踢故、容量文黎、SLA 需求的評(píng)估。所以可以使用 ZooKeeper殿较,但是大數(shù)據(jù)請(qǐng)向左耸峭,而交易則向右,分布式協(xié)調(diào)向左淋纲,服務(wù)發(fā)現(xiàn)向右抓艳。寫(xiě)在最后感謝你耐心的閱讀到這里,至此帚戳,我相信你已經(jīng)理解,我們寫(xiě)這篇文章并不是全盤(pán)否定 ZooKeeper儡首,而只是根據(jù)我們阿里巴巴近 10 年來(lái)在大規(guī)模服務(wù)化上的生產(chǎn)實(shí)踐片任,對(duì)我們?cè)诜?wù)發(fā)現(xiàn)和注冊(cè)中心設(shè)計(jì)及使用上的經(jīng)驗(yàn)教訓(xùn)進(jìn)行一個(gè)總結(jié),希望對(duì)業(yè)界就如何更好的使用 ZooKeeper蔬胯,如何更好的設(shè)計(jì)自己的服務(wù)注冊(cè)中心有所啟發(fā)和幫助对供。最后,條條大路通羅馬氛濒,衷心祝愿你的注冊(cè)中心直接就誕生在羅馬产场。