老鐵們，大家好，相信還有很多朋友對于spring和springcloud面試題常問的相關問題不太懂，沒關系，今天就由我來為大家分享分享spring以及springcloud面試題常問的問題，文章篇幅可能偏長，希望可以幫助到大家，下面一起來看看吧！
springcloud高級面試題
1.什么是微服務？
2.差異配置中心如何工作？
3.如何解決SpringCloud應用的配置管理？
4.SpringCloud有哪些主要的組件？
5.NetflixOSS的組件如何組合在一起來構建可擴展的應用？
6.SpringCloud使用哪種服務發現機制？
7.微服務和負載均衡之間有何區別？
8.使用SpringCloudStream如何處理消息傳遞？
9.描述Ribbon負載均衡和Feign負載均衡之間的差異？
10.有哪些Hystrix斷路器必須考慮的因素？
mq面試必背知識點
主要有3點：解耦、異步、削峰（限流）。
其實就是在服務與服務之間增加了一個中間件，可以實現上面的三種用途。
?
解耦：我們看到，服務A強依賴服務B和C，當服務B或者C掛掉后，會直接導致服務A的不可用，這顯然不是我們所期望的。比如服務的最后一步是記錄日志，但是該服務掛了，雖然日志服務和主流服務沒有必然的業務聯系，但是因為代碼的耦合性過高，直接導致整個服務響應失敗。
異步：假如服務A本身執行只需要10ms，服務B需要5ms，服務C（日志服務）需要1s。同樣的，一個和業務本身無關的服務過長的響應時間導致了整體服務的響應超時。
削峰：假如由于服務C只是記錄日志的，服務器配置較低，1s只能處理2000條數據，但是高峰時段，每秒的請求高達10萬筆，過高的請求會導致服務器崩潰。
可以看到，其實上面所講的三種情況，都很類似，連起來可以這么理解。高峰時段導致服務C運行越來越慢，產生了“異步”所說的問題，如果長時間沒解決，可能會導致“解耦”所說的情況，即服務掛掉。
在增加了MQ以后，我們可以在服務A執行完核心業務后，將后續處理的業務數據打入消息隊列中，然后就可以返回成功。然后日志服務從消息隊列中取到對應的消息進行處理即可。這樣就實現了“解耦”和“異步”。在高峰時段，所有的數據都會打入消息隊列中，而日志服務只需要按照自己的消費水平（2000條/s）取數據就好，保證了服務的平滑穩定。
二、MQ選型
主流的MQ有4種，ActiveMQ、RabbitMQ、RocketMQ和Kafka。不過ActiveMQ雖然框架成熟、曾經是MQ中的王牌，但是現在官方的維護頻率越來越低，國內各大公司已經很少才用了，再加上吞吐量不高（比kafka低一個數量級），存在消息丟失的情況，所以現在新項目很少會采用了。
RabbitMQ是用ErLang語言開發的，性能上是最好的，但是由于ErLang語言不是主流語言，二次開發難度較高，很多想要根據實際情況進行二次開發的公司很少采用。不過如果只是簡單使用的話，還是不錯的，畢竟它的延時是最少的；并且RabbitMQ有一個最大的好處是它具有可視化界面，操作維護很方便。
RocketMQ是阿里開源的產品，經過了很多高并發項目的考驗（如雙十一），性能上是有保證的。純Java編寫，維護性高。我理解的它和kafka最大的不同有兩點，一是它支持事務；二是集群結構不一致，它沒有主從切換，當leader掛掉后，存在一定的感知時間，然后切換到follower上。
kafka的特點就是高吞吐量，一般配合大數據類的系統來進行實時數據計算、日志采集，在日志收集領域是事實上的標準。
另外，springCloud全家桶中，有一個springCloudStream消息驅動框架，該框架很好的封裝了MQ操作的相關API，減輕了開發者在MQ方面的代碼量，不過該框架只封裝了RabbitMQ和kafka這兩種MQ。
綜上，如果需要對MQ傳輸提供事務支持或者解決高并發下的業務解耦，建議采用RocketMQ，微服務框架是dubbo的話，應該也建議用RocketMQ（這個沒測過，個人猜測，畢竟都是阿里的產品）。如果是要做日志收集等工作，建議采用kafka。中小型公司使用springCloud全家桶開發的項目中，建議采用RabbitMQ（或者kafka）。
以上是查資料總結的，由于我平時都是使用的kafka，所以后面都以kafka為例了。
三、重復消費
重復消費在MQ中是一個重點問題，該問題是如何產生的？
kafka中有一個消息偏移量offset，每當消費者消費完一條消息時，執行commit，會將offset+1。如果一條消息在消費完以后尚未commitoffset，突發宕機，會讓zookeeper認為該條消息沒有被消費。導致消費者重啟后重復消費之前的數據。
如何避免？
避免重復消費的問題，與同一個服務被多次調用的問題類似，就是如何解決服務的冪等性。大致有如下幾個方案：
1、利用數據庫的唯一性約束。
2、將數據存入redis中，利用redis天然的冪等性，然后再將數據從redis同步到數據庫中
3、生產者發消息時增加一個唯一id（比如UUID），消費者消費成功后將該UUID存入redis中，每次消費前先查看該UUID是否存在。
四、消息丟失
消息丟失同樣也是MQ中是一個重點問題。由于系統中存在生產者、消費者和MQ本身三個組件，所以需要從這三個方面分別討論。
MQ本身丟失：由于kafka的集群是leader/follower模式，leader先接受消息后，再同步給follower，如果leader接收到消息后發生宕機，沒來得及同步數據給follower，這時依靠選舉機制產生了新的leader，但是它已經永遠的失去了這條消息。為了避免這種情況發生，就需要修改kafka的配置，利用kafka自身的特性來解決。
首先給topic設置replication.factor參數：這個值必須大于1，要求每個partition必須有至少2個副本。
然后在kafka服務端設置min.insync.replicas參數：這個值必須大于1，這個是要求一個leader至少感知到有至少一個follower還跟自己保持聯系，沒掉隊，這樣才能確保leader掛了還有一個follower。
然后在producer端設置acks=all：這個是要求每條數據，必須是寫入所有replica之后，才能認為是寫成功了
最后在producer端設置retries=MAX（很大很大很大的一個值，無限次重試的意思）：這個是要求一旦寫入失敗，就無限重試，卡在這里了。
這樣配置以后，就可以保證只有所有的副本數據都同步成功后，才認為消息發送成功，避免了leader掛掉的情況。
消費者丟失：kafka有一個自動提交機制，每次接受到消息后自動提交offset。如果消息還未處理就掛掉了，但zk卻已經接收到消費成功的通知，顯然不合理，所以要避免使用kafka的自動提交，改為手動提交。
生產者丟失：顯然，如果配置了acks=all以后，生產者是不會發生消息丟失的。
另外，查資料發現RabbitMQ和kafka的消息丟失情況不同，這里補充一個RabbitMQ的處理方式。
MQ本身丟失：由于RabbitMQ沒有集群配置，所以只能依靠持久化到本地的方式來進行備份。如果接收到消息還沒來得及備份就掛掉了，就會導致消息丟失。不過這個概率很低。如果發生了，可以利用生產者丟失的方式處理，見下。
消費者丟失：產生原因不說了?？梢圆捎肦abbitMQ提供的ack機制，即關閉RabbitMQ自動ack，然后通過api來調用就行，在確認處理完消息后，手動提交ack通知MQ。
生產者丟失：可能存在的問題就是生產者發送消息后，網絡傳輸有問題導致了數據丟失。為了避免這種情況，一般會開啟事務機制，保證數據一致性，但是事務機制由于是同步的，會造成系統性能下降，所以可以借鑒分布式事務的理念，即confirm機制。生產者發送消息后，開啟異步接受MQ的反饋，收到后，默認消息發送成功，超時后觸發消息重發機制。
五、如何確保消息順序消費。
這個很簡單，只要保證每個消費者或者每個處理線程都對應一個隊列即可。
六、消息積壓如何處理。
畢竟流量高峰的時間存在不長，只要最初規劃MQ的空間時考慮到流量高峰的容量，一般是不會出現積壓的，除非由于代碼bug或者消費者宕機。
這時為了快速處理積壓的消息，我們除了修正bug和重啟服務器以外，還需要有提前定好的應急方案，即臨時擴容消費者，增加消費者處理速度。并且不能設置消息的TTL，保證消息一直存在。
實在沒辦法了的終極解決方案，就是拋棄部分消息，然后過了高峰以后，依靠日志等方式人肉維護。。。
最后，說一個我之前的公司，為了避免重復消費和消息丟失的解決方案，就是在生產者發送消息前和消費者接收消息后，在本地記錄一條數據，然后定時對比兩者的差異，來確保這兩個問題不會發生。同樣該方案也可用于處理積壓，完全可以拋棄消息，最后依靠生產者記錄的數據進行維護。這種方式比較適合業務分離狀態的，如購物場景，只要保證用戶下單成功即可，后續的出庫，贈加積分，贈送優惠券等功能稍緩緩也不礙事，但是如果是時效性較高的業務，比如商品查詢，可能商品描述、商品價格、商品圖片都是不同的服務在處理，如果一個服務不能正常返回，那這個業務就無法正常開展。這種情況，就建議采用限流策略了。
為什么要用springcloud面試題
因為可以初步測試是否適合崗位。
如何學習spring是先學習設計模式還是spring
看見上一位答主的可愛回答想笑。題主問這個問題應該是還沒接觸了解過spring框架，我有下面的學習建議:
spring框架和設計模式是兩大學習點spring框架包含了許多架構的頂級設計思路，去研究它是需要花費比較多經歷的。而設計模式也是一大課題，有專門一本厚厚的設計模式的書籍給你學習。因此，這兩種東西不能說先去學誰，應該是用到哪個學哪個。
有人說設計模式是為了彌補Java的不足，這是有一定道理的，常規的二十三種設計模式如果說你要全部理清還算要一點時間，要說能學精通還真的挺難。
spring框架的學習建議:先學習搭ssm框架項目感受spring框架的魅力。對spring框架原理進行理解，這里如果牽扯上了什么設計模式就去學習對應的設計模式。看看能不能理解和基本運用依賴注入和面向切面編程了。推薦讀《spring源碼深度解析》，系統性得結合源碼學習spring框架，途中一定會遇到的設計模式，遇到哪種模式就學哪種模式。歸納一下就是兩種并行學習，設計模式是輔助spring框架的理解。
覺得“熱心哥哥宇文笑”解讀專業的點點關注，會帶來更多精彩內容分享精通spring全家桶，被15家公司拒絕，大專程序員出路在哪
看你的情況，說明你對自己還是比較自信，認為自己卻掌握了比較全方位的技術，但是在面試過程中你屢屢碰壁，連續被多家單位和企業拒絕，拋開他們是否有眼光不說，這其中肯定有你自己的問題。建議你在以下幾個方面，查找自己面試過程中的不足。
1.是否把你的能力真正的展示出來了。
作為技術員而言，學歷是一個方面，可以作為一個參考，但并不是最重要，最重要的是有實打實的技術。企業需要的是能夠解決問題的技術員，而不是需要學歷高的技術員，這一點是很肯定的，所以你不必過于在意自己學歷不高的問題。如果是要需要學歷撐門面的話，本科研究生或許都什么用，至少也要找一個專家來撐門面。所以，很有可能是在你在面試的過程中，你并沒有把自己的能力真正的完全的展示出來。
2.是否有自己的代表作品。
企業在面試的過程中，通常都會與應聘者進行溝通，但是這些溝通都比較宏觀，也是一種感性的認識。你在面試的過程中，除了你介紹自己的技術全面之外，如果你能夠拿出自己具有代表性的作品，那么可以增強你的說服力，大大增加自己應試的籌碼。
3.是否對自己的工作經歷進行了系統梳理。
企業招聘人員的時候，要在短時間認識和了解一個人，本身這是一項難度很高的事情，所以給每個應聘者的時間并不是很多。那么，你在面試之前，要對自己的工作經歷，取得的業績或成果，對未來的發展設想，進行系統全面的梳理，以便于更高效的與相關的招聘人員進行溝通。不能以為自己是理工科類別，干的是技術活，就不需要梳理和總結。
祝你能早日找到滿意的工作。
spring的介紹就聊到這里吧，感謝你花時間閱讀本站內容，更多關于springcloud面試題常問、spring的信息別忘了在本站進行查找哦。
