110道 Dubbo面試題及答案(持續更新)


本人發現網上雖然有不少Dubbo面試題及答案,但第一未必全,第二未必有答案,第三雖然有答案,但未必能在面試中說,所以在本文里,會不斷收集各種面試題,並站在面試官的立場上,給出我自己的答案

如果不背 Dubbo面試題的答案,肯定面試會掛!

這套Dubbo面試題大全,希望對大家有幫助哈~

博主已將以下這些面試題整理成了一個Java面試手冊,是PDF版的

1、RPC框架需要解決的問題?

1、 如何確定客戶端和服務端之間的通信協議?

2、 如何更高效地進行網絡通信?

3、 服務端提供的服務如何暴露給客戶端?

4、 客戶端如何發現這些暴露的服務?

5、 如何更高效地對請求對象和響應結果進行序列化和反序列化操作?

2、Dubbo 支持哪些協議,每種協議的應用場景,優缺點?

1、 dubbo:單一長連接和 NIO 異步通訊,適合大並發小數據量的服務調用,以及消費者遠大於提供者。傳輸協議 TCP,異步, Hessian 序列化;

2、 rmi:采用 JDK 標准的 rmi 協議實現,傳輸參數和返回參數對象需要實現Serializable 接口,使用 java 標准序列化機制,使用阻塞式短連接,傳輸數據包大小混合,消費者和提供者個數差不多,可傳文件,傳輸協議 TCP。多個短連接, TCP 協議傳輸,同步傳輸,適用常規的遠程服務調用和 rmi 互操作。在依賴低版本的 Common-Collections 包, java 序列化存在安全漏洞;

3、 http:基於 Http 表單提交的遠程調用協議,使用 Spring 的 HttpInvoke 實現。多個短連接,傳輸協議 HTTP,傳入參數大小混合,提供者個數多於消費者,需要給應用程序和瀏覽器 JS 調用;

4、 webservice:基於 WebService 的遠程調用協議,集成 CXF 實現,提供和原生 WebService 的互操作。多個短連接,基於 HTTP 傳輸,同步傳輸,適用系統集成和跨語言調用;

5、 hessian:集成 Hessian 服務,基於 HTTP 通訊,采用 Servlet 暴露服務,Dubbo 內嵌 Jetty 作為服務器時默認實現,提供與 Hession 服務互操作。多個短連接,同步 HTTP 傳輸, Hessian 序列化,傳入參數較大,提供者大於消費者,提供者壓力較大,可傳文件;

6、 Redis:基於 Redis 實現的 RPC 協議

3、dubbo 通信協議 dubbo 協議為什么不能傳大包;

因 dubbo 協議采用單一長連接,如果每次請求的數據包大小為 500KByte,假設網絡為千兆網卡(1024Mbit=128MByte),每條連接最大 7MByte(不同的環境可能不一樣,供參考),單個服務提供者的 TPS(每秒處理事務數)最大為:128MByte / 500KByte = 262。

單個消費者調用單個服務提供者的 TPS(每秒處理事務數)最大為:7MByte / 500KByte = 14。

如果能接受,可以考慮使用,否則網絡將成為瓶頸。

4、一般使用什么注冊中心?還有別的選擇嗎?

推薦使用 Zookeeper 作為注冊中心,還有 Redis、Multicast、Simple 注冊中心,但不推薦。

5、Dubbo 在安全機制方面是如何解決的

Dubbo 通過 Token 令牌防止用戶繞過注冊中心直連,然后在注冊中心上管理授權。Dubbo 還提供服務黑白名單,來控制服務所允許的調用方。

6、Dubbo有哪幾種集群容錯方案,默認是哪種?

1、 Failover Cluster 失敗自動切換,自動重試其他服務器(默認)

2、 Failfast Cluster 快速失敗,立即報錯,只發起一次調用

3、 Failsafe Cluster 失敗安全,出現異常時,直接忽略

4、 Failback Cluster 失敗自動回復,記錄失敗請求,定時請求

5、 Forking Cluster 並行調用多個服務器,只要一個成功即返回

6、 Broadcast Cluster 廣播逐個調用所有提供者,任意一個報錯則報錯

7、Dubbo 支持哪些協議,每種協議的應用場景,優缺點?

1、 dubbo:單一長連接和 NIO 異步通訊,適合大並發小數據量的服務調用,以及消費者遠大於提供者。傳輸協議 TCP,異步, Hessian 序列化;

2、 rmi:采用 JDK 標准的 rmi 協議實現,傳輸參數和返回參數對象需要實現 Serializable 接口,使用 java 標准序列化機制,使用阻塞式短連接,傳輸數據包大小混合,消費者和提供者個數差不多,可傳文件,傳輸協議 TCP。多個短連接, TCP 協議傳輸,同步傳輸,適用常規的遠程服務調用和rmi 互操作。在依賴低版本的 Common-Collections包, java 序列化存在安全漏洞;

3、 webservice:基於 WebService 的遠程調用協議,集成 CXF 實現,提供和原生 WebService 的互操作。多個短連接,基於 HTTP 傳輸,同步傳輸,適用系統集成和跨語言調用;

4、 http:基於 Http 表單提交的遠程調用協議,使用 Spring 的HttpInvoke 實現。多個短連接,傳輸協議 HTTP,傳入參數大小混合,提供者個數多於消費者,需要給應用程序和瀏覽器 JS 調用;

5、 hessian:集成 Hessian 服務,基於 HTTP 通訊,采用 Servlet 暴露服務, Dubbo 內嵌 Jetty 作為服務器時默認實現,提供與 Hession 服務互操作。多個短連接,同步 HTTP 傳輸, Hessian 序列化,傳入參數較大,提供者大於消費者,提供者壓力較大,可傳文件;

6、 memcache:基於 Memcached 實現的 RPC 協議

7、 Redis:基於 Redis 實現的 RPC 協議

8、Dubbo 如何優雅停機?

Dubbo 是通過 JDK 的 ShutdownHook 來完成優雅停機的,所以如果使用 kill -9 PID 等強制關閉指令,是不會執行優雅停機的,只有通過 kill PID 時,才會執行。

9、RPC使用了哪些關鍵技術,從服務提供者的角度看:

當服務提供者啟動的時候,需要將自己提供的服務注冊到指定的注冊中心,以便服務消費者能夠通過服務注冊中心進行查找;

當服務提供者由於各種原因致使提供的服務停止時,需要向注冊中心注銷停止的服務;

服務的提供者需要定期向服務注冊中心發送心跳檢測,服務注冊中心如果一段時間未收到來自服務提供者的心跳后,認為該服務提供者已經停止服務,則將該服務從注冊中心上去掉。

10、注冊了多個同一樣的服務,如果測試指定的某一個服務呢?

可以配置環境點對點直連,繞過注冊中心,將以服務接口為單位,忽略注冊中心的提供者列表。

11、dubbo 推薦用什么協議?

默認使用 dubbo 協議

12、Dubbo 核心功能有哪些?

1、 Remoting:網絡通信框架,提供對多種NIO框架抽象封裝,包括“同步轉異步”和“請求-響應”模式的信息交換方式。

2、 Cluster:服務框架,提供基於接口方法的透明遠程過程調用,包括多協議支持,以及軟負載均衡,失敗容錯,地址路由,動態配置等集群支持。

3、 Registry:服務注冊,基於注冊中心目錄服務,使服務消費方能動態的查找服務提供方,使地址透明,使服務提供方可以平滑增加或減少機器。

13、dubbo 推薦用什么協議?

默認使用 dubbo 協議。

14、Dubbo 的主要應用場景?

1、 透明化的遠程方法調用,就像調用本地方法一樣調用遠程方法,只需簡單配置,沒有任何 API 侵入。

2、 軟負載均衡及容錯機制,可在內網替代 F5 等硬件負載均衡器,降低成本,減少單點。

3、 服務自動注冊與發現,不再需要寫死服務提供方地址,注冊中心基於接口名查詢服務提供者的 IP 地址,並且能夠平滑添加或刪除服務提供者。

Dubbo 的主要應用場景?

Dubbo 的核心功能?

主要就是如下 3 個核心功能:

1、 Remoting:網絡通信框架,提供對多種 NIO 框架抽象封裝,包括“同步轉異步”和“請求-響應”模式的信息交換方式。

2、 Cluster:服務框架,提供基於接口方法的透明遠程過程調用,包括多協議支持,以及軟負載均衡,失敗容錯,地址路由,動態配置等集群支持。

3、 Registry:服務注冊,基於注冊中心目錄服務,使服務消費方能動態的查找服務提供方,使地址透明,使服務提供方可以平滑增加或減少機器。

15、Dubbo服務之間的調用是阻塞的嗎?

默認是同步等待結果阻塞的,支持異步調用,Dubbo 是基於 NIO 的非阻塞實現並行調用,客戶端不需要啟動多線程即可完成並行調用多個遠程服務,相對多線程開銷較小,異步調用會返回一個 Future 對象。

16、dubbo 服務集群配置(集群容錯模式)

在集群調用失敗時, Dubbo 提供了多種容錯方案,缺省為 failover 重試。可以自行擴展集群容錯策略

l Failover Cluster(默認)

失敗自動切換,當出現失敗,重試其它服務器。(缺省)通常用於讀操作,

但重試會帶來更長延遲。可通過 retries="2"來設置重試次數(不含第一次)。

<dubbo:service retries="2" cluster="failover"/>或:<dubbo:reference retries="2" cluster="failover"/>cluster="failover"可以不用寫,因為默認就是 failover

Failfast Cluster

快速失敗,只發起一次調用,失敗立即報錯。通常用於非冪等性的寫操作,

比如新增記錄。

dubbo:service cluster="failfast" />

或:

<dubbo:reference cluster="failfast" /> cluster="failfast"和 把 cluster="failover"、 retries="0"是一樣的效果,retries="0"就是不重

Failsafe Cluster失敗安全,出現異常時,直接忽略。通常用於寫入審計日志等操作。

<dubbo:service cluster="failsafe" />

或:

<dubbo:reference cluster="failsafe" />

Failback Cluster

失敗自動恢復,后台記錄失敗請求,定時重發。通常用於消息通知操作。

<dubbo:service cluster="failback" />

或:

<dubbo:reference cluster="failback" />

Forking Cluster並行調用多個服務器,只要一個成功即返回。通常用於實時性要求較高的讀

操作,但需要浪費更多服務資源。可通過 forks="2"來設置最大並行數。

<dubbo:service cluster=“forking" forks="2"/>

或:

<dubbo:reference cluster=“forking" forks="2"/>

17、Dubbo 默認采用注冊中心?

采用 Zookeeper

18、Dubbo 支持服務降級嗎?

以通過 dubbo:reference 中設置 mock=“return null”。mock 的值也可以修改為 true,然后再跟接口同一個路徑下實現一個 Mock 類,命名規則是 “接口名稱+Mock” 后綴。然后在 Mock 類里實現自己的降級邏輯

19、RPC使用了哪些關鍵技術,主流RPC框架有哪些

20、Dubbo的管理控制台能做什么?

管理控制台主要包含:路由規則,動態配置,服務降級,訪問控制,權重調整,負載均衡,等管理功能

21、你覺得用 Dubbo 好還是 Spring Cloud 好?

擴展性的問題,沒有好壞,只有適合不適合,不過我好像更傾向於使用 Dubbo, Spring Cloud 版本升級太快,組件更新替換太頻繁,配置太繁瑣,還有很多我覺得是沒有 Dubbo 順手的地方。

22、Dubbo Monitor 實現原理?

Consumer端在發起調用之前會先走filter鏈;provider端在接收到請求時也是先走filter鏈,然后才進行真正的業務邏輯處理。

默認情況下,在consumer和provider的filter鏈中都會有Monitorfilter。

1、 MonitorFilter向DubboMonitor發送數據

2、 DubboMonitor將數據進行聚合后(默認聚合1min中的統計數據)暫存到ConcurrentMap<Statistics, AtomicReference> statisticsMap,然后使用一個含有3個線程(線程名字:DubboMonitorSendTimer)的線程池每隔1min鍾,調用SimpleMonitorService遍歷發送statisticsMap中的統計數據,每發送完畢一個,就重置當前的Statistics的AtomicReference

3、 SimpleMonitorService將這些聚合數據塞入BlockingQueue queue中(隊列大寫為100000)

4、 SimpleMonitorService使用一個后台線程(線程名為:DubboMonitorAsyncWriteLogThread)將queue中的數據寫入文件(該線程以死循環的形式來寫)

5、 SimpleMonitorService還會使用一個含有1個線程(線程名字:DubboMonitorTimer)的線程池每隔5min鍾,將文件中的統計數據畫成圖表

23、RPC使用了哪些關鍵技術,從調用者的角度看:

服務的調用者啟動的時候根據自己訂閱的服務向服務注冊中心查找服務提供者的地址等信息;

當服務調用者消費的服務上線或者下線的時候,注冊中心會告知該服務的調用者;

服務調用者下線的時候,則取消訂閱。

24、Dubbo 可以對結果進行緩存嗎?

為了提高數據訪問的速度。Dubbo 提供了聲明式緩存,以減少用戶加緩存的工作量<dubbo:reference cache=“true” />

其實比普通的配置文件就多了一個標簽 cache=“true”

25、Dubbo 用到哪些設計模式?

Dubbo框架在初始化和通信過程中使用了多種設計模式,可靈活控制類加載、權限控制等功能。

工廠模式

Provider在export服務時,會調用ServiceConfig的export方法。ServiceConfig中有個字段:

private static final Protocol protocol = ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension();

Dubbo里有很多這種代碼。這也是一種工廠模式,只是實現類的獲取采用了JDK SPI的機制。這么實現的優點是可擴展性強,想要擴展實現,只需要在classpath下增加個文件就可以了,代碼零侵入。另外,像上面的Adaptive實現,可以做到調用時動態決定調用哪個實現,但是由於這種實現采用了動態代理,會造成代碼調試比較麻煩,需要分析出實際調用的實現類。

裝飾器模式

Dubbo在啟動和調用階段都大量使用了裝飾器模式。以Provider提供的調用鏈為例,具體的調用鏈代碼是在ProtocolFilterWrapper的buildInvokerChain完成的,具體是將注解中含有group=provider的Filter實現,按照order排序,最后的調用順序是:

EchoFilter -> ClassLoaderFilter -> GenericFilter -> ContextFilter -> ExecuteLimitFilter -> TraceFilter -> TimeoutFilter -> MonitorFilter -> ExceptionFilter

更確切地說,這里是裝飾器和責任鏈模式的混合使用。例如,EchoFilter的作用是判斷是否是回聲測試請求,是的話直接返回內容,這是一種責任鏈的體現。而像ClassLoaderFilter則只是在主功能上添加了功能,更改當前線程的ClassLoader,這是典型的裝飾器模式。

觀察者模式

Dubbo的Provider啟動時,需要與注冊中心交互,先注冊自己的服務,再訂閱自己的服務,訂閱時,采用了觀察者模式,開啟一個listener。注冊中心會每5秒定時檢查是否有服務更新,如果有更新,向該服務的提供者發送一個notify消息,provider接受到notify消息后,即運行NotifyListener的notify方法,執行監聽器方法。

動態代理模式

Dubbo擴展JDK SPI的類ExtensionLoader的Adaptive實現是典型的動態代理實現。Dubbo需要靈活地控制實現類,即在調用階段動態地根據參數決定調用哪個實現類,所以采用先生成代理類的方法,能夠做到靈活的調用。生成代理類的代碼是ExtensionLoader的createAdaptiveExtensionClassCode方法。代理類的主要邏輯是,獲取URL參數中指定參數的值作為獲取實現類的key。

26、Dubbo 如何優雅停機?

Dubbo 是通過 JDK 的 ShutdownHook 來完成優雅停機的,所以如果使用kill -9 PID 等強制關閉指令,是不會執行優雅停機的,只有通過 kill PID 時,才會執行。

27、RPC使用了哪些關鍵技術,NIO通信

出於並發性能的考慮,傳統的阻塞式 IO 顯然不太合適,因此我們需要異步的 IO,即 NIO。Java 提供了 NIO 的解決方案,Java 7 也提供了更優秀的 NIO.2 支持。可以選擇Netty或者MINA來解決NIO數據傳輸的問題。

28、在使用過程中都遇到了些什么問題?

如序列化問題。

29、集群容錯怎么做?

讀操作建議使用 Failover 失敗自動切換,默認重試兩次其他服務器。寫操作建議使用 Failfast 快速失敗,發一次調用失敗就立即報錯。

30、Dubbo 超時時間怎樣設置?

Dubbo 超時時間設置有兩種方式:

服務提供者端設置超時時間,在 Dubbo 的用戶文檔中,推薦如果能在服務端多配置就盡量多配置,因為服務提供者比消費者更清楚自己提供的服務特性。

服務消費者端設置超時時間,如果在消費者端設置了超時時間,以消費者端為主,即優先級更高。因為服務調用方設置超時時間控制性更靈活。如果消費方超時,服務端線程不會定制,會產生警告。

更多 Dubbo 面試題70道

01、Dubbo 集群提供了哪些負載均衡策略?

02、RPC的實現基礎?

03、dubbo 通信協議 dubbo 協議適用范圍和適用場景

04、Dubbo 是什么?

05、Dubbo 默認采用注冊中心?

06、Dubbo SPI 和 Java SPI 區別?

07、Dubbo 有些哪些注冊中心?

08、Dubbo 超時時間怎樣設置?

09、Dubbo telnet 命令能做什么?

10、Dubbo 和 Spring Cloud 有什么哪些區別?

11、你覺得用 Dubbo 好還是 Spring Cloud 好?

12、Dubbo Monitor 實現原理?

13、RPC使用了哪些關鍵技術,從調用者的角度看:

14、Dubbo 可以對結果進行緩存嗎?

15、Dubbo 用到哪些設計模式?

16、Dubbo 如何優雅停機?

17、RPC使用了哪些關鍵技術,NIO通信

18、在使用過程中都遇到了些什么問題?

09、集群容錯怎么做?

20、Dubbo 超時時間怎樣設置?

21、Dubbo集群提供了哪些負載均衡策略?

22、Dubbo 服務器注冊與發現的流程?

23、同一個服務多個注冊的情況下可以直連某一個服務嗎?

24、默認使用什么序列化框架,你知道的還有哪些?

25、你還了解別的分布式框架嗎?

26、Dubbo 的使用場景有哪些?

27、Dubbo 的注冊中心集群掛掉,者和訂閱者之間還能通信么?

28、同一個服務多個注冊的情況下可以直連某一個服務嗎?

29、默認使用什么序列化框架,你知道的還有哪些?

30、Dubbo 和 Dubbox 之間的區別?

31、Dubbo 集群容錯有幾種方案?

32、Dubbo 的注冊中心集群掛掉,發布者和訂閱者之間還能通信么?

33、Dubbo 能集成 SpringBoot 嗎?

34、Dubbo 支持哪些協議,每種協議的應用場景,優缺點?

35、Dubbo 和 Spring Cloud 的關系?

36、dubbo 推薦用什么協議?

37、Dubbo 核心組件有哪些?

08、如何解決服務調用鏈過長的問題?

39、Dubbo 使用過程中都遇到了些什么問題?

40、同一個服務多個注冊的情況下可以直連某一個服務嗎?

41、Dubbo 服務器注冊與發現的流程?

42、Dubbo 的默認集群容錯方案?

43、RPC使用了哪些關鍵技術,動態代理

44、dubbo 服務負載均衡策略?

45、Dubbo的集群容錯方案有哪些?

46、Dubbo 和 Dubbox 之間的區別?

47、默認使用什么序列化框架,你知道的還有哪些?

48、RPC使用了哪些關鍵技術,RMI

49、Dubbo 的注冊中心集群掛掉,發布者和訂閱者之間還能通信么?

50、Dubbo的集群容錯方案有哪些?

51、RPC使用了哪些關鍵技術,序列化

52、Dubbo 支持哪些序列化方式?

53、說說核心的配置有哪些?

54、Dubbo集群提供了哪些負載均衡策略?

55、Dubbo 使用的是什么通信框架?

56、服務調用是阻塞的嗎?

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

58、Dubbo 超時時間怎樣設置?

59、Dubbo 的注冊中心集群掛掉,者和訂閱者之間還能通信么?

60、Dubbo telnet 命令能做什么?

61、你還了解別的分布式框架嗎?

62、在使用過程中都遇到了些什么問題?

63、Dubbo 超時時間怎樣設置?

64、同一個服務多個注冊的情況下可以直連某一個服務嗎?

65、服務調用是阻塞的嗎?

66、Dubbo 和 Spring Cloud 的區別?

67、服務讀寫推薦的容錯策略是怎樣的?

68、默認使用的是什么通信框架,還有別的選擇嗎?

69、Dubbo 如何優雅停機?

70、Dubbo 集群容錯有幾種方案?

如果不背 Dubbo面試題的答案,肯定面試會掛!

這套Dubbo面試題大全,希望對大家有幫助哈~

博主已將以下這些面試題整理成了一個Java面試手冊,是PDF版的


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM