Spring Cloud 面試突擊2

高并發：是一種系統運行過程中遇到的短時間大量的請求操作

響應時間：

吞吐量：

QPS：數據庫為維度

TPS

并發用戶數

并發的維度：很多的

并發是不是達到的當前系統的瓶頸

緩存（第一手段）降級限流限制流量

5.在微服務中有幾種限流方式

sentinel hystrix 線程池 300線程

資源：被流量控制的對象

策略：限流算法以及可調節參數

基于請求限流：

基于資源限流：

限制總并發數限制瞬間的并發數

令牌桶

令牌桶算法是網絡流量整形（Traffic Shaping）和速率限制（Rate Limiting）中最常使用的一種算法。典型情況下，令牌桶算法用來控制發送到網絡上的數據的數目，并允許突發數據的發送。

令牌桶是一個存放固定容量令牌（token）的桶，按照固定速率往桶里添加令牌; 令牌桶算法實際上由三部分組成：兩個流和一個桶，分別是令牌流、數據流和令牌桶

令牌流與令牌桶

系統會以一定的速度生成令牌，并將其放置到令牌桶中，可以將令牌桶想象成一個緩沖區（可以用隊列這種數據結構來實現），當緩沖區填滿的時候，新生成的令牌會被扔掉。這里有兩個變量很重要：

第一個是生成令牌的速度，一般稱為 rate 。比如，我們設定 rate = 2 ，即每秒鐘生成 2 個令牌，也就是每 1/2 秒生成一個令牌；

第二個是令牌桶的大小，一般稱為 burst 。比如，我們設定 burst = 10 ，即令牌桶最大只能容納 10 個令牌。

數據流

數據流是真正的進入系統的流量，對于http接口來說，如果平均每秒鐘會調用2次，則認為速率為 2次/s。

特點：1.令牌是可以累計的，意味著我們能夠去處理小于令牌桶+令牌生成速率的瞬時流量

2.允許突發的流量

漏桶

漏桶算法思路是，不斷的往桶里面注水，無論注水的速度是大還是小，水都是按固定的速率往外漏水；如果桶滿了，水會溢出；

桶本身具有一個恒定的速率往下漏水，而上方時快時慢的會有水進入桶內。當桶還未滿時，上方的水可以加入。一旦水滿，上方的水就無法加入。桶滿正是算法中的一個關鍵的觸發條件（即流量異常判斷成立的條件）。而此條件下如何處理上方流下來的水，有兩種方式

在桶滿水之后，常見的兩種處理方式為：

1）暫時攔截住上方水的向下流動，等待桶中的一部分水漏走后，再放行上方水。

2）溢出的上方水直接拋棄。

特點

漏水的速率是固定的

即使存在注水burst（突然注水量變大）的情況，漏水的速率也是固定的

計數器

這個最簡單，比如用Redis做計數器

計數器算法是使用計數器在周期內累加訪問次數，當達到設定的限流值時，觸發限流策略。下一個周期開始時，進行清零，重新計數。此算法在單機還是分布式環境下實現都非常簡單，使用redis的incr原子自增性和線程安全即可輕松實現。

滑動窗口

滑動窗口協議是傳輸層進行流控的一種措施，接收方通過通告發送方自己的窗口大小，從而控制發送方的發送速度，從而達到防止發送方發送速度過快而導致自己被淹沒的目的。

簡單解釋下，發送和接受方都會維護一個數據幀的序列，這個序列被稱作窗口。發送方的窗口大小由接受方確定，目的在于控制發送速度，以免接受方的緩存不夠大，而導致溢出，同時控制流量也可以避免網絡擁塞。下面圖中的4,5,6號數據幀已經被發送出去，但是未收到關聯的ACK，7,8,9幀則是等待發送。可以看出發送端的窗口大小為6，這是由接受端告知的。此時如果發送端收到4號ACK，則窗口的左邊緣向右收縮，窗口的右邊緣則向右擴展，此時窗口就向前“滑動了”，即數據幀10也可以被發送。

參考如下網址提供的動態效果

https://media.pearsoncmg.com/aw/ecs_kurose_compnetwork_7/cw/content/interactiveanimations/selective-repeat-protocol/index.html

6.熔斷與限流的區別

在分布式系統中，限流和熔斷是處理并發的兩大利器。關于限流和熔斷，需要記住一句話，客戶端熔斷，服務端限流。

發現為什么是限流和熔斷？而不是限流和降級？所以下面我特地講一講他們的區別。

相似處：
1.目的一致

都是為了系統的穩定性，防止因為個別微服務的不可用而拖死整個系統服務；

2.表現類似

在表現上都是讓用戶感知，該服務暫時不可用請稍后再試；

3.粒度一致

粒度上，都是服務級別的粒度，某些情況下，也有更細的粒度，如數據的持久層，只允許查詢，不允許增刪改。

主要區別：
1.觸發條件不同

服務熔斷一般是某個服務掛掉了引起的，一般是下游服務，而服務降級一般是從整體的負荷考慮，主動降級；

2.管理目標的層次不同

熔斷其實是一個框架級的處理，每個微服務都需要，沒有層次之分，而降級一般需要對業務有層級之分，一般是從最外圍服務開始。

7.斷路器的隔離方式（線程池隔離以及信號量隔離）有什么區別

在斷路器中，介紹兩種處理高并發的解決方案。

首先需要理解高并發的情況下系統會出現什么樣的問題。

當部署完一個服務后，這個服務會向外界開放多個接口，比如一個爛大街的商城系統可能有訂單查詢接口，個人中心接口，付款接口，商品查詢接口。當服務部署好之后，沒有其他配置時， tomcat默認開啟一個線程池，這個線程池中有200個線程供使用。這時候，這四個接口都有對這個線程池的使用權，也就是說這四個接口共享一個線程池。當訪問量小的時候系統沒有問題，但是遇到突發情況，比如一類爆款商品降價，導致了商品查詢接口訪問量激增。商品查詢接口占用了線程池中大量的線程，導致其他三個接口搶不到線程從而沒有線程可用，這時候，由于四個接口共享一個線程池，當一個接口訪問量激增而占用大量資源時，導致其他三個接口搶不到資源進而導致自身功能不可用。

線程池隔離

這時候，提出一種解決方案–線程池隔離。

線程池隔離的思想是: 把tomcat中先一個線程池分成兩個線程池. 比如tomcat線程池中初始有200個線程, 分成兩個線程池A , B后, A線程池有50個線程可以用, B線程池有150個線程可以用. 將訪問量較大的接口單獨配置給一個線程池, 其他接口使用另一個線程池 , 使其訪問量激增時不要影響其他接口的調用.

然后, 將訪問量暴增的接口訪問交給A線程池, 其他接口的訪問交給B線程池. A , B兩個線程池是相互隔離的, 互不影響. 這時候, 如果商品查詢接口訪問量激增 , 被擠爆的線程池也只是A線程池, A,B線程池互不影響, 所以其他接口如: 個人中心接口, 付款接口, 訂單查詢接口依然可用.

線程池隔離主要針對C端用戶對服務的訪問. 線程池隔離起到分流的作用.

信號量隔離

還有一種是新思路是采用信號量隔離方式.

可以把信號量理解成一個計數器 , 對這個計數器規定一個計數上限, 代表一個接口被訪問的最大量.

假定設置付款接口的信號量最大值為10,(這個接口最多占用線程池中10個線程) 初始值為0. 每調用一次接口信號量加一 , 接口處理完后信號量減一. 當信號量值達到最大時 , (10時) , 對后續的調用請求拒接處理.

信號量隔離主要是針對各個服務內部的調用處理, 起到限流的作用.

8.API網關的工作流程

客戶端向Spring Cloud Gateway發出請求。如果網關處理程序映射（Gateway Handler Mapping）確定請求與路由匹配，則將其發送到網關Web處理程序（Gateway Web Handler）。該處理程序通過特定于請求的過濾器鏈來運行請求。過濾器器由虛線分隔的原因是，過濾器可以在發送代理請求之前和之后運行邏輯。所有“前置”過濾器邏輯均被執行。然后發出代理請求。發出代理請求后，將運行“后置”過濾器邏輯。圖中虛線左邊的對應于前置過濾器，虛線右邊的對應于后置過濾器。