面試集錦（八）分佈式與高併發

分佈式下的問題

1.session共享，使用redis存儲session信息，主從複製慢能夠在代碼中手動寫入

2.分佈式事務

兩階段提交協議

使用消息中間件

3.負載均衡

4.分佈式鎖

一致性hash算法

用處：分佈式緩存

算法描述：

先構造一個長度爲232的整數環（這個環被稱爲一致性Hash環），根據節點名稱的Hash值（其分佈爲[0, 232-1]）將服務器節點放置在這個Hash環上，而後根據數據的Key值計算獲得其Hash值（其分佈也爲[0, 232-1]），接着在Hash環上順時針查找距離這個Key值的Hash值最近的服務器節點，完成Key到服務器的映射查找。

避免hash傾斜性方法:引入虛擬節點

將一個物理節點拆分爲多個虛擬節點，而且同一個物理節點的虛擬節點儘可能均勻分佈在Hash環上

消息隊列的應用場景

1.異步處理（如發送短信）

2.應用解偶

3.流量銷峯（秒殺活動限流）

4.日誌處理

5.消息通信（點對點通訊或聊天室）

高併發下的性能優化

1.調整項目結構，增長服務器資源，集羣或分佈式，負載均衡

2.數據庫優化

3.代碼優化（使用多線程+算法優化）

4.合理使用緩存

5.html靜態化，圖片存於服務器

接口如何處理重複請求

前端控制：當用戶點擊按鈕後將按鈕disable掉，後端不返回數據時不可點擊

後端控制：uriPath+userId+MD5(JsonString(全部參數))做爲key,用redis分佈式鎖，用spring aop來實現，對resource method 作aop攔截

主要是利用惟一Token值與提交參數相匹配驗證。

接口限流算法

限流算法總結

1.計數器法（最簡單最容易實現）：假設要求某個接口一分鐘以內不能超過100個請求：設置一個count,每次請求count++，在count>100時判斷時間有沒有超過一分鐘，超過說明請求過多；若是沒超過說明還在範圍以內，那麼重置count

缺陷：在臨界值（如59秒時發送100個請求，在00時又發送100個請求，會認爲是兩個時間段，但其實2秒之間就會有200個請求，這樣很容易擊垮應用）

2.滑動窗口：將時間細分爲不少格，每過n秒向右移動n格，能夠避免上述問題

3.漏桶算法：設置一個容量固定的桶，流入的速率未知，流出去的速度恆定，多餘的水會溢出

優勢：使用了漏桶算法後咱們能夠保證接口會以一個常速速率來處理請求。

缺點：不能應對突發流量

4.令牌桶算法（使用最多）：設置一個容量固定的桶，裏面存放令牌（token）,以一個恆定的速率往桶裏放令牌，接口請求過來時，會從桶裏取出一個令牌，有令牌才能夠經過，沒有令牌時沒法經過，這就保證了接口的請求速率。

解決臨界值問題：就算在一瞬間令牌所有被取完了，可是往桶裏放令牌的速率是很慢的，這就保證了後面的請求不會在一瞬間經過。

分佈式下的限流能夠利用redis來實現

分佈式緩存：

分佈式緩存設計

緩存分級：本地緩存-->redis緩存-->tomcat堆緩存-->mybatis或DB緩存

分佈式下要特別考慮的問題：不能多個進程同時寫值，必須保證原子性，不能出現髒數據

redis緩存的負載策略：建議首先採用一致性hash算法（能夠保證相同的請求會打在同一臺服務器上，而且不隨擴容而下降），當到達必定的閾值後切換爲輪詢算法，這樣既能保證緩存命中又能保證服務的高可用