摘要:的上有一句話,大意是一個服務啟動后最長可能需要分鐘時間才能被其它服務感知到,但是文檔并沒有解釋為什么會有這分鐘。其實這是由三處緩存一處延遲造成的。對此做了修改,服務啟動后會馬上注冊以上這四個秒正是官方上寫服務注冊最長需要分鐘的原因。
Eureka的wiki上有一句話,大意是一個服務啟動后最長可能需要2分鐘時間才能被其它服務感知到,但是文檔并沒有解釋為什么會有這2分鐘。其實這是由三處緩存 + 一處延遲造成的。
首先,Eureka對HTTP響應做了緩存。在Eureka的”控制器”類ApplicationResource的109行可以看到有一行
String payLoad = responseCache.get(cacheKey);
的調用,該代碼所在的getApplication()方法的功能是響應客戶端查詢某個服務信息的HTTP請求:
String payLoad = responseCache.get(cacheKey); // 從cache中拿響應數據 if (payLoad != null) { logger.debug("Found: {}", appName); return Response.ok(payLoad).build(); } else { logger.debug("Not Found: {}", appName); return Response.status(Status.NOT_FOUND).build(); }
上面的代碼中,responseCache引用的是ResponseCache類型,該類型是一個接口,其get()方法首先會去緩存中查詢數據,如果沒有則生成數據返回(即真正去查詢注冊列表),且緩存的有效時間為30s。也就是說,客戶端拿到Eureka的響應并不一定是即時的,大部分時候只是緩存信息。
其次,Eureka Client對已經獲取到的注冊信息也做了30s緩存。即服務通過eureka客戶端第一次查詢到可用服務地址后會將結果緩存,下次再調用時就不會真正向Eureka發起HTTP請求了。
再次, 負載均衡組件Ribbon也有30s緩存。Ribbon會從上面提到的Eureka Client獲取服務列表,然后將結果緩存30s。
最后,如果你并不是在Spring Cloud環境下使用這些組件(Eureka, Ribbon),你的服務啟動后并不會馬上向Eureka注冊,而是需要等到第一次發送心跳請求時才會注冊。心跳請求的發送間隔也是30s。(Spring Cloud對此做了修改,服務啟動后會馬上注冊)
以上這四個30秒正是官方wiki上寫服務注冊最長需要2分鐘的原因。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/72034.html
摘要:和二級緩存影響狀態更新,縮短這兩個定時任務周期可減少滯后時間,例如配置更新周期更新周期服務提供者保證服務正常下線。服務提供者延遲下線。 引言 Eureka是Netflix開源的、用于實現服務注冊和發現的服務。Spring Cloud Eureka基于Eureka進行二次封裝,增加了更人性化的UI,使用更為方便。但是由于Eureka本身存在較多緩存,服務狀態更新滯后,最常見的狀況是:服務...
摘要:大家好,我是悟空呀上兩篇講解源碼的文章過于硬核領導讓我研究源碼啟動過程領導叕讓我研究源碼注冊過程本篇將會給大家講解我在本地搭建的集群環境下,控制臺的參數說明。目前悟空我的機器上顯示的個。悟空我的本機是往進行注冊了。 大家好,我是悟空呀~上兩篇講解 Eureka 源碼的文章過于硬核:領導讓我研究 Eureka 源...
摘要:所以通過設置一個適中的拉取注冊表以及發送心跳的頻率,保證大規模系統里對的請求壓力不會太大。在注冊表發生變更的時候會在內存中更新變更的注冊表數據,同時過期掉。上述就是架構中,作為微服務注冊中心可以承載大規模系統每天千萬級訪問量的原理。 歡迎關注微信公眾號:石杉的架構筆記 周一至周五早8點!精品技術文章準時送上!! 往期文章1.拜托!面試請不要再問我Spring Cloud底層原理! 目...
摘要:所以通過設置一個適中的拉取注冊表以及發送心跳的頻率,保證大規模系統里對的請求壓力不會太大。在注冊表發生變更的時候會在內存中更新變更的注冊表數據,同時過期掉。上述就是架構中,作為微服務注冊中心可以承載大規模系統每天千萬級訪問量的原理。 歡迎關注微信公眾號:石杉的架構筆記 周一至周五早8點!精品技術文章準時送上!! 往期文章1.拜托!面試請不要再問我Spring Cloud底層原理! 目...
摘要:上篇文章緩存機制介紹了的緩存機制,相信大家對有了進一步的了解,本文將詳細介紹網關如何實現服務下線的實時感知。目前網關實現的是對網關下游服務的實時感知,而且需滿足以下條件生產者需部署在容器管理平臺生產者做正常的下線升級或者縮容操作。 上篇文章《Eureka 緩存機制》介紹了Eureka的緩存機制,相信大家對Eureka 有了進一步的了解,本文將詳細介紹API網關如何實現服務下線的實時感知...
閱讀 2158·2021-09-22 10:56
閱讀 1465·2021-09-07 10:11
閱讀 1800·2019-08-30 15:54
閱讀 2290·2019-08-30 15:44
閱讀 2307·2019-08-29 12:40
閱讀 3031·2019-08-28 18:25
閱讀 1735·2019-08-26 10:24
閱讀 3186·2019-08-23 18:39