Dubbo中的一些常見問題?

2021-08-11 05:31:51 字數 1404 閱讀 5622

關於dubbo是用的什麼協議?

在使用dubbo的時候會配置

所以再回答面試官的時候就隨口說的是

dubbo協議

,其實面試官問的此協議非彼協議,而是問的是http協議還是tcp協議,因為dubbo的核心就是用的單一長連線進行非同步通訊。

那問題來了為什麼要用dubbo進行資料傳輸?

一般服務端伺服器比較少,消費端有可能會有很多專案或者工程會呼叫dubbo的介面,而且資料量傳輸較小且併發量比較高的情況下用dubbo效率會很高。

tcp協議就是所謂的長連線

http協議呢就是所謂的短連線,經典的三次握手。

長連線的好處:

減少來回握手的頻率,當操作頻繁,點對點的通訊時,

可以同時傳送多個資料報,以不至於服務者被消費者壓死

dubbo中zookeeper做註冊中心,如果註冊中心集群都掛掉,發布者和訂閱者之間還能通訊麼?可以

1.啟動dubbo時,消費者會從zk拉取註冊的生產者的位址介面等資料,快取在本地。每次呼叫時,按照本地儲存的位址進行呼叫。

2.註冊中心對等集群,任意一台宕掉後,會自動切換到另一台 。

3.註冊中心全部宕掉,服務提供者和消費者仍可以通過本地快取通訊 。

4.服務提供者無狀態,任一台 宕機後,不影響使用 。

5.服務提供者全部宕機,服務消費者會無法使用,並無限次重連等待服務者恢復 。

2、dubbo連線註冊中心和直連的區別 ?

在開發及測試環境下,經常需要繞過註冊中心,只測試指定服務提供者,這時候可能需要點對點直連, 點對點直聯方式,將以服務介面為單位,忽略註冊中心的提供者列表,

服務註冊中心,動態的註冊和發現服務,使服務的位置透明,並通過在消費方獲取服務提供方位址列表,實現軟負載均衡和failover, 註冊中心返回服務提供者位址列表給消費者,如果有變更,註冊中心將基於長連線推送變更資料給消費者。 

服務消費者,從提供者位址列表中,基於軟負載均衡演算法,選一台提供者進行呼叫,如果呼叫失敗,再選另一台呼叫。註冊中心負責服務位址的註冊與查詢,相當於目錄服務,服務提供者和消費者只在啟動時與註冊中心互動,註冊中心不**請求,服務消費者向註冊中心獲取服務提供者位址列表,並根據負載演算法直接呼叫提供者,註冊中心,服務提供者,服務消費者三者之間均為長連線,監控中心除外,註冊中心通過長連線感知服務提供者的存在,服務提供者宕機,註冊中心將立即推送事件通知消費者,註冊中心和監控中心全部宕機,不影響已執行的提供者和消費者,消費者在本地快取了提供者列表,註冊中心和監控中心都是可選的,服務消費者可以直連服務提供者

3、dubbo在安全機制方面是如何解決的 ?

dubbo通過token令牌防止使用者繞過註冊中心直連,然後在註冊中心上管理授權。dubbo還提供服務黑白名單,來控**務所允許的呼叫方。

dedecms一些常見問題

1 list和arclist的區別 首頁的列表呼叫,以及其它內頁的側邊欄,這些地方都可以使用arclist標籤,並且還可以根據typeid id 來指定呼叫哪個欄目下的列表 list 標籤還有乙個不同處就是分頁,我們知道在 製作中分頁功能是 欄目列表頁必不可少的乙個功能,而這個功能用arclist標...

Redis一些常見問題

1.多個系統同時併發競爭乙個key zookeeper分布式鎖 儲存到mysql的時候帶有時間戳 這樣redis裡面存的也有時間戳了 2.redis執行緒模型 核心操作模組 如網路請求模組 由單執行緒完成,當然另外還有一些 輔助線程 從旁協助,比如 lru 的淘汰過程。為什麼之前網路請求模組為什麼沒...

ubuntu的一些常見問題

但是我操作上出現問題,執行命令cp libflashplayer.so usr bin forefox,結果就悲劇了,firefox啟動不了。解決方式 適用了下把firefox的檔案copy到usr bin目錄下,但是不成功,所以就解除安裝了firefox,又裝了一遍。sudo apt get re...