👏作者簡介：大家好，我是愛寫博客的嗯哼，愛好Java的小菜坤
🔥如果感覺博主的文章還不錯的話，請👍三連支持👍一下博主哦
📝社區(qū)論壇：希望大家能加入社區(qū)共同進(jìn)步
🧑?💼個人博客：智慧筆記
📕系列專欄：面試寶典

• 本文引自黑馬程序員Java面試寶典

面試官：Spring Cloud 5大組件有哪些？

候選人：

早期我們一般認(rèn)為的Spring Cloud五大組件是

• Eureka : 注冊中心
• Ribbon : 負(fù)載均衡
• Feign : 遠(yuǎn)程調(diào)用
• Hystrix : 服務(wù)熔斷
• Zuul/Gateway : 網(wǎng)關(guān)

隨著SpringCloudAlibba在國內(nèi)興起 , 我們項(xiàng)目中使用了一些阿里巴巴的組件

• 注冊中心/配置中心 Nacos

• 負(fù)載均衡 Ribbon

• 服務(wù)調(diào)用 Feign

• 服務(wù)保護(hù) sentinel

• 服務(wù)網(wǎng)關(guān) Gateway

面試官：服務(wù)注冊和發(fā)現(xiàn)是什么意思？Spring Cloud 如何實(shí)現(xiàn)服務(wù)注冊發(fā)現(xiàn)？

候選人：

我理解的是主要三塊大功能，分別是服務(wù)注冊 、服務(wù)發(fā)現(xiàn)、服務(wù)狀態(tài)監(jiān)控

我們當(dāng)時項(xiàng)目采用的eureka作為注冊中心，這個也是spring cloud體系中的一個核心組件

服務(wù)注冊：服務(wù)提供者需要把自己的信息注冊到eureka，由eureka來保存這些信息，比如服務(wù)名稱、ip、端口等等

服務(wù)發(fā)現(xiàn)：消費(fèi)者向eureka拉取服務(wù)列表信息，如果服務(wù)提供者有集群，則消費(fèi)者會利用負(fù)載均衡算法，選擇一個發(fā)起調(diào)用

服務(wù)監(jiān)控：服務(wù)提供者會每隔30秒向eureka發(fā)送心跳，報告健康狀態(tài)，如果eureka服務(wù)90秒沒接收到心跳，從eureka中剔除

面試官：我看你之前也用過nacos、你能說下nacos與eureka的區(qū)別？

候選人：

我們當(dāng)時xx項(xiàng)目就是采用的nacos作為注冊中心，選擇nacos還要一個重要原因就是它支持配置中心，不過nacos作為注冊中心，也比eureka要方便好用一些，主要相同不同點(diǎn)在于幾點(diǎn)：

• 共同點(diǎn)

Nacos與eureka都支持服務(wù)注冊和服務(wù)拉取，都支持服務(wù)提供者心跳方式做健康檢測

• Nacos與Eureka的區(qū)別

①Nacos支持服務(wù)端主動檢測提供者狀態(tài)：臨時實(shí)例采用心跳模式，非臨時實(shí)例采用主動檢測模式

②臨時實(shí)例心跳不正常會被剔除，非臨時實(shí)例則不會被剔除

③Nacos支持服務(wù)列表變更的消息推送模式，服務(wù)列表更新更及時

④Nacos集群默認(rèn)采用AP方式，當(dāng)集群中存在非臨時實(shí)例時，采用CP模式；Eureka采用AP方式

面試官：你們項(xiàng)目負(fù)載均衡如何實(shí)現(xiàn)的 ?

候選人：

是這樣~~

在服務(wù)調(diào)用過程中的負(fù)載均衡一般使用SpringCloud的Ribbon 組件實(shí)現(xiàn) , Feign的底層已經(jīng)自動集成了Ribbon , 使用起來非常簡單

當(dāng)發(fā)起遠(yuǎn)程調(diào)用時，ribbon先從注冊中心拉取服務(wù)地址列表，然后按照一定的路由策略選擇一個發(fā)起遠(yuǎn)程調(diào)用，一般的調(diào)用策略是輪詢

面試官：Ribbon負(fù)載均衡策略有哪些 ?

候選人：

我想想啊，有很多種，我記得幾個：

• RoundRobinRule：簡單輪詢服務(wù)列表來選擇服務(wù)器

• WeightedResponseTimeRule：按照權(quán)重來選擇服務(wù)器，響應(yīng)時間越長，權(quán)重越小

• RandomRule：隨機(jī)選擇一個可用的服務(wù)器

• ZoneAvoidanceRule：區(qū)域敏感策略，以區(qū)域可用的服務(wù)器為基礎(chǔ)進(jìn)行服務(wù)器的選擇。使用Zone對服務(wù)器進(jìn)行分類，這個Zone可以理解為一個機(jī)房、一個機(jī)架等。而后再對Zone內(nèi)的多個服務(wù)做輪詢(默認(rèn))

面試官：如果想自定義負(fù)載均衡策略如何實(shí)現(xiàn) ?

候選人：

提供了兩種方式：

1，創(chuàng)建類實(shí)現(xiàn)IRule接口，可以指定負(fù)載均衡策略，這個是全局的，對所有的遠(yuǎn)程調(diào)用都起作用

2，在客戶端的配置文件中，可以配置某一個服務(wù)調(diào)用的負(fù)載均衡策略，只是對配置的這個服務(wù)生效遠(yuǎn)程調(diào)用

面試官：什么是服務(wù)雪崩，怎么解決這個問題？

候選人：

服務(wù)雪崩是指一個服務(wù)失敗，導(dǎo)致整條鏈路的服務(wù)都失敗的情形，一般我們在項(xiàng)目解決的話就是兩種方案，第一個是服務(wù)降級，第二個是服務(wù)熔斷，如果流量太大的話，可以考慮限流

服務(wù)降級：服務(wù)自我保護(hù)的一種方式，或者保護(hù)下游服務(wù)的一種方式，用于確保服務(wù)不會受請求突增影響變得不可用，確保服務(wù)不會崩潰，一般在實(shí)際開發(fā)中與feign接口整合，編寫降級邏輯

服務(wù)熔斷：默認(rèn)關(guān)閉，需要手動打開，如果檢測到 10 秒內(nèi)請求的失敗率超過 50%，就觸發(fā)熔斷機(jī)制。之后每隔 5 秒重新嘗試請求微服務(wù)，如果微服務(wù)不能響應(yīng)，繼續(xù)走熔斷機(jī)制。如果微服務(wù)可達(dá)，則關(guān)閉熔斷機(jī)制，恢復(fù)正常請求

面試官：你們的微服務(wù)是怎么監(jiān)控的？

候選人：

我們項(xiàng)目中采用的skywalking進(jìn)行監(jiān)控的

1，skywalking主要可以監(jiān)控接口、服務(wù)、物理實(shí)例的一些狀態(tài)。特別是在壓測的時候可以看到眾多服務(wù)中哪些服務(wù)和接口比較慢，我們可以針對性的分析和優(yōu)化。

2，我們還在skywalking設(shè)置了告警規(guī)則，特別是在項(xiàng)目上線以后，如果報錯，我們分別設(shè)置了可以給相關(guān)負(fù)責(zé)人發(fā)短信和發(fā)郵件，第一時間知道項(xiàng)目的bug情況，第一時間修復(fù)

面試官：你們項(xiàng)目中有沒有做過限流 ? 怎么做的 ?

候選人：

我當(dāng)時做的xx項(xiàng)目，采用就是微服務(wù)的架構(gòu)，因?yàn)閤x因?yàn)?#xff0c;應(yīng)該會有突發(fā)流量，最大QPS可以達(dá)到2000，但是服務(wù)支撐不住，我們項(xiàng)目都通過壓測最多可以支撐1200QPS。因?yàn)槲覀兤綍r的QPS也就不到100，為了解決這些突發(fā)流量，所以采用了限流。

【版本1】

我們當(dāng)時采用的nginx限流操作，nginx使用的漏桶算法來實(shí)現(xiàn)過濾，讓請求以固定的速率處理請求，可以應(yīng)對突發(fā)流量，我們控制的速率是按照ip進(jìn)行限流，限制的流量是每秒20

【版本2】

我們當(dāng)時采用的是spring cloud gateway中支持局部過濾器RequestRateLimiter來做限流，使用的是令牌桶算法，可以根據(jù)ip或路徑進(jìn)行限流，可以設(shè)置每秒填充平均速率，和令牌桶總?cè)萘?/p>

面試官：限流常見的算法有哪些呢？

候選人：

比較常見的限流算法有漏桶算法和令牌桶算法

漏桶算法是把請求存入到桶中，以固定速率從桶中流出，可以讓我們的服務(wù)做到絕對的平均，起到很好的限流效果

令牌桶算法在桶中存儲的是令牌，按照一定的速率生成令牌，每個請求都要先申請令牌，申請到令牌以后才能正常請求，也可以起到很好的限流作用

它們的區(qū)別是，漏桶和令牌桶都可以處理突發(fā)流量，其中漏桶可以做到絕對的平滑，令牌桶有可能會產(chǎn)生突發(fā)大量請求的情況，一般nginx限流采用的漏桶，spring cloud gateway中可以支持令牌桶算法

面試官：什么是CAP理論？

候選人：

CAP主要是在分布式項(xiàng)目下的一個理論。包含了三項(xiàng)，一致性、可用性、分區(qū)容錯性

• 一致性(Consistency)是指更新操作成功并返回客戶端完成后，所有節(jié)點(diǎn)在同一時間的數(shù)據(jù)完全一致(強(qiáng)一致性)，不能存在中間狀態(tài)。

• 可用性(Availability) 是指系統(tǒng)提供的服務(wù)必須一直處于可用的狀態(tài)，對于用戶的每一個操作請求總是能夠在有限的時間內(nèi)返回結(jié)果。

• 分區(qū)容錯性(Partition tolerance) 是指分布式系統(tǒng)在遇到任何網(wǎng)絡(luò)分區(qū)故障時，仍然需要能夠保證對外提供滿足一致性和可用性的服務(wù)，除非是整個網(wǎng)絡(luò)環(huán)境都發(fā)生了故障。

面試官：為什么分布式系統(tǒng)中無法同時保證一致性和可用性？

候選人：

嗯，是這樣的~~

首先一個前提，對于分布式系統(tǒng)而言，分區(qū)容錯性是一個最基本的要求，因此基本上我們在設(shè)計分布式系統(tǒng)的時候只能從一致性（C）和可用性（A）之間進(jìn)行取舍。

如果保證了一致性（C）：對于節(jié)點(diǎn)N1和N2，當(dāng)往N1里寫數(shù)據(jù)時，N2上的操作必須被暫停，只有當(dāng)N1同步數(shù)據(jù)到N2時才能對N2進(jìn)行讀寫請求，在N2被暫停操作期間客戶端提交的請求會收到失敗或超時。顯然，這與可用性是相悖的。

如果保證了可用性（A）：那就不能暫停N2的讀寫操作，但同時N1在寫數(shù)據(jù)的話，這就違背了一致性的要求。

面試官：什么是BASE理論？

候選人：

嗯，這個也是CAP分布式系統(tǒng)設(shè)計理論

BASE是CAP理論中AP方案的延伸，核心思想是即使無法做到強(qiáng)一致性（StrongConsistency，CAP的一致性就是強(qiáng)一致性），但應(yīng)用可以采用適合的方式達(dá)到最終一致性（Eventual Consitency）。它的思想包含三方面：

1、Basically Available（基本可用）：基本可用是指分布式系統(tǒng)在出現(xiàn)不可預(yù)知的故障的時候，允許損失部分可用性，但不等于系統(tǒng)不可用。

2、Soft state（軟狀態(tài)）：即是指允許系統(tǒng)中的數(shù)據(jù)存在中間狀態(tài)，并認(rèn)為該中間狀態(tài)的存在不會影響系統(tǒng)的整體可用性，即允許系統(tǒng)在不同節(jié)點(diǎn)的數(shù)據(jù)副本之間進(jìn)行數(shù)據(jù)同步的過程存在延時。

3、Eventually consistent（最終一致性）：強(qiáng)調(diào)系統(tǒng)中所有的數(shù)據(jù)副本，在經(jīng)過一段時間的同步后，最終能夠達(dá)到一個一致的狀態(tài)。其本質(zhì)是需要系統(tǒng)保證最終數(shù)據(jù)能夠達(dá)到一致，而不需要實(shí)時保證系統(tǒng)數(shù)據(jù)的強(qiáng)一致性。

面試官：你們采用哪種分布式事務(wù)解決方案？

候選人：

我們當(dāng)時是xx項(xiàng)目，主要使用到的seata的at模式解決的分布式事務(wù)

seata的AT模型分為兩個階段：

1、階段一RM的工作：① 注冊分支事務(wù) ② 記錄undo-log（數(shù)據(jù)快照）③ 執(zhí)行業(yè)務(wù)sql并提交 ④報告事務(wù)狀態(tài)

2、階段二提交時RM的工作：刪除undo-log即可

3、階段二回滾時RM的工作：根據(jù)undo-log恢復(fù)數(shù)據(jù)到更新前

at模式犧牲了一致性，保證了可用性，不過，它保證的是最終一致性

面試官：分布式服務(wù)的接口冪等性如何設(shè)計？

候選人：

嗯，我們當(dāng)時有一個xx項(xiàng)目的下單操作，采用的token+redis實(shí)現(xiàn)的，流程是這樣的

第一次請求，也就是用戶打開了商品詳情頁面，我們會發(fā)起一個請求，在后臺生成一個唯一token存入redis，key就是用戶的id，value就是這個token，同時把這個token返回前端

第二次請求，當(dāng)用戶點(diǎn)擊了下單操作會后，會攜帶之前的token，后臺先到redis進(jìn)行驗(yàn)證，如果存在token，可以執(zhí)行業(yè)務(wù)，同時刪除token；如果不存在，則直接返回，不處理業(yè)務(wù)，就保證了同一個token只處理一次業(yè)務(wù)，就保證了冪等性

面試官：xxl-job路由策略有哪些？

候選人：

xxl-job提供了很多的路由策略，我們平時用的較多就是：輪詢、故障轉(zhuǎn)移、分片廣播…

面試官：xxl-job任務(wù)執(zhí)行失敗怎么解決？

候選人：

有這么幾個操作

第一：路由策略選擇故障轉(zhuǎn)移，優(yōu)先使用健康的實(shí)例來執(zhí)行任務(wù)

第二，如果還有失敗的，我們在創(chuàng)建任務(wù)時，可以設(shè)置重試次數(shù)

第三，如果還有失敗的，就可以查看日志或者配置郵件告警來通知相關(guān)負(fù)責(zé)人解決

面試官：如果有大數(shù)據(jù)量的任務(wù)同時都需要執(zhí)行，怎么解決？

候選人：

我們會讓部署多個實(shí)例，共同去執(zhí)行這些批量的任務(wù)，其中任務(wù)的路由策略是分片廣播

在任務(wù)執(zhí)行的代碼中可以獲取分片總數(shù)和當(dāng)前分片，按照取模的方式分?jǐn)偟礁鱾€實(shí)例執(zhí)行就可以了

往期文章推薦：

• redis相關(guān)面試題
• 圖解 Paxos 算法
• Spring相關(guān)面試題
• Mysql相關(guān)面試題
• 深入淺出WebSocket
• 關(guān)于redis的讀寫一致問題
• springsecurity加入第三方授權(quán)認(rèn)證
• Java連接mysql常遇時間問題