三面美團終拿offer，分享面試題：Spring+Dubbo+Redis+Zookeeper+微服務

前言：

一線大廠一直是互聯網人包括程序員求之不得的公司，苦於BAT大廠的進入門檻過高，無奈只能望門興嘆，因此只能苦練技能纔能有機會去敲開BAT的大門。下面是一位Java程序員的親身經歷三面美團拿下了offer，特獻上面試真題，以供參考學習。

第一部分. Spring專題

一、Spring怎樣定義類的做用域

經過bean 定義中的scope屬性來定義。

二、Spring支持的幾種bean的做用域

支持如下五種bean的做用域：

• singleton : bean在每一個Spring ioc 容器中只有一個實例。（缺省默認）
• prototype：一個bean的定義能夠有多個實例。
• request：每次http請求都會建立一個bean，該做用域僅在基於web的Spring ApplicationContext情形下有效。
• session：在一個HTTP Session中，一個bean定義對應一個實例。該做用域僅在基於web的Spring ApplicationContext情形下有效。
• global-session：在一個全局的HTTP Session中，一個bean定義對應一個實例。該做用域僅在基於web的Spring ApplicationContext情形下有效。

三、Spring支持的事務管理類型

• 編程式事務管理：這意味你經過編程的方式管理事務，給你帶來極大的靈活性，可是難維護。
• 聲明式事務管理：這意味着你能夠將業務代碼和事務管理分離，你只需用註解和XML配置來管理事務。

四、什麼是控制反轉(IOC)？什麼是依賴注入？

• 控制反轉(IOC) ： 傳統應用程序是由咱們本身在對象中主動控制去直接獲取依賴對象，如今由容器幫咱們查找及注入依賴對象，對象只是被動的接受依賴對象，因此是控制反轉。
• 依賴注入：組件之間依賴關係由容器在運行期決定，形象的說，即由容器動態的將某個依賴關係注入到組件之中。經過依賴注入機制，咱們只須要經過簡單的配置，而無需任何代碼就可指定目標須要的資源，完成自身的業務邏輯，而不須要關心具體的資源來自何處，由誰實現。
• 實現方式：構造器注入、Setter方法注入、接口注入。註解裝配在默認狀況下是不開啓的，爲了使用註解裝配，咱們必須在Spring配置文件中配置 <context:annotation-config/>元素。

五、Spring由幾大核心組件？

• Bean 組件
• Context 組件
• Core 組件

六、Spring MVC核心工做流程 ？

• 用戶向服務器發送request請求，請求被SpringMVC中央控制器DispatcherServlet捕獲；
• DispatcherServlet對請求URL進行解析，獲得請求資源標識符（URI）。而後根據該URI，調用HandlerMapping映射處理器，將請求發送給指定的Controller。
• Controller執行完成後，將返回的數據信息封裝到ModelAndView對象中，最後經過ViewResolver視圖解析器選擇一個合適的View 渲染視圖返回界面。

七、spring事務隔離級別（五種面試最好所有說出來）

• DEFAULT 這是一個PlatfromTransactionManager默認的隔離級別，使用數據庫默認的事務隔離級別.
• 未提交讀（read uncommited） : 髒讀，不可重複讀，虛讀都有可能發生 。是最低的事務隔離級別，它容許另一個事務能夠看到這個事務未提交的數據。
• 已提交讀 （read commited）: 避免髒讀。可是不可重複讀、虛讀有可能發生 。保證一個事物提交後才能被另一個事務讀取。另一個事務不能讀取該事物未提交的數據。Oracle 默認
• 可重複讀 （repeatable read）: 這種事務隔離級別能夠防止髒讀，不可重複讀。可是可能會出現幻象讀。它除了保證一個事務不能被另一個事務讀取未提交的數據以外還避免瞭如下狀況產生（不可重複讀）。Mysql 默認
• 串行化的 （serializable） : 這是花費最高代價、效率差但最可靠的事務隔離級別。事務被處理爲順序執行。除了防止髒讀，不可重複讀以外，還避免了幻象讀（避免三種）。

八、Spring事務特性（四種面試最好所有說出來）

• 原子性 （atomicity）: 一個事務中全部對數據庫的操做是一個不可分割的操做序列，要麼全作要麼全不作。
• 一致性 （consistency）: 事務的執行的先後數據的完整性保持一致.
• 隔離性 （isolation）: 一個事務執行的過程當中,不該該受到其餘事務的干擾
• 持久性（durability） : 一個事物一旦提交，它對數據庫的改變就是永久的

九、Spring事務七個傳播特性（七種面試說一兩個便可）

• Propagation.REQUIRED (默認) 面試必須說出來這個。調用方已經存在事務，則加入到同一個事務中運行，不然，自啓一個事務
• Propagation.REQUIRES_NEW。不管什麼時候自身都會開啓新事務
• Propagation.SUPPORTS。調用方存在事務，則加入到同一個事務中運行，若不存在事務，則以非事務的方式運行
• Propagation.NOT_SUPPORTED。調用方存在事務，則會被掛起，直到被調用方運行完畢後，事務恢復。
• Propagation.MANDATORY。調用方存在事務，則加入到同一個事務中運行，若不存在，則拋出異常
• Propagation.NEVER。調用方存在事務，則拋出異常
• Propagation.NESTED。若調用方存在事務，則運行一個嵌套事務，若調用方不存在事務，則以Propagation.REQUIRED的方式運行,即開啓一個新的事務

十、簡述Spring Bean的生命週期

實例化、初始化、使用、銷燬。

關鍵詞：BeanFactoryPostProcessor 、BeanPostProcessor 、init-method/destroy-method

第二部分. Dubbo面試專題

一、Dubbo的容錯機制有哪些？

Dubbo官網提出總共有六種容錯策略

• Failover Cluster模式：失敗自動切換，當出現失敗，重試其它服務器。(默認)
• Failfast Cluster：快速失敗，只發起一次調用，失敗當即報錯。一般用於非冪等性的寫操做，好比新增記錄。
• Failsafe Cluster：失敗安全，出現異常時，直接忽略。一般用於寫入審計日誌等操做。
• Failback Cluster：失敗自動恢復，後臺記錄失敗請求，定時重發。一般用於消息通知操做。
• Forking Cluster：並行調用多個服務器，只要一個成功即返回。一般用於實時性要求較高的讀操做，但須要浪費更多服務資源。可經過forks=」2」來設置最大並行數。
• Broadcast Cluster：廣播調用全部提供者，逐個調用，任意一臺報錯則報錯。(2.1.0開始支持)一般用於通知全部提供者更新緩存或日誌等本地資源信息。

總結：在實際應用中查詢語句容錯策略建議使用默認Failover Cluster，而增刪改建議使用Failfast Cluster或者使用Failover Cluster（retries=」0」）策略防止出現數據重複添加等等其它問題。建議在設計接口時候把查詢接口方法單獨作一個接口提供查詢。

二、使用dubbo遇到過哪些問題？

增長提供服務版本號和消費服務版本號

這個具體來講不算是一個問題，而是一種問題的解決方案，在咱們的實際工做中會面臨各類環境資源短缺的問題，也是很實際的問題，剛開始咱們還能夠提供一個服務進行相關的開發和測試，可是當有多個環境多個版本，多個任務的時候就不知足咱們的需求，這時候咱們能夠經過給提供方增長版本的方式來區分.這樣可以剩下不少的物理資源，同時爲從此更換接口定義發佈在線時，可不停機發布，使用版本號.引用只會找相應版本的服務，例如：

<dubbo:serviceinterface="com.xxx.XxxService" ref="xxxService" version="1.0"/>
<dubbo:referenceid="xxxService" interface="com.xxx.XxxService" version="1.0"/>

三、dubbo reference註解問題？

@Reference只能在SpringBean實例對應的當前類中使用，暫時沒法在父類使用；若是確實要在父類聲明一個引用，可經過配置文件配置dubbo：reference，而後在須要引用的地方跟引用SpringBean同樣就能夠了.

四、出現RpcException：No provider available for remote service異常怎麼辦？

• 檢查鏈接的註冊中心是否正確
• 到註冊中心查看相應的服務提供者是否存在
• 檢查服務提供者是否正常運行

五、服務提供者沒掛，但在註冊中內心看不到？

首先，確認服務提供者是否鏈接了正確的註冊中心，不僅是檢查配置中的註冊中心地址，並且要檢查實際的網絡鏈接。

其次，看服務提供者是否很是繁忙，好比壓力測試，以致於沒有CPU片斷向註冊中心發送心跳，這種狀況減少壓力將自動恢復。

六、Dubbo的鏈接方式有哪些？

Dubbo的客戶端和服務端有三種鏈接方式，分別是：廣播，直連和使用zookeeper註冊中心。

七、Dubbo廣播

這種方式是dubbo官方入門程序所使用的鏈接方式，可是這種方式有不少問題。在企業開發中，不使用廣播的方式。taotao-manager服務端配置：

!-- applicationContext-service.xml 文件中 -->
<!-- 提供方應用信息，用於計算機依賴關係 -->
<dubbo:application name="taotao-manager-service」 />
<!-- 使用 multicast 廣播暴露服務地址 -->
<dubbo:registry address="multicast：//224.5.6.7：1234" />
<!-- 使用 dubbo 協議在 20880 協議暴露服務 -->
<dubboprotocol name="dubbo" port="20880" />
<!-- 聲明須要暴露的服務接口 -->
<dubbo:service interface="com.taotao.manager.service.TestService" ref="testServiceImpl" />

第三部分. Redis專題

1.什麼是Redis？

答：Remote Dictionary Server(Redis)是一個開源的使用ANSI C語言編寫、支持網絡、可基於內存亦可持久化的日誌型、Key-Value數據庫，並提供多種語言的API。

它一般被稱爲數據結構服務器，由於值（value）能夠是 字符串(String), 哈希(Map), 列表(list), 集合(sets) 和 有序集合(sorted sets)等類型。

2.Redis的特色什麼是？

• 支持多種數據結構，如 string(字符串)、 list(雙向鏈表)、dict(hash表)、set(集合)、zset(排序set)、hyperloglog(基數估算)
• 支持持久化操做，能夠進行aof及rdb數據持久化到磁盤，從而進行數據備份或數據恢復等操做，較好的防止數據丟失的手段。
• 支持經過Replication進行數據複製，經過master-slave機制，能夠實時進行數據的同步複製，支持多級複製和增量複製，master-slave機制是Redis進行HA的重要手段。

單進程請求，全部命令串行執行，併發狀況下不須要考慮數據一致性問題。

3.Redis數據類型有哪些？

答：

• String(字符串)
• Hash(hash表)
• List(鏈表)
• Set(集合)
• SortedSet(有序集合zset)

4. Redis的配置以及持久化方案有幾種？

答：如下兩種

• RDB方式
• AOF方式

第四部分. Zookeeper專題

1. Zookeeper是什麼框架

分佈式的、開源的分佈式應用程序協調服務，本來是Hadoop、HBase的一個重要組件。

應用場景：Zookeeper的功能很強大，應用場景不少，結合我實際工做中使用Dubbo框架的狀況，Zookeeper主要是作註冊中心用。

基於Dubbo框架開發的提供者、消費者都向Zookeeper註冊本身的URL，消費者還能拿到並訂閱提供者的註冊URL，以便在後續程序的執行中去調用提供者。而提供者發生了變更，也會經過Zookeeper向訂閱的消費者發送通知。

2. Zookeeper有哪幾種節點類型

• 持久：建立以後一直存在，除非有刪除操做，建立節點的客戶端會話失效也不影響此節點。
• 持久順序：跟持久同樣，就是父節點在建立下一級子節點的時候，記錄每一個子節點建立的前後順序，會給每一個子節點名加上一個數字後綴。
• 臨時：建立客戶端會話失效（注意是會話失效，不是鏈接斷了），節點也就沒了。不能建子節點。
• 臨時順序：不用解釋了吧。

3. Zookeeper對節點的watch監聽通知是永久的嗎？

不是。

官方聲明：一個Watch事件是一個一次性的觸發器，當被設置了Watch的數據發生了改變的時候，則服務器將這個改變發送給設置了Watch的客戶端，以便通知它們。

爲何不是永久的，舉個例子，若是服務端變更頻繁，而監聽的客戶端不少狀況下，每次變更都要通知到全部的客戶端，這太消耗性能了。

通常是客戶端執行getData(「/節點A」,true)，若是節點A發生了變動或刪除，客戶端會獲得它的watch事件，可是在以後節點A又發生了變動，而客戶端又沒有設置watch事件，就再也不給客戶端發送。

在實際應用中，不少狀況下，咱們的客戶端不須要知道服務端的每一次變更，我只要最新的數據便可。

4. Zookeeper集羣若是有3臺機器，掛掉一臺集羣還能工做嗎？掛掉兩臺呢？

記住一個原則：過半存活便可用。

集羣支持動態添加機器嗎？

其實就是水平擴容了，Zookeeper在這方面不太好。兩種方式：

• 所有重啓：關閉全部Zookeeper服務，修改配置以後啓動。不影響以前客戶端的會話。
• 逐個重啓：顧名思義。這是比較經常使用的方式。

第五部分. 微服務專題

1. 爲何要使用微服務跟蹤？它解決了什麼問題？

1. 微服務調用的現狀?

• 微服務的現狀:隨着業務的發展，單體架構變爲微服務架構，而且系統規模也變得愈來愈大，各微服務間的調用關係也變得愈來愈複雜。
• 多服務協同工做:在微服務的應用中，一個由客戶端發起的請求在後端系統中會通過多個不一樣的微服務調用來協同產生最後的請求結果。
• 複雜的調用鏈條容易出錯:在複雜的微服務架構系統中，幾乎每個前端請求都會造成一-個複雜的分佈式服務調用鏈路，在每條鏈路中任何一個依賴服務出現延遲超時或者錯誤都有可能引發整個請求最後的失敗。

2. 微服務跟蹤解決了什麼問題?

微服務跟蹤實際上是一個工具，它在整個分佈式系統中能跟蹤一個用戶請求的過程(包括數據採集、數據傳輸、數據存儲、數據分析、數據可視化) ,捕獲這些跟蹤數據，就能構建微服務的整個調用鏈的視圖，這是調試和監控微服務的關鍵工具。

Spring Cloud S1euth有4個特色:

• 提供鏈路追蹤:經過sleuth能夠很清楚的看出一-個請求都通過了哪些服務。能夠很方便的理清服務間的調用關係。
• 性能分析:經過sleuth能夠很方便的看出每一個採樣請求的耗時，分析出哪些服務調用比較耗時。當服務調用的耗時隨着請求量的增大而增大時，也能夠對服務的擴容提供- -定的提醒做用。
• 數據分析，優化鏈路:對於頻繁地調用一個服務，或者並行地調用等，能夠針對業務作一些優化措施。
• 可視化錯誤:對於程序未捕捉的異常，能夠在zipkin界面上看到。

寫在最後：

限於篇幅，文中只展現了部分的面試題，完整的面試題筆者已經整理成了一份PDF文件須要這份面試題的朋友請點擊下方傳送門；便可免費領取完整的面試專題文件

傳送門

如下是部分面試題截圖