Dubbo面試題及答案【傳智播客】

【面試題1】Dubbo支持的協(xié)議

dubbo(默認(rèn))：單一長連接和NIO異步通訊，適合大并發(fā)小數(shù)據(jù)量的服務(wù)調(diào)用，以及消費者遠(yuǎn)大于提供者。傳輸協(xié)議 TCP，異步，Hessian 序列化;

rmi：采用JDK標(biāo)準(zhǔn)的rmi協(xié)議實現(xiàn)，傳輸參數(shù)和返回參數(shù)對象需要實現(xiàn)Serializable接口，使用java標(biāo)準(zhǔn)序列化機制，使用阻塞式短連接，傳輸數(shù)據(jù)包大小混合，消費者和提供者個數(shù)差不多，可傳文件，傳輸協(xié)議 TCP。多個短連接，TCP 協(xié)議傳輸，同步傳輸，適用常規(guī)的遠(yuǎn)程服務(wù)調(diào)用和 rmi 互操作。在依賴低版本的 Common-Collections包，java 序列化存在安全漏洞;

webservice：基于 WebService 的遠(yuǎn)程調(diào)用協(xié)議，集成 CXF 實現(xiàn)，提供和原生 WebService 的互操作。多個短連接，基于 HTTP 傳輸，同步傳輸，適用系統(tǒng)集成和跨語言調(diào)用;

http：基于 Http 表單提交的遠(yuǎn)程調(diào)用協(xié)議，使用Spring的HttpInvoke 實現(xiàn)。多個短連接，傳輸協(xié)議 HTTP，傳入?yún)?shù)大小混合，提供者個數(shù)多于消費者，需要給應(yīng)用程序和瀏覽器 JS 調(diào)用;

hessian：集成Hessian 服務(wù)，基于HTTP通訊，采用Servlet暴露服務(wù)，Dubbo 內(nèi)嵌 Jetty 作為服務(wù)器時默認(rèn)實現(xiàn)，提供與Hession服務(wù)互操作。多個短連接，同步 HTTP 傳輸，Hessian 序列化，傳入?yún)?shù)較大，提供者大于消費者，提供者壓力較大，可傳文件;

memcache： 基于memcached實現(xiàn)的RPC協(xié)議

傳入傳出參數(shù)數(shù)據(jù)包較小(建議小于100K)，消費者比提供者個數(shù)多，單一消費者無法壓滿提供者，盡量不要用dubbo協(xié)議傳輸大文件或超大字符串。

redis： 基于redis實現(xiàn)的RPC協(xié)議

【面試題2】Dubbo推薦用什么協(xié)議?使用該協(xié)議有哪些優(yōu)缺點?

傳入傳出參數(shù)數(shù)據(jù)包較小(建議小于100K)，消費者比提供者個數(shù)多，單一消費者無法壓滿提供者，盡量不要用dubbo協(xié)議傳輸大文件或超大字符串。

【面試題3】Dubbo超時時間的設(shè)置

通過timeout屬性配置超時時間,服務(wù)的提供者和消費者都可以配置，盡量在服務(wù)提供者中配置，因為服務(wù)的提供者會對自己提供的服務(wù)情況更清楚超時時間不要設(shè)置太大(1~5S),會影響并發(fā)性能問題。

【面試題4】Dubbo自動重試機

Dubbo在調(diào)用服務(wù)不成功時，默認(rèn)會重試2次。Dubbo的路由機制，會把超時的請求路由到其他機器上，而不是本機嘗試，所以 dubbo的重試機制也能一定程度的保證服務(wù)的質(zhì)量

【面試題5】Dubbo支持的注冊中心

Multicast 注冊中心

Multicast 注冊中心不需要任何中心節(jié)點，只要廣播地址，就能進行服務(wù)注冊和發(fā)現(xiàn)?；诰W(wǎng)絡(luò)中組播傳輸實現(xiàn)

Zookeeper 注冊中心

基于分布式協(xié)調(diào)系統(tǒng) Zookeeper 實現(xiàn)，采用Zookeeper 的 watch 機制實現(xiàn)數(shù)據(jù)變更

redis 注冊中心

基于redis實現(xiàn)，采用key/Map存儲，住key存儲服務(wù)名和類型，Map中key存儲服務(wù)URL，value 服務(wù)過期時間。基于redis 的發(fā)布/訂閱模式通知數(shù)據(jù)變更;

【面試題6】Dubbo集群的負(fù)載均衡策略

隨機

按權(quán)重設(shè)置隨機概率。在一個截面上碰撞的概率高，但調(diào)用量越大分布越均勻，而且按概率使用權(quán)重后也比較均勻，有利于動態(tài)調(diào)整提供者權(quán)重。(權(quán)重可以在dubbo管控臺配置)

輪循

按公約后的權(quán)重設(shè)置輪循比率。存在慢的提供者累積請求問題，比如：第二臺機器很慢，但沒掛，當(dāng)請求調(diào)到第二臺時就卡在那，久而久之，所有請求都卡在調(diào)到第二臺上。

最少活躍調(diào)用數(shù)

相同活躍數(shù)的隨機，活躍數(shù)指調(diào)用前后計數(shù)差。使慢的提供者收到更少請求，因為越慢的提供者的調(diào)用前后計數(shù)差會越大。

一致性Hash

相同參數(shù)的請求總是發(fā)到同一提供者。當(dāng)某一臺提供者掛時，原本發(fā)往該提供者的請求，基于虛擬節(jié)點，平攤到其它提供者，不會引起劇烈變動。

【面試題7】Dubbo支持哪些序列化方式?

dubbo序列化：阿里尚未開發(fā)成熟的高效java序列化實現(xiàn)，阿里不建議在生產(chǎn)環(huán)境使用它

hessian2序列化(默認(rèn)推薦)：hessian是一種跨語言的高效二進制序列化方式。但這里實際不是原生的hessian2序列化，而是阿里修改過的hessian lite，它是dubbo RPC默認(rèn)啟用的序列化方式

json序列化：目前有兩種實現(xiàn)，一種是采用的阿里的fastjson庫，另一種是采用dubbo中自己實現(xiàn)的簡單json庫，但其實現(xiàn)都不是特別成熟，而且json這種文本序列化性能一般不如上面兩種二進制序列化。

java序列化：主要是采用JDK自帶的Java序列化實現(xiàn)，性能很不理想。

【面試題8】注冊中心宕機，服務(wù)間是否可以繼續(xù)通信

可以通信的，啟動dubbo時，消費者會從zk拉取注冊的生產(chǎn)者的地址接口等數(shù)據(jù)，緩存在本地。每次調(diào)用時，按照本地存儲的地址進行調(diào)用;

但前提是你沒有增加新的服務(wù)，如果你要調(diào)用新的服務(wù)，則是不能辦到的。

另外如果服務(wù)的提供者全部宕機，服務(wù)消費者會無法使用，并無限次重連等待服務(wù)者恢復(fù);

【面試題9】Dubbo與spring的關(guān)系

Dubbo采用全Spring 配置方式，透明化接入應(yīng)用，對應(yīng)用沒有任何API 侵入，只需用Spring加載Dubbo的配置即可。

【面試題10】Dubbo使用的是什么通信框架?

NIO Netty框架

【面試題11】Dubbo的集群容錯方案

Failover Cluster(默認(rèn)):

失敗自動切換，當(dāng)出現(xiàn)失敗，重試其它服務(wù)器。通常用于讀操作，但重試會帶來更長延遲。

Failfast Cluster

快速失敗，只發(fā)起一次調(diào)用，失敗立即報錯。通常用于非冪等性的寫操作，比如新增記錄。

Failsafe Cluster

失敗安全，出現(xiàn)異常時，直接忽略。通常用于寫入審計日志等操作。

Failback Cluster

失敗自動恢復(fù)，后臺記錄失敗請求，定時重發(fā)。通常用于消息通知操作。

Forking Cluster

并行調(diào)用多個服務(wù)器，只要一個成功即返回。通常用于實時性要求較高的讀操作，但需要浪費更多服務(wù)資源?？赏ㄟ^ forks="2" 來設(shè)置最大并行數(shù)。

Broadcast Cluster

廣播調(diào)用所有提供者，逐個調(diào)用，任意一臺報錯則報錯 。通常用于通知所有提供者更新緩存或日志等本地資源信息。

【面試題12】Dubbo 和 Spring Cloud 的關(guān)系?

Dubbo 是 SOA 時代的產(chǎn)物，它的關(guān)注點主要在于服務(wù)的調(diào)用，流量分發(fā)、流量監(jiān)控和熔斷。而 Spring Cloud 誕生于微服務(wù)架構(gòu)時代，考慮的是微服務(wù)治理的方方面面，另外由于依托了 Spirng、Spirng Boot 的優(yōu)勢之上，兩個框架在開始目標(biāo)就不一致，Dubbo定位服務(wù)治理、Spirng Cloud 是一個生態(tài)。最大的區(qū)別：Dubbo 底層是使用 Netty 這樣的 NIO 框架，是基于TCP 協(xié)議傳輸?shù)?，配合?Hession 序列化完成 RPC 通信。而 SpringCloud 是基于 Http 協(xié)議+Rest 接口調(diào)用遠(yuǎn)程過程的通信，相對來說，Http 請求會有更大的報文，占的帶寬也會更多。但是REST相比RPC更為靈活，服務(wù)提供方和調(diào)用方的依賴只依靠一紙契約，不存在代碼級別的強依賴。


猜你喜歡：

Java面試題及答案最新匯總 

Java中Sleep和Wait有什么區(qū)別? 

Hashmap與Hashtable有什么區(qū)別?

Java高級軟件工程師課程