Eureka, Client, Ribbon之間的緩存和服務實時上下線實現(xiàn)思路分析

在使用Eureka做注冊中心時挫掏,我平時遇到的最不爽問題,就是無法做到實時上下線秩命。比如尉共,我服務已經正常下線了,為什么上游還能調通弃锐?我服務已經上線了袄友,為什么還有等"很久"才能真正被其他服務所"發(fā)現(xiàn)"?其實這些都是從Eureka到Client再到Ribbion這條鏈路中的逐級緩存造成的霹菊。

Eureka為什么要使用緩存

比如剧蚣,對于Eureka來說,Eureka Client獲取注冊更新信息時,Eureka Server返回的數(shù)據(jù)其實是從一個默認每30s才更新的緩存獲取的券敌。也就是說,如果你服務下了一個柳洋,即使client是在服務下線之后發(fā)請求查詢的注冊列表待诅,那這次請求也不會包括服務下線的信息。那么Eureka為什么要搞cache而不是實時的返回注冊信息呢熊镣?我個人推測了一下卑雁,應該是為了在訪問注冊數(shù)據(jù)結構時盡量少加鎖,從而提升單次請求時的性能绪囱。如果沒有這層cache, 那么對于服務注冊表這個數(shù)據(jù)結構來說测蹲,就會存在并發(fā)讀寫的情況,那就避免不了加鎖保護鬼吵。如果有cache, 是可以做到完全不加鎖的扣甲。想一下,對于微服務架構來說齿椅,特點就是每個服務較輕琉挖,但服務數(shù)量較多。如果每個服務都定時請求eureka更新注冊信息的話涣脚,對于Eureka Server來說示辈,確實是可能會造成嚴重的鎖競爭的。除了這個responseCache外遣蚀,Eureka對于無心跳服務的清理也是默認每60s執(zhí)行一次的矾麻,也就是說對于異常下線的服務(沒有主動取消注冊,而是中斷了心跳)芭梯,在Eureka Server端最大會有長達 60s + 30s * 3 = 150s的延遲险耀。這里的30s * 3 是3個心跳的周期。

Eureka Client的緩存

Eureka Client默認會對注冊信息做30s緩存 玖喘,這個很好理解 胰耗,因為我們當然不希望每次RPC都要重新查一次注冊表,這是很浪費的芒涡。?這是常規(guī)操作柴灯,無可厚非。

Ribbon的緩存

這就有點詭異了费尽。Ribbon向上對接Eureka Client, 向下對接實現(xiàn)發(fā)起HTTP請求的客戶端赠群。ribbon自身也是有30s緩存的,即ribbon會每30s向Eureka Client那里索要注冊信息旱幼,注意是Eureka Client而不是Eureka Server查描,這樣就更加劇了整個系統(tǒng)對服務上下線感知的延遲。我認為Ribbon這樣設計,原因是考慮到了其上游不僅僅是Eureka Client, 還可能是配置文件冬三,或者以編程的方式輸入的注冊列表匀油,而這些查詢是有可能比較耗時的。Ribbon為了兼容這些情況勾笆,不得不添加了緩存敌蚜。

實時上下線思路

只能用消息中間件了。新做一個上下線管理服務窝爪,提供HTTP接口來上下線指定服務弛车,當指定要下線A服務時,先向Eureka發(fā)請求蒲每,將此服務下所有的實例都刪掉纷跛,然后再向kafka類似這樣的消息系統(tǒng)中發(fā)一條消息,所有的微服務都要監(jiān)聽此消息隊列邀杏。

服務收到下線消息時贫奠,將指定服務從本地Ribbon服務列表中刪除。這里Ribbon的 Loadbalancer提供了markServerDown()方法可以使用望蜡,還是容易實現(xiàn)的叮阅。

服務收到上線消息時,需要將服務信息添加到Ribbon中泣特,Ribbon雖然也提供了對應的方法浩姥,但是參數(shù)較為復雜,還需要研究一下状您。

這些功能可以直接打包成starter, 寫好以后各服務直接引用即可勒叠。


2、Eureka Server端優(yōu)秀的多級緩存機制

? ?eureka為了避免同時讀寫內存數(shù)據(jù)結構造成的并發(fā)沖突問題采用了多級緩存的機制:

在拉取注冊表時會首從readonlyCacheMap緩存里查找膏孟,如果沒有再從readWriteCacheMap查找眯分,要是還沒有找到就直接從內存找。 當注冊表發(fā)生改變時柒桑,直接修改內存中的注冊表同時會過濾掉readWriteCacheMap弊决,但readonlyCacheMap不會進行過濾還可以訪問,當?shù)竭_30秒過后后臺線程發(fā)現(xiàn)readWriteCacheMap被清空了魁淳,同時也會清空readonlyCacheMap飘诗。當下個請求進行訪問readonlyCacheMap和readWriteCacheMap會重新從最新的內存注冊表過更新數(shù)據(jù),又達到了一致性界逛。

總結:Eureka同時通過純內存的注冊表昆稿,保證了所有的請求都可以在內存處理,確保了極高的性能息拜,另外多級緩存機制溉潭,確保了不會針對內存數(shù)據(jù)結構發(fā)生頻繁的讀寫并發(fā)沖突操作净响,進一步提升性能。

原文鏈接:https://blog.csdn.net/neosmith/article/details/90213156

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯(lián)系作者
  • 序言:七十年代末喳瓣,一起剝皮案震驚了整個濱河市馋贤,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌畏陕,老刑警劉巖配乓,帶你破解...
    沈念sama閱讀 222,946評論 6 518
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異蹭秋,居然都是意外死亡扰付,警方通過查閱死者的電腦和手機堤撵,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 95,336評論 3 399
  • 文/潘曉璐 我一進店門仁讨,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人实昨,你說我怎么就攤上這事洞豁。” “怎么了荒给?”我有些...
    開封第一講書人閱讀 169,716評論 0 364
  • 文/不壞的土叔 我叫張陵丈挟,是天一觀的道長。 經常有香客問我志电,道長曙咽,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 60,222評論 1 300
  • 正文 為了忘掉前任挑辆,我火速辦了婚禮例朱,結果婚禮上,老公的妹妹穿的比我還像新娘鱼蝉。我一直安慰自己洒嗤,他們只是感情好,可當我...
    茶點故事閱讀 69,223評論 6 398
  • 文/花漫 我一把揭開白布魁亦。 她就那樣靜靜地躺著渔隶,像睡著了一般。 火紅的嫁衣襯著肌膚如雪洁奈。 梳的紋絲不亂的頭發(fā)上间唉,一...
    開封第一講書人閱讀 52,807評論 1 314
  • 那天,我揣著相機與錄音利术,去河邊找鬼终吼。 笑死,一個胖子當著我的面吹牛氯哮,可吹牛的內容都是我干的际跪。 我是一名探鬼主播商佛,決...
    沈念sama閱讀 41,235評論 3 424
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼姆打!你這毒婦竟也來了良姆?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 40,189評論 0 277
  • 序言:老撾萬榮一對情侶失蹤幔戏,失蹤者是張志新(化名)和其女友劉穎玛追,沒想到半個月后,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體闲延,經...
    沈念sama閱讀 46,712評論 1 320
  • 正文 獨居荒郊野嶺守林人離奇死亡痊剖,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 38,775評論 3 343
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現(xiàn)自己被綠了垒玲。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片陆馁。...
    茶點故事閱讀 40,926評論 1 353
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖合愈,靈堂內的尸體忽然破棺而出叮贩,到底是詐尸還是另有隱情,我是刑警寧澤佛析,帶...
    沈念sama閱讀 36,580評論 5 351
  • 正文 年R本政府宣布益老,位于F島的核電站,受9級特大地震影響寸莫,放射性物質發(fā)生泄漏捺萌。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 42,259評論 3 336
  • 文/蒙蒙 一膘茎、第九天 我趴在偏房一處隱蔽的房頂上張望桃纯。 院中可真熱鬧,春花似錦辽狈、人聲如沸慈参。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,750評論 0 25
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽驮配。三九已至,卻和暖如春着茸,著一層夾襖步出監(jiān)牢的瞬間壮锻,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 33,867評論 1 274
  • 我被黑心中介騙來泰國打工涮阔, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留猜绣,地道東北人。 一個月前我還...
    沈念sama閱讀 49,368評論 3 379
  • 正文 我出身青樓敬特,卻偏偏與公主長得像掰邢,于是被迫代替她去往敵國和親牺陶。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 45,930評論 2 361

推薦閱讀更多精彩內容