柚子快報激活碼778899分享：Spring Cloud面試篇
柚子快報激活碼778899分享：Spring Cloud面試篇
面試篇-nacos面試題
1. springboot常見組件
注冊中心組件：Eureka、Nacos 負載均衡組件：Ribbon 遠程調用組件：OpenFeign 網關組件：Zuul、Gateway 服務保護組件：Hystrix、Sentinel 服務配置管理組件：SpringCloudConfig、Nacos
2. nacos注冊表的結構
回答: 分級存儲模型。下圖是nacos服務的分級存儲模型
????????對上圖的解釋: Nacos采用了數據的分級存儲模型，最外層是Namespace，用來隔離環(huán)境。然后是Group，用來對服務分組。接下來就是服務（Service）了，一個服務包含多個實例，但是可能處于不同機房，因此Service下有多個集群（Cluster），Cluster下是不同的實例（Instance）。對應到Java代碼中，Nacos采用了一個多層的Map來表示。結構為Map
3. nacos解決高并發(fā)
nacos如何解決高并發(fā)的注冊壓力？ ????????回答: Nacos內部接收到注冊的請求時，不會立即寫數據，而是將服務注冊的任務放入一個阻塞隊列就立即響應給客戶端。然后利用線程池讀取阻塞隊列中的任務，異步來完成實例更新，從而提高并發(fā)寫能力
4. nacos并發(fā)讀寫沖突
Nacos如何避免并發(fā)讀寫沖突問題？ ????????回答: Nacos在更新實例列表時，會采用CopyOnWrite技術，首先將舊的實例列表拷貝一份，然后更新拷貝的實例列表，再用更新后的實例列表來覆蓋舊的實例列表。這樣在更新的過程中，就不會對讀實例列表的請求產生影響，也不會出現臟讀問題了
5. nacos與eureka的區(qū)別
接口方式：Nacos與Eureka都對外暴露了Rest風格的API接口，用來實現服務注冊、發(fā)現等功能 實例類型：Nacos的實例有永久和臨時實例之分；而Eureka只支持臨時實例 健康檢測：Nacos對臨時實例采用心跳模式檢測，對永久實例采用主動請求來檢測；Eureka只支持心跳模式 服務發(fā)現：Nacos支持定時拉取和訂閱推送兩種模式；Eureka只支持定時拉取模式
面試篇-sentinel面試題
1. 線程隔離的方式
線程隔離有兩種方式實現 ●線程池隔離（Hystix默認采用） ●信號量隔離（Sentinel默認采用）
優(yōu)點 缺點 場景 線程池隔離 支持主動超時，支持異步調用 線程的額外開銷比較大 低扇出 信號量隔離 輕量級，無額外開銷 不支持主動超時，不支持異步調用 高頻調用，高扇出
2. 限流相關的算法
限流：對應用服務器的請求做限制，避免因過多請求而導致服務器過載甚至宕機。限流算法常見的包括三種 ●計數器算法，又包括窗口計數器算法、滑動窗口計數器算法 ●令牌桶算法（Token Bucket） ●漏桶算法(Leaky Bucket) 固定窗口計數器算法概念如下: 一、將時間劃分為多個窗口(下圖的藍虛線)，窗口時間跨度稱為Interval，本例中為1000ms 二、每個窗口維護一個計數器，每有一次請求(下圖的綠塊)就將計數器加一，限流就是設置計數器閾值(下圖的紅虛線)，本例為3秒 三、如果計數器超過了限流閾值，則超出閾值的請求都被丟棄(下圖的橙塊) 四、缺點: 紫色部分的情況，雖然兩個窗口都能容納3個請求，但是在那1秒你實際要應對6個請求，就會超出閾值設定的3秒，給服務器造成壓力
滑動窗口計數器算法會將一個窗口劃分為n個更小的區(qū)間，如下: 一、窗口時間跨度為1秒(下圖的每兩個綠虛線塊)，區(qū)間數量 n = 2 (每秒有兩個小窗口，即有兩個綠虛線塊)，則每個小區(qū)間時間跨度為500ms 二、限流閾值(下圖的紅虛線)依然為3，時間窗口(有兩個小窗口，共表示1秒) 內請求(綠塊)超過閾值時，超出的請求被限流 三、窗口會根據請求的當前時間來移動，窗口范圍是從'當前請求時間 減 時間跨度' 之后的第一個時區(qū)開始，到所在時區(qū)結束 四、滑動窗口是通過把單個窗口細分為多個窗口，作用是盡可能避免固定窗口的問題 五、缺點: 只要是窗口就會存在請求超出閾值但被放行的結果。例如1250ms~2100ms，間隔了850毫秒，但是放行了4個請求，不符合1秒最多3個請求的閾值
令牌桶算法如下: 一、以固定的速率(相當于限流)生成令牌，存入令牌桶中，如果令牌桶滿了以后，多余令牌丟棄 二、請求進入后，必須先嘗試從桶中獲取令牌，獲取到令牌后才可以被處理 三、如果令牌桶中沒有令牌，則請求等待或丟棄 四、桶里面放的是令牌
漏桶算法如下: 一、將每個請求視作"水滴"放入"漏桶"進行存儲 二、"漏桶"以固定速率向外"漏"出請求來執(zhí)行，如果"漏桶"空了則停止"漏水” 三、如果"漏桶"滿了則多余的"水滴"會被直接丟棄 四、可以理解成請求在桶內排隊等待。有利于應對突發(fā)請求 五、漏銅算法是用來優(yōu)化令牌桶 算法的，漏銅算法的桶里面放的是請求
Sentinel在實現漏桶時，采用了排隊等待模式：讓所有請求進入一個隊列中，然后按照閾值允許的時間間隔依次執(zhí)行。并發(fā)的多個請求必須等待，預期的等待時長 =最近一次請求的預期等待時間 + 允許的間隔。如果請求預期的等待時間超出最大時長，則會被拒絕。例如：QPS = 5，意味著每200ms處理一個隊列中的請求；timeout = 2000，意味著預期等待超過2000ms的請求會被拒絕并拋出異常。如下圖
3. 限流算法的對比
注意: 固定窗口并沒有在內
滑動時間窗口 令牌桶 漏桶 能否保證流量曲線平滑 不能，但窗口內區(qū)間越小，流量控制越平滑 基本能，在請求量持續(xù)高于令牌生成速度時，流量平滑。但請求量在令牌生成速率上下波動時，無法保證曲線平滑 能，所有請求進入桶內，以恒定速率放行，絕對平滑 能否應對突增流量 不能，徒增流量，只要高出限流閾值都會被拒絕 能，桶內積累的令牌可以應對突增流量 能，請求可以暫存在桶內 流量控制精確度 低，窗口區(qū)間越小，精度越高 高 高
4. Sentinel與Hystix的區(qū)別
【線程隔離的角度】 Hystix: 默認是基于線程池實現的線程隔離，每一個被隔離的業(yè)務都要創(chuàng)建一個獨立的線程池，線程過多會帶來額外的CPU開銷，性能一般，但是隔離性更強。Sentinel: 是基于信號量（計數器）實現的線程隔離，不用創(chuàng)建線程池，性能較好，但是隔離性一般
5. sentinel與gateway的區(qū)別
【限流的角度】 限流算法常見的有三種實現：滑動時間窗口、令牌桶算法、漏桶算法。 Gateway: 采用了基于Redis實現的令牌桶算法 Sentinel: 相對復雜，默認限流模式是基于滑動時間窗口算法排隊等待的限流模式則基于漏桶算法而熱點參數限流則是基于令牌桶算法
完結撒花
文件下載-奶?？靷?Download ｜CowTransfer
該筆記對標的視頻是BV1LQ4y127n4
柚子快報激活碼778899分享：Spring Cloud面試篇
相關閱讀
本文內容根據網絡資料整理，出于傳遞更多信息之目的，不代表金鑰匙跨境贊同其觀點和立場。
轉載請注明，如有侵權，聯系刪除。
Emex通道優(yōu)選家
