哈嘍!大家好,我是小奇,一位熱愛分享的程式設計師
小奇打算以輕鬆幽默的對話方式來分享一些技術,如果你覺得通過小奇的文章學到了東西,那就給小奇一個贊吧
文章持續更新
書接上回,今天還是過週末,雖然不上班,但是週末得正常過呀,今天依舊躺在我家祖傳的土炕上躺平。
哎,啥時候能老婆孩子熱炕頭啊,現在自己睡覺怪冷的(還得添把柴)。。。
算了,不想這有的沒的了,一切隨緣吧,是在不行就讓劉嬸給我說媒。。。先燒火做飯吧
就在我燒火的時候我的手機突然響了。
我:「喂您好」。
對面:「您好,請問是小奇嗎」。
我:「是我,你是?」。
對面:「我是XXX公司的,我看到hr推給我你的簡歷,我感覺還不錯,你什麼時候方便來現場面試一下」。
我:「現在不方便現場面試了」。
對面:「好吧,那你現在方便嗎?我們現線上上面試一下吧」。
我:「好的」。
面試官:我看你簡歷上寫的精通Dubbo,那你能說一下Dubbo是什麼嗎?
我:Dubbo最開始是一款RPC框架,隨著功能越來越完善,現在Dubbo是一款Java服務架構。
面試官:嗯,既然你說到了RPC,那麼他是什麼呢?
我:RPC是遠端過程呼叫,RPC同時也是一種計算機通訊協定,他可以從A機器呼叫B機器的程式,呼叫的時候就類似於呼叫本地程式一樣方便。
面試官:嗯,那你說一下Dubbo都有哪些特性吧?
Dubbo具有負載均衡、服務超時處理、叢集容錯、服務降級、本地存根、本地偽裝、引數回撥、非同步呼叫等特性。
面試官:嗯,那你說一下Dubbo的負載均衡是怎麼實現的吧?
我:在Dubbo中,消費者呼叫服務者的時候會記錄服務者的active,比如現在有一個消費者,有A、B兩個服務者。
當消費者向A服務傳送一條訊息的時候,消費者自身會記錄A服務的active會加1,當消費者接收到服務者A的相應結果後會將A服務的active減1。
而在消費者選擇使用哪個服務者的時候正是根據每個服務者active的大小來判斷的,首先選擇active小的來呼叫。
面試官:嗯,那你說一下Dubbo服務超時怎麼設定吧,有什麼要注意的嗎?
Dubbo可以在消費者和伺服器端都設定超時時間,消費者的超時時間是消費者發出訊息後到消費者接收到訊息的時間。
伺服器端的超時時間是伺服器端接收訊息後到處理完畢後發出的時間。
需要注意的是消費端的時間儘量設定的要比伺服器端的時間要長,因為如果消費端設定的是2秒,伺服器端設定的是5秒,而服務執行就需要3秒,那麼消費端肯定是超時了,但是這個時候伺服器端並沒有超時,不會發生異常。
面試官:嗯,那你說一下Dubbo的叢集容錯吧?
叢集容錯是伺服器端有多個提供者,他們構成叢集,當消費者呼叫伺服器端的時候伺服器端通過負載均衡策略選出一個提供者來提供服務,當呼叫這個服務者發生錯誤的時候,Dubbo後續採取了一系列策略。
Dubbo提供了多種叢集容錯模式。
Failover Cluster:失敗自動切換,當出現失敗,重試其它伺服器。通常用於讀操作,但重試會帶來更長延遲。可通過 retries="2" 來設定重試次數(不含第一次)。
Failfast Cluster:快速失敗,只發起一次呼叫,失敗立即報錯。通常用於非冪等性的寫操作,比如新增記錄。
Failsafe Cluster :失敗安全,出現異常時,直接忽略。通常用於寫入審計紀錄檔等操作。
Failback Cluster:失敗自動恢復,後臺記錄失敗請求,定時重發。通常用於訊息通知操作。
Forking Cluster:並行呼叫多個伺服器,只要一個成功即返回。通常用於實時性要求較高的讀操作,但需要浪費更多服務資源。可通過 forks="2" 來設定最大並行數。
Broadcast Cluster:廣播呼叫所有提供者,逐個呼叫,任意一臺報錯則報錯。通常用於通知所有提供者更新快取或紀錄檔等本地資源資訊。
面試官:「小夥子不錯呀,什麼時候能回北京入職呢」
我:「額。。。等等吧,現在還有好多家公司等著談薪資呢,我得挑一家合適的。」
面試官:「你要多少我都給你,來我這吧」
我:「額。。。那就月薪100個W吧」。
面試官:「喂,你說什麼我聽不見,訊號不好。。。」
我:「喂喂喂」(嘟嘟嘟嘟嘟嘟嘟嘟。。。)。
這裡的相關內容還沒有整理完畢,文章後面持續更新,建議收藏。
文章中涉及到的命令大家一定要像我一樣每個都敲幾遍,只有在敲的過程中才能發現自己對命令是否真正的掌握了。
如果覺得我的文章還不錯的話就點個贊吧