技術面試問題總結二

一、lvs的四種工作模式:

LVS 有四種主要工作模式：NAT 模式、DR 模式、TUN 模式和Full-NAT 模式

1、NAT模式：

工作原理

LVS 作為客戶端和真實服務器（RS）之間的中間節點，接收客戶端請求后，修改請求的目標 IP 地址（改為 RS 的 IP），并轉發給 RS。
RS 處理請求后，直接將響應返回給 LVS（需配置網關為 LVS），LVS 再修改響應的源 IP 地址（改回 VIP），返回給客戶端。

關鍵特點

單一 IP 暴露：客戶端只看到 LVS 的虛擬 IP（VIP），RS 的真實 IP 對客戶端透明。
請求和響應都經過 LVS：LVS 成為流量瓶頸（尤其在大流量場景下）。
RS 必須與 LVS 在同一網段：RS 的網關需指向 LVS。

優點

實現簡單，無需對 RS 進行特殊配置。
支持跨網段部署（只要 LVS 能訪問 RS）。

缺點

LVS 需處理雙向流量，性能受限。
RS 數量不宜過多（通常幾十臺以內）。

應用場景：

????????小規模負載均衡，如企業內部應用；安全性要求高，需隱藏 RS 真實 IP。

2、DR模式

工作原理

LVS 接收客戶端請求后，不修改 IP 頭部，而是在數據鏈路層修改 MAC 地址（將目標 MAC 改為 RS 的 MAC），直接轉發給 RS。
RS 處理請求后，直接將響應返回給客戶端（無需經過 LVS），通過配置 VIP 別名實現。

關鍵特點

請求經過 LVS，響應直接返回客戶端：LVS 僅處理入站流量，性能顯著提升。
所有設備需在同一物理網段：依賴二層轉發（如交換機），跨網段需特殊配置。
RS 需配置 VIP 別名：但 RS 不會將 VIP 作為默認網關。

優點

性能高，適用于大流量場景（如電商、視頻網站）。
LVS 負載壓力小，可支持更多 RS。

缺點

部署復雜度高（需配置 ARP 抑制）。
跨網段支持有限。

應用場景

????????高并發場景，如大型網站、API 網關；需處理大量請求的后端服務（如 MySQL 集群）。

3、TUN模式

工作原理

LVS 接收客戶端請求后，不修改原始 IP 包，而是封裝一個新的 IP 頭部（外層 IP 目標為 RS），通過 IP 隧道轉發給 RS。
RS 解封裝后處理請求，直接將響應返回給客戶端（無需經過 LVS），同樣需配置 VIP 別名。

關鍵特點

請求經過 LVS，響應直接返回客戶端：與 DR 模式類似，但通過 IP 隧道實現，支持跨地域部署。
RS 需支持 IP 隧道協議（如 IPIP），并配置 VIP 別名。
網絡拓撲靈活：RS 可分布在不同地理位置。

優點

支持跨地域負載均衡（如多地數據中心）。
性能高，LVS 僅處理入站流量。

缺點

隧道封裝增加網絡開銷。
RS 配置復雜（需支持隧道協議）。

應用場景

????????跨地域分布式系統（如 CDN 節點負載均衡）；云服務提供商的負載均衡架構。

4、三種模式對比表格

維度	NAT 模式	DR 模式	TUN 模式
轉發機制	修改 IP 地址	修改 MAC 地址	IP 隧道封裝
流量路徑	請求和響應都經過 LVS	請求經 LVS，響應直接回客戶端	同 DR 模式
網絡要求	RS 與 LVS 需在同一網段	所有設備需在同一物理網段	支持跨地域部署
RS 配置	網關指向 LVS	配置 VIP 別名，ARP 抑制	支持 IP 隧道，配置 VIP 別名
性能	較低（雙向流量）	高（單向流量）	較高（單向流量，但有封裝開銷）
典型場景	小規模內部應用	大型網站、高并發服務	跨地域分布式系統

?5、Full-NAT 模式（補充）

工作原理：LVS 同時修改請求的源 IP（改為 LVS 的 IP）和目標 IP（改為 RS 的 IP），RS 響應時直接返回給 LVS，再由 LVS 轉發給客戶端。
特點：支持 RS 與 LVS 不在同一網段，但性能低于 DR 和 TUN 模式，適用于特殊網絡環境。

綜合選擇：

小流量、簡單部署：選 NAT 模式。
大流量、同網段：選 DR 模式（性能最優）。
跨地域、分布式：選 TUN 模式。
特殊網絡環境：選 Full-NAT 模式。

二、代理和負載均衡的區別

維度	代理（Proxy）	負載均衡（Load Balancer）
核心目標	中間轉發、隔離網絡、功能增強（如緩存、過濾）	分配流量到多臺服務器，提高可用性和吞吐量
處理對象	通常針對單條連接或一類請求的轉發邏輯	針對多個后端節點的流量分配策略
典型場景	跨網絡訪問（如 VPN 代理）、內容過濾、緩存加速	分布式系統、高并發服務（如電商網站、API 集群）

代理（Proxy）：中間轉發與功能增強

代理是位于客戶端和目標服務器之間的中間服務器，客戶端的請求先發送到代理，再由代理轉發給目標服務器，響應則反向傳遞。其核心作用是 “代表客戶端訪問目標”，并可附加額外功能。

核心功能：

????????流量轉發：跨網絡（如內部網絡→外部網絡）或跨協議（如 HTTP→HTTPS）轉發請求。

????????網絡隔離：隱藏客戶端或服務器的真實地址（如反向代理隱藏服務器 IP）。

????????功能增強：緩存數據、過濾內容（如廣告攔截）、身份驗證、加密傳輸等。

分類與舉例：

正向代理：代理客戶端，幫助客戶端訪問無法直接訪問的資源。
????????舉例：科學上網工具（如 Shadowsocks）：客戶端通過代理服務器訪問外網，目標服務器只看到代理的 IP，看不到客戶端真實 IP。

反向代理：代理服務器，客戶端不知道目標服務器的存在，請求先到反向代理，再由其轉發給后端服務器。
????????舉例：Nginx 作為反向代理：用戶訪問www.example.com時，請求先到 Nginx，Nginx 再轉發給后端的 Tomcat 服務器，用戶感知不到 Tomcat 的存在。Nginx 還可在此過程中緩存靜態資源（如圖片、CSS），減少后端壓力。

負載均衡（Load Balancer）：流量分配與高可用

負載均衡是將客戶端的請求 “均勻分配” 到多個后端服務器的技術，避免單臺服務器過載，提高系統的可用性和吞吐量。其核心作用是“分流”，確保服務穩定運行。

核心功能：

????????流量分配：根據策略（如輪詢、權重、IP 哈希）將請求分發到不同服務器。

????????健康檢查：監測后端服務器狀態，自動剔除故障節點。

????????擴展性支持：通過增加服務器節點提升系統容量，無需修改客戶端配置。

舉例：

????????電商網站集群：某電商平臺有 3 臺服務器處理訂單請求，負載均衡器（如 F5 硬件負載均衡器）接收用戶的下單請求后，按 “輪詢” 策略依次分配給 3 臺服務器，避免單臺服務器因請求過多崩潰。若其中 1 臺服務器故障，負載均衡器會自動將請求轉發給另外 2 臺，確保服務不中斷。

????????云服務負載均衡：AWS 的 ELB（彈性負載均衡）：當用戶訪問一個高并發 API 時，ELB 會根據后端 EC2 實例的負載（如 CPU 使用率）動態分配請求，負載高的實例會被分配更少的流量。

區別：

????????目標不同：代理的核心是 “轉發 + 附加功能”（如隔離、緩存）；負載均衡的核心是 “分流 + 高可用”。

????????處理對象不同：代理可針對單臺后端服務器（如反向代理僅轉發到特定服務器）；負載均衡必須面對多臺后端服務器，目標是 “分配流量”。

????????依賴關系：負載均衡器通常會集成反向代理功能（如 Nginx 既可以做反向代理，也可以做負載均衡），但代理不一定具備負載均衡能力（如正向代理僅轉發到單一目標）。

????????代理更側重 “中間層的功能擴展”，而負載均衡更側重 “多服務器的流量分配”，兩者在復雜架構中常結合使用（如負載均衡器先接收流量，再通過反向代理轉發到具體服務器）

三、MySQL B+樹與跳表對比

數據結構本質

跳表：通過在鏈表上增加多層 “快速通道” 來加速查詢。每個節點的層級由隨機函數決定。

4層: 1 ----------------------------> 7

3層: 1 ---------> 3 ----------------> 7

2層: 1 ----> 2 ---> 3 ----> 5 -----> 7

1層: 1 -> 2 -> 3 -> 4 -> 5 -> 6 -> 7 （原始鏈表）

B + 樹：所有數據都存儲在葉子節點，非葉子節點僅用于索引。

磁盤 I/O 優化

跳表：節點隨機分布，導致磁盤訪問分散，每次查詢可能產生多次隨機 I/O。

B + 樹：

????????節點大小設計為與磁盤頁（通常 4KB）對齊，一次 I/O 能讀取一個完整節點。

????????非葉子節點不存儲數據，可容納更多索引項，減少樹的高度。

????????例如：一個高度為 3 的 B + 樹可存儲約 10 億條記錄，但只需 3 次 I/O。

范圍查詢效率

????????跳表：從起始節點開始逐層下降，然后在底層鏈表中順序遍歷。例如查詢 [3,7]：

????????從頂層找到3 → 下降到第1層 → 遍歷3→4→5→6→7

????????B + 樹：直接定位到左邊界，通過葉子節點的鏈表指針順序訪問。例如：

????????找到3 → 通過鏈表指針依次訪問4,5,6,7

并發性能

跳表：使用 CAS（Compare-And-Swap）操作實現無鎖插入 / 刪除。

????????例如：Redis 的有序集合在并發環境下表現優異。

B + 樹：需要實現復雜的鎖機制（如 InnoDB 的意向鎖、行鎖）。

????????寫操作可能導致整頁鎖定，影響并發度。

總結

????????跳表是內存場景下的高效選擇，尤其適合高并發、小規模數據。

????????B+樹是磁盤存儲的標準方案，通過優化磁盤 I/O 提升整體性能。

????????MySQL 的 InnoDB 存儲引擎選擇 B + 樹作為索引結構，正是為了適應磁盤存儲的特性。而 Memory 引擎則可能使用跳表實現內存索引。

四、什么是三次握手四次揮手？tcp為什么要三次握手？

為了防止已失效的連接請求報文段突然又傳送到了服務端，因而產生錯誤

三次握手

第一次握手：建立連接時，客戶端發送syn包(syn=j)到服務器，并進入SYN_SEND狀態，等待服務器確認；

第二次握手：服務器收到syn包，必須確認客戶的SYN（ack=j+1），同時自己也發送一個SYN包（syn=k），即SYN+ACK包，此時服務器進入SYN_RECV狀態；

第三次握手：客戶端收到服務器的SYN＋ACK包，向服務器發送確認包ACK(ack=k+1)，此包發送完畢，客戶端和服務器進入ESTABLISHED狀態，完成三次握手。

完成三次握手，客戶端與服務器開始傳送數據

客戶端先發送FIN，進入FIN_WAIT1狀態，用來關閉Client到Server的數據傳送

服務端收到FIN，發送ACK，進入CLOSE_WAIT狀態，客戶端收到這個ACK，進入FIN_WAIT2狀態

服務端發送FIN，進入LAST_ACK狀態，用來關閉Server到Client的數據傳送

客戶端收到FIN，發送ACK，進入TIME_WAIT狀態，服務端收到ACK，進入CLOSE狀態（等待2MSL時間，約4分鐘。主要是防止最后一個ACK丟失。）

四次揮手

第一次揮手：主動關閉方發送一個FIN，用來關閉主動方到被動關閉方的數據傳送，也就是主動關閉方告訴被動關閉方：我已經不會再給你發數據了(當然，在fin包之前發送出去的數據，如果沒有收到對應的 ack確認報文，主動關閉方依然會重發這些數據)，但是，此時主動關閉方還可以接受數據。

第二次揮手：被動關閉方收到FIN包后，發送一個ACK給對方，確認序號為收到序號+1（與SYN相同，一個FIN占用一個序號）。

第三次揮手：被動關閉方發送一個FIN，用來關閉被動關閉方到主動關閉方的數據傳送，也就是告訴主動關閉方，我的數據也發送完了，不會再給你發數據了。

第四次揮手：主動關閉方收到FIN后，發送一個ACK給被動關閉方，確認序號為收到序號+1，至此，完成四次揮手。

五、TCP和UDP的區別以及應用場景

1、概念

TCP（傳輸控制協議）和 UDP（用戶數據報協議）是 TCP/IP 協議族中兩種核心的傳輸層協議，它們在數據傳輸方式、可靠性、效率等方面存在顯著差異，適用于不同的應用場景。

傳輸層的核心作用

提供進程間通信：通過端口號（如 HTTP 的 80 端口、SSH 的 22 端口）區分同一主機上的不同應用程序，實現進程間的數據傳輸。
可靠性控制：
TCP 通過確認機制、重傳機制、流量控制等保證可靠傳輸。
UDP 不提供可靠性，僅盡最大努力交付數據。

數據分段與重組：將上層（應用層）的報文分割為適合傳輸的段（Segment），或在接收端將接收到的段重組為完整數據。

對比其他層

網絡層（Network Layer）：如 IP 協議，負責將數據包從源主機傳輸到目標主機，但不保證可靠性和順序。
應用層（Application Layer）：如 HTTP、SMTP、DNS 等，直接為用戶應用程序提供服務。
鏈路層（Link Layer）：負責物理網絡的幀傳輸，如以太網、Wi-Fi 等。

2、核心對比

對比維度	TCP	UDP
連接方式	面向連接（需三次握手建立連接，四次揮手關閉）	無連接（直接發送數據，無需建立 / 關閉連接）
可靠性	可靠傳輸（通過確認機制、重傳機制、流量控制等保證數據不丟失、不重復、按序到達）	不可靠傳輸（無確認 / 重傳機制，數據可能丟失、亂序）
數據邊界	無（數據被視為字節流，接收方需自行劃分邊界）	有（數據以數據報為單位，發送和接收的邊界一致）
擁塞控制	支持（通過慢啟動、擁塞避免等算法調整發送速率，適應網絡負載）	不支持（發送速率不受網絡狀態影響，可能加劇擁塞）
傳輸效率	較低（因連接建立、確認、重傳等機制，開銷大）	較高（無額外控制機制，頭部開銷小，傳輸速度快）
適用數據量	適合大量數據傳輸（如文件、視頻流）	適合少量數據傳輸（如實時指令、消息）

3、應用場景分析

1. TCP 的典型應用場景

TCP 的可靠性使其適用于對數據準確性要求高、允許一定延遲的場景：

文件傳輸：如 FTP（文件傳輸協議）、HTTP/HTTPS（網頁傳輸）。文件傳輸需保證數據完整，不能丟失或損壞，TCP 的重傳機制可確保這一點。
郵件發送：如 SMTP（簡單郵件傳輸協議）。郵件內容的完整性和順序至關重要，TCP 能避免郵件內容錯亂或丟失。
遠程登錄：如 SSH（安全外殼協議）、Telnet。遠程操作指令需要準確執行，TCP 的按序傳輸可保證指令順序正確。
數據庫交互：如 MySQL 的 TCP 連接。數據庫查詢和修改需確保數據一致性，TCP 的可靠性可防止數據同步錯誤。

2. UDP 的典型應用場景

UDP 的高效性使其適用于對實時性要求高、可容忍少量數據丟失的場景：

實時通信：如視頻通話（Skype）、語音通話（VoIP）。實時傳輸中，延遲比偶爾的數據包丟失更影響體驗，UDP 的低延遲特性更適合。
流媒體播放：如直播（RTSP/RTP 協議常用 UDP）。直播中，丟失個別幀不會影響整體觀看，但若用 TCP 可能因重傳導致畫面卡頓。
游戲數據傳輸：如多人在線游戲的實時位置、操作指令。游戲需要低延遲響應，少量數據包丟失可通過本地預測補償，而 TCP 的重傳可能導致操作延遲。
物聯網通信：如傳感器數據上報（CoAP 協議）。傳感器數據通常周期性發送，少量丟失不影響整體分析，UDP 的低開銷更適合資源有限的設備。
DNS 查詢：域名解析（DNS 協議）通常用 UDP。查詢數據量小，且即使丟失可快速重發，UDP 的高效性能縮短解析時間。

4、總結

TCP是 “可靠但低效” 的協議，適合需要保證數據完整性的場景，如文件傳輸、郵件、數據庫交互等。
UDP是 “高效但不可靠” 的協議，適合需要低延遲、可容忍少量丟失的場景，如實時音視頻、游戲、物聯網等。

六、用戶輸入網址到響應界面操作中間發生了什么？

1、DNS 解析：將域名轉換為 IP 地址

瀏覽器緩存檢查：瀏覽器首先檢查本地緩存中是否有該域名對應的 IP 地址（緩存時間由 DNS 記錄的 TTL 值控制）。
系統緩存檢查：若瀏覽器緩存未命中，則檢查操作系統的 hosts 文件或本地 DNS 緩存（如 Windows 的 DNS Client 服務）。
本地 DNS 服務器查詢：若仍未命中，請求本地 DNS 服務器（通常由 ISP 提供）。本地 DNS 服務器會先檢查自身緩存，若沒有則進行遞歸查詢。
遞歸查詢流程：
- 根 DNS 服務器（.com、.cn 等頂級域名服務器的地址）。
- 頂級域 DNS 服務器（如.com 域名服務器）。
- 權威 DNS 服務器（如example.com的具體 DNS 服務器）。
獲取 IP 地址：最終從權威 DNS 服務器獲取目標網站的 IP 地址，并逐級返回給瀏覽器。

2、TCP 連接：建立與服務器的可靠通信

TCP 三次握手：
- 客戶端發送 SYN 包，請求建立連接，并攜帶初始序列號（ISN）。
- 服務器返回 SYN+ACK 包，確認請求并發送自己的初始序列號。
- 客戶端發送 ACK 包，完成連接建立。
TCP 參數協商：雙方協商 MSS（最大段大小）、窗口大小等參數，優化數據傳輸。

3、HTTP 請求：發送網頁資源請求

構建 HTTP 請求報文：包含請求行（如 GET /index.html HTTP/1.1）、請求頭（如 User-Agent、Cookie 等）和請求體（如 POST 請求的數據）。
HTTPS 額外步驟（若啟用）：
- TLS 握手：協商加密算法、驗證服務器證書、生成會話密鑰。
- 數據加密：后續 HTTP 數據通過對稱加密傳輸。

4、服務器處理請求

負載均衡（若存在）：請求先到達負載均衡器（如 Nginx、AWS ELB），被轉發到合適的后端服務器。
Web 服務器接收請求：如 Apache、Nginx 處理 HTTP 請求，解析請求頭和 URL。
應用服務器處理：
- 靜態資源：直接返回文件（如 HTML、CSS、JS）。
- 動態資源：調用應用程序（如 PHP、Python、Java）生成響應。
數據庫交互（若需要）：應用程序查詢數據庫獲取數據（如用戶信息、文章內容）。
生成 HTTP 響應：包含狀態碼（如 200 OK、404 Not Found）、響應頭（如 Content-Type、Cache-Control）和響應體（網頁內容）。

5、HTTP 響應：返回數據到客戶端

服務器發送響應：將 HTTP 響應通過 TCP 連接返回給客戶端。
客戶端接收響應：
- 解析響應頭：獲取內容類型、緩存策略等信息。
- 處理壓縮數據：若內容被壓縮（如 gzip），先解壓。

6、瀏覽器解析渲染頁面

解析 HTML：構建 DOM 樹（文檔對象模型）。
資源加載：
- 解析 HTML 中的資源引用（如 CSS、JS、圖片）。
- 并行請求這些資源（HTTP/1.1 通過多個 TCP 連接，HTTP/2 通過多路復用）。
構建 CSSOM：解析 CSS 文件，構建 CSS 對象模型。
合并渲染樹：將 DOM 樹和 CSSOM 合并為渲染樹（只包含可見元素）。
布局（Layout）：計算每個元素在屏幕上的位置和大小。
繪制（Painting）：將渲染樹轉換為屏幕上的像素。
合成（Compositing）：處理層疊和動畫，優化渲染性能。

7、TCP 連接關閉（可選）

四次揮手：
- 客戶端發送 FIN 包，表示請求關閉發送方向。
- 服務器返回 ACK 包，確認關閉請求。
- 服務器發送 FIN 包，表示請求關閉接收方向。
- 客戶端返回 ACK 包，確認關閉請求。
連接復用：HTTP/1.1 默認使用持久連接（Connection: keep-alive），多個請求可復用同一個 TCP 連接；HTTP/2 進一步優化了連接復用效率。

概括總結如下：

DNS 解析：瀏覽器將域名（如www.example.com）轉換為服務器 IP 地址（如 192.168.1.1）。
建立連接：通過 TCP 三次握手與服務器建立連接（若為 HTTPS，還需額外完成 TLS 加密握手）。
發送請求：瀏覽器向服務器發送 HTTP 請求（如獲取首頁內容）。
服務器響應：服務器處理請求后，返回 HTTP 響應（包含網頁 HTML、CSS、JS 等數據）。
渲染頁面：瀏覽器解析響應內容，構建 DOM 樹和樣式，最終渲染出可視化頁面。
關閉連接：完成后通過 TCP 四次揮手關閉連接（或復用連接處理后續請求）。

七、redis的緩存穿透、緩存擊穿、緩存雪崩

1、什么是redis

????????redis是一個單線程的支持網絡、可基于內存也可持久化的日志型、K-V數據庫，并提供多種語言的API。支持多種的數據類型：string hash 列表、集合等，支持事務讀寫速度非常快

2、緩存穿透

2.1描述：

????????用戶想要查詢某個數據，在 Redis 中查詢不到，即沒有緩存命中，這時就會直接訪問數據庫進行查詢。當請求量超出數據庫最大承載量時，就會導致數據庫崩潰。這種情況一般發生在非正常 URL 訪問，目的不是為了獲取數據，而是進行惡意攻擊。

2.2現象：

????????1、應用服務器壓力變大

????????2、Redis緩存命中率降低

????????3、一直查詢數據庫

2.3原因：

????????一個不存在緩存及查詢不到的數據，由于緩存是不命中時被動寫的，并且出于容錯考慮，如果從存儲層查不到數據則不寫入緩存，這將導致這個不存在的數據每次請求都要到存儲層去查詢，失去了緩存的意義。

2.4解決方法：

????????① 對空值緩存：如果一個查詢數據為空（不管數據是否存在），都對該空結果進行緩存，其過期時間會設置非常短。

????????② 設置可以訪問名單：使用bitmaps類型定義一個可以訪問名單，名單id作為bitmaps的偏移量，每次訪問時與bitmaps中的id進行比較，如果訪問id不在bitmaps中，則進行攔截，不允許訪問。

????????③ 采用布隆過濾器：布隆過濾器可以判斷元素是否存在集合中，他的優點是空間效率和查詢時間都比一般算法快，缺點是有一定的誤識別率和刪除困難。

????????④ 進行實時監控：當發現 Redis 緩存命中率急速下降時，迅速排查訪問對象和訪問數據，將其設置為黑名單。

3、緩存擊穿

3.1描述

????????key中對應數據存在，當key中對應的數據在緩存中過期，而此時又有大量請求訪問該數據，由于緩存中過期了，請求會直接訪問數據庫并回設到緩存中，高并發訪問數據庫會導致數據庫崩潰。

3.2現象

????????1、數據庫訪問壓力瞬時增加

????????2、Redis中沒有出現大量 Key 過期

????????3、Redis正常運行

????????4、數據庫崩潰

3.3原因：

????????由于 Redis 中某個 Key 過期，而正好有大量訪問使用這個 Key，此時緩存無法命中，因此就會直接訪問數據層，導致數據庫崩潰。最常見的就是非常“熱點”的數據訪問。

3.4解決方法

????????① 預先設置熱門數據：在redis高峰訪問時期，提前設置熱門數據到緩存中，或適當延長緩存中key過期時間。

????????② 實時調整：實時監控哪些數據熱門，實時調整key過期時間。

????????③ 對于熱點key設置永不過期。

4、緩存雪崩

4.1描述

????????key中對應數據存在，在某一時刻，緩存中大量key過期，而此時大量高并發請求訪問，會直接訪問后端數據庫，導致數據庫崩潰。

4.2現象

數據庫壓力變大導致數據庫和 Redis 服務崩潰

4.3原因

????????短時間內大量的key過期，恰好大量的訪問使用這些過期的key，此時緩存無法命中，導致大量的請求直接打到數據庫中，導致宕機。

4.4解決方法

????????① 構建多級緩存機制：nginx緩存 + redis緩存 + 其他緩存。

????????② 設置過期標志更新緩存：記錄緩存數據是否過期，如果過期會觸發另外一個線程去在后臺更新實時key的緩存。

????????③ 將緩存可以時間分散：如在原有緩存時間基礎上增加一個隨機值，這個值可以在1-5分鐘隨機，這樣過期時間重復率就會降低，防止大量key同時過期。

????????④ 使用鎖或隊列機制：使用鎖或隊列保證不會有大量線程一次性對數據庫進行讀寫，從而避免大量并發請求訪問數據庫，該方法不適用于高并發情況。