1.分布式系統下如何實現服務限流

• 核心算法：
  • 固定窗口：將時間劃分為固定窗口（如 1 秒），統計窗口內請求數，超過閾值則限流。實現簡單但存在臨界值突發流量問題。
  • 滑動窗口：將固定窗口拆分為多個小窗口，滑動計算請求數，緩解臨界問題，但實現復雜度較高。
  • 漏桶算法：控制請求處理速率恒定，平滑流量，但無法應對突發流量。
  • 令牌桶算法：按固定速率生成令牌，請求需獲取令牌才能處理，支持突發流量且靈活，是主流選擇。
• 實現方式：
  • 單機限流：如 Guava 的RateLimiter（基于令牌桶）、Nginx 的limit_req模塊。
  • 分布式限流：基于 Redis 實現（如用INCR統計請求數，結合過期時間模擬窗口；或用 Lua 腳本實現令牌桶），保證集群限流一致性。
• 應用場景：根據業務需求選擇算法（如秒殺場景用令牌桶應對突發流量），并在網關層、服務層多維度限流。

2. 訂單未支付過期自動關單方案

3. 秒殺系統設計

3.1 架構原則 “4 要 1 不要”

• 數據要少（減少傳輸與處理數據）、請求要少（合并 CSS/JS 等）、路徑要短（減少中間節點）、依賴要少（區分強弱依賴）、不要有單點（服務無狀態化）。

3.2 核心優化策略

• 動靜分離：拆分靜態數據（如商品標題）與動態數據（如庫存），靜態數據緩存至 CDN、瀏覽器，提升訪問效率。
• 熱點處理：識別靜態熱點（報名篩選）與動態熱點（實時上報），通過緩存、限制、隔離（業務 / 系統 / 數據隔離）優化。
• 流量削峰：用消息隊列緩沖、答題延緩請求、分層過濾（CDN→前臺→后臺→數據庫）減少無效請求。
• 減庫存設計：可選 “下單減庫存”（防超賣）、“付款減庫存”（可能超賣）、“預扣庫存”（保留時間 + 自動釋放），需保證數據一致性（如數據庫字段設為無符號整數）。

4. 高并發系統設計（QPS 提升 10 倍）

• 硬件與架構：水平擴容、微服務拆分（降低耦合）。
• 通信優化：用 Dubbo 等 RPC 框架（性能是 Feign 的 10 倍），自帶負載均衡、熔斷降級。
• 中間件支撐：消息隊列（削峰解耦）、三級緩存（本地緩存 + 分布式緩存 + 數據庫）。
• 數據庫優化：讀寫分離、分庫分表（按用戶 ID / 業務分片）。
• 高可用策略：熔斷（隔離故障服務）、限流（控制請求量）、降級（弱依賴失效時保障核心流程）、預案與核對機制。

5. 其他核心系統設計要點

• 會員系統：ES 雙中心主備集群（高可用）+ Redis 緩存（性能）+ MySQL 分庫分表（存儲），解決高并發查詢與數據一致性。
• 優惠券系統：分庫分表應對存儲瓶頸，拆分子庫存解決熱點問題，本地緩存優化模板獲取，支撐 10 萬級 QPS。
• 短 URL 生成器：預生成短 URL（Base64 編碼），用 HDFS 存儲、Redis 緩存，支持百億級規模與數萬并發。
• 分布式鏈路跟蹤：通過 TraceID 串聯請求鏈路，記錄各環節日志，用 ELK 棧分析，定位性能瓶頸。

6. 關鍵技術問題解決方案

• 庫存超賣：用 Redis 原子操作（decr）、令牌桶（預生成庫存令牌）、自旋鎖或 CAS 樂觀鎖控制并發修改。
• 數據庫選擇：高并發場景不推薦關系數據庫（B + 樹索引 IO 成本高），可選用 LSM 樹或列存儲數據庫。
• 同城多活：用 Otter 工具基于 binlog 同步數據，支持雙機房故障自動切換，保障數據一致性。

7. 架構設計原則

• 分層設計：隔離關注點（表現層、邏輯層、數據層），便于復用與擴展。
• 動靜分離：靜態數據緩存至 CDN / 本地，動態數據按需加載，減少服務端壓力。
• 限流熔斷：通過令牌桶 / 漏桶算法限流，熔斷故障依賴，保障系統在流量峰值下的可用性。

8. 短 URL 生成器設計

• 核心需求：將長 URL 轉換為短 URL（如http://1.cn/ScW4dt），支持百億級規模管理和數萬級并發吞吐量，需解決無沖突、高并發訪問及海量存儲問題。
• 實現方案：
  • 短 URL 生成：采用預生成策略，通過隨機數生成 6 個字符的短 URL（Base64 編碼），利用布隆過濾器檢查沖突，預生成 144 億條（含 20% 冗余）存儲于 HDFS。
  • 架構設計：用戶請求經負載均衡到短 URL 服務器，生成短 URL 時從預加載服務器的內存中獲取，同時將映射關系存入 HBase；訪問短 URL 時優先查 Redis 緩存，未命中則查 HBase 并更新緩存。
  • 過期處理：每月清理過期（2 年）短 URL，回收資源并重寫入預生成文件。

9. 支持萬億 GB 網盤系統（DBox）設計

• 核心功能：文件上傳下載（支持斷點續傳）、文件共享、秒傳、限流（向付費用戶傾斜資源）。
• 關鍵技術：
  • 存儲架構：元數據（用戶信息、文件屬性等）存于分庫分表的 MySQL，文件內容切分為 4MB 塊存儲于 Ceph 對象存儲，實現元數據與內容分離管理。
  • 秒傳實現：通過文件 MD5、前 256KB MD5 及文件長度三重校驗，若文件已存在則僅建立關聯，不重復上傳。
  • 限流策略：根據用戶類型（免費 / VIP）限制并發連接數、線程數及傳輸速率，保障付費用戶體驗。

10. 支持 3 千萬用戶同時在線的短視頻系統（QuickTok）設計

• 核心挑戰：應對高并發訪問的帶寬壓力（總帶寬 88Tb）及海量存儲（年新增 5200PB）。
• 架構設計：
  • 上傳流程：用戶上傳視頻經負載均衡到上傳微服務，暫存文件后觸發消息隊列，視頻處理器進行合規審查、轉碼等操作，最終存入 HDFS 和 CDN。
  • 播放優化：采用 CDN 分發，對粉絲超 10 萬的大 V 視頻主動推送至粉絲活躍區域的 CDN 節點，僅推送部分片段（基于完播率），降低帶寬壓力。
  • 縮略圖推薦：結合大數據和機器學習，生成吸引用戶的縮略圖，通過實時推薦和離線訓練優化點擊率。

11. 基于 LBS 的交友系統（Liao）地理空間鄰近算法

• 核心需求：為 10 億用戶快速匹配鄰近用戶，需高效計算用戶間距離。
• 算法選擇：
  • 排除方案：SQL 鄰近算法（效率低）、地理網格算法（精度不足）、動態網格算法（實現復雜）。
  • 最終方案：GeoHash 算法，將經緯度編碼為 5 個字符（網格約 25km2），存儲于 Hash 表（key 為 GeoHash 值，value 為用戶 ID 列表）。查詢時先匹配當前網格用戶，不足時擴展至周邊 8 個網格，計算實際距離后返回結果。

12. 搜索引擎（Bingoo）設計

• 核心功能：全網內容爬取、索引構建、快速檢索及結果排序。
• 關鍵組件：
  • 分布式爬蟲：爬取網頁存儲于 HDFS，壓縮后按固定格式（含 docID、URL、內容）存儲。
  • 索引構建：生成 “docID→單詞列表” 正排索引，再轉換為 “單詞→docID 列表” 倒排索引，通過 64 個索引桶并行處理提升效率。
  • 排序算法：采用 PageRank 算法，根據網頁鏈接關系打分，結合用戶搜索詞相關性排序，確保結果準確性。

13. 微博系統（Weitter）應對熱點事件的突發訪問壓力

• 核心功能：發微博、關注好友、刷微博（支持 10 萬 QPS），需處理大 V 熱點消息引發的高并發。
• 優化策略：
  • 推拉結合的信息流模式：在線用戶采用推模式（實時更新好友微博列表），離線用戶采用拉模式（登錄時重建列表），平衡讀寫壓力。
  • 緩存設計：緩存 7 天內微博（約 700G），大 V 用戶 48 小時內微博本地緩存，減少數據庫訪問。
  • 數據庫分片：按用戶 ID 分片，避免大 V 數據集中導致的熱點問題，限制用戶日發微博上限（50 條）。

14. 限流器（Diana）設計

• 核心功能：部署于網關，對超限流規則的請求返回 503 響應，支持全局限流、賬號 / 設備 / 資源限流。
• 限流算法：
  • 固定窗口：簡單但可能短時間放過兩倍請求，適合非核心場景。
  • 滑動窗口：拆分時間片滑動計算，避免固定窗口缺陷，精度更高。
  • 漏桶算法：控制請求處理速率，但會浪費空閑資源，適合特殊場景。
  • 令牌桶算法：默認算法，可在系統空閑時累積令牌，高效利用資源，支持突發流量。

15. 敏感數據加解密平臺（Venus）設計

• 核心需求：保障敏感數據（手機號、密碼等）存儲和傳輸安全，解決密鑰分散、版本管理混亂等問題。
• 安全策略：
  • 密鑰管理：密鑰分片存儲于異構服務器（文件服務器 + 數據庫），需多角色協同才能獲取完整密鑰，避免泄露。
  • 加解密流程：應用通過 SDK 調用服務，SDK 緩存密鑰和算法，首次調用需從服務端獲取，保障性能和可靠性。
  • 版本控制：支持多版本密鑰，加密時嵌入版本信息，解密時根據版本獲取對應密鑰，避免密鑰升級導致的數據不可解。

16. 支持 5 億用戶的網約車系統（Udi）設計

• 核心規模：日活乘客 5 千萬、司機 2 千萬，日訂單 6 千萬，需處理長連接和實時派單。
• 關鍵模塊：
  • 長連接管理：司機 App 通過 TCP 長連接每秒上傳位置，由 TCP 管理服務器分配連接節點，用 Redis 記錄連接關系，確保消息準確推送。
  • 派單算法：基于 Redis GeoHash 計算乘客附近司機，結合地理系統規劃路徑，聚合 3 秒內訂單批量派單，最小化整體等待時間。
  • 訂單狀態模型：覆蓋 “創單→派單中→已派單→行程中→待支付→已完成” 全生命周期，確保流程無遺漏。

17. 雙十一預約搶購系統設計

• 核心階段：商品預約、等待搶購、商品搶購、訂單支付。
• 技術方案：
  • 預約階段：用 Redis 分布式鎖控制資格發放，避免超量。
  • 等待階段：頁面靜態化并緩存于 CDN，對動態接口限流（如 Nginx 模塊），應對流量突增。
  • 搶購階段：消息隊列削峰，Redis 預扣庫存，訂單表分庫分表，避免數據庫壓力過大。
  • 支付階段：支付回調后異步更新訂單狀態，用本地消息表確保積分累計等非核心流程的最終一致性。

18. 千萬級流量架構設計

• 前端優化：減少請求（合并 CSS/JS、圖片）、頁面靜態化（CDN 緩存）、邊緣計算（CDN 節點提供計算能力）。
• 后端優化：
  • 網絡層面：專線和 CDN 優化，減少延遲。
  • 架構層面：動靜分離、集群部署、數據隔離、服務拆分、異步驅動（消息隊列）。
  • 性能保障：明確指標（如 100 萬并發內 TP99=2s）、限流保護、快速擴容（3 分鐘內完成）、全流程性能優化。

19. 支持 10 萬 QPS 的 RPC 框架設計

• 性能優化：
  • 網絡傳輸：采用多路 I/O 復用模型（如 epoll），開啟 tcp_nodelay 關閉 Nagle 算法，減少延遲。
  • 序列化方式：優先選擇 Protobuf/Thrift（性能高、跨語言），JSON 適合低要求場景。
  • 調用流程：客戶端序列化請求→網絡傳輸→服務端反序列化并調用→返回結果，優化每個環節的耗時。

20. 藍綠發布實現

• 核心目標：微服務不停機升級，降低部署風險。
• 實現思路：部署兩套環境（藍綠），藍環境為當前版本，綠環境部署新版本。升級時將流量逐步切至綠環境，驗證無誤后全量切換，故障時可快速回滾至藍環境，確保服務連續性。

21. 如何根據應用場景選擇合適的消息中間件？

• 應用場景：核心為異步解耦（如用戶注冊后異步贈送積分、優惠券，降低模塊耦合）和削峰填谷（如外賣訂單創建時，通過消息隊列緩沖瞬時流量，保護下游系統）。
• 技術選型：
  • RabbitMQ：支持優先級隊列等功能，但消息堆積能力較弱，適合中小規模場景，團隊技術棧為 Golang 時優先考慮。
  • RocketMQ：性能優秀，支持消息重試、過濾、軌跡等功能，適合核心業務場景，Java 技術棧優先考慮。
  • Kafka：高吞吐量，擅長日志、大數據流式計算場景，適合數據量極大的場景。
  • 選型需結合性能、擴展性、團隊技術棧及功能需求，避免過度依賴單一中間件特性。

22. 如何提升 RocketMQ 順序消費性能？

• 順序消費原理：基于隊列級別的順序保證，通過加鎖（Broker 端隊列鎖、消費端 MessageQueue 和 ProcessQueue 鎖）實現，但并發度受隊列數量限制。
• 設計缺陷：多次加鎖導致并發性能低。
• 優化方案：
  • 關聯順序性：區分不同業務的順序需求（如同一用戶的操作需順序，不同用戶可并發）。
  • 線程模型優化：按消息 Key 的哈希值路由到不同消費線程，同一 Key 的消息串行處理，不同 Key 并行，提升并發度。
  • 核心是通過細化鎖粒度，在保證業務順序的前提下提高并行處理能力。

23. 使用分布式調度框架該考慮哪些問題？

• 核心場景：保證分布式事務一致性（如用戶注冊后消息發送與數據庫操作的一致性）。
• 解決方案：采用 “本地消息表 + 定時任務”，通過 ElasticJob 實現定時調度：
  • 本地消息表記錄待發送消息，確保數據庫操作與消息記錄在同一事務。
  • 定時任務通過分片機制拉取待處理消息，發送到 MQ 并更新消息狀態。
  • 支持流式任務，通過循環拉取處理數據，提升實時性；處理失敗時通過重試機制補償。
• 關鍵要點：任務分片、故障轉移、流式處理及消息重試策略。

24. 同城多活方案中如何實現機房之間的數據同步？

• 核心數據中心設計：主庫集中在一個機房，通過主從同步至備份機房，適合機房距離≤50 公里場景，但存在主從延遲、故障切換復雜等問題。
• Otter 工具：基于 Canal 監控 MySQL 的 Row Binlog，實現跨機房雙向同步：
  • 解決數據沖突（行沖突通過時間戳，字段沖突通過合并或回源查詢）。
  • 支持多機房拓撲（星形、級聯），但推薦同城雙活，避免跨城市高延遲。
• 注意事項：使用 SnowFlake 算法避免主鍵沖突，表結構變更需兼容，雙向同步表無默認值且必須有主鍵。

25. 微服務架構下如何進行系統拆分？

• 拆分思路：
  • 從上到下梳理業務流程，按階段（如計劃排期、生產交付、售后）劃分領域。
  • 從下到上分析數據依賴，按實體職責拆分（如訂單與排期分離），避免數據交叉頻繁。
• 服務抽象：
  • 被動抽象法：提取公共邏輯為公共服務，適合初期項目。
  • 動態輔助表：通過輔助表存儲業務特性數據，貼近業務但隔離性差。
  • 強制標準接口：底層服務僅提供標準功能，業務個性部分由上層實現，降低耦合。
• 原則：確保拆分后模塊職責單一，數據依賴清晰，便于維護和擴展。

26. 如何解決高并發下庫存搶購超賣少買問題？

• 常見方案：
  • 原子操作：使用 Redis 的decr等原子命令，避免超賣，失敗時需補償庫存。
  • 令牌庫存：用 Redis 的 List 存儲令牌，用戶搶庫存時獲取令牌，避免負數問題。
  • 多庫存秒殺：拆分庫存到多個 Key，隨機扣減；庫存不足時需判斷是否允許部分購買。
  • 鎖機制：自旋互斥鎖（適合多步操作）、CAS 樂觀鎖（爭搶少時效率高）、Redis Lua 腳本（保證多操作原子性）。
• 核心：減少鎖爭搶，利用原子操作或分布式鎖保證庫存一致性。

27. 高并發下數據寫入為何不推薦關系數據庫？

• 關系數據庫限制：基于 B+Tree 索引，樹深度隨數據量增加導致 IO 增多，寫入性能下降；主從架構下主庫壓力集中，不適合高并發寫入。
• 替代方案：
  • LSM Tree：如 RocksDB，通過內存暫存 + 順序寫磁盤，合并小文件減少 IO，適合寫多讀少場景。
  • 列存儲數據庫：按列存儲，適合數據分析場景，減少無效 IO，壓縮效率高。
  • HTAP：融合 OLAP 和 OLTP，同一數據支持行 / 列存儲，自動選擇引擎優化查詢。
• 結論：關系數據庫適合事務性操作，高并發寫入需結合 LSM Tree 或列存儲等方案。

28. 如何設計分布式鏈路跟蹤系統？

• 核心組件：基于 ELK 棧（Filebeat 收集、Kafka 傳輸、Elasticsearch 存儲、Kibana 分析）。
• 關鍵設計：
  • TraceID：標識單次請求，貫穿整個調用鏈路。
  • RPCID/SpanID：RPCID（層級計數器）或 SpanID（鏈式依賴）記錄調用關系，串聯日志。
  • 日志規范：JSON 格式，包含類型（請求、數據庫操作、錯誤等）、時間戳、耗時等字段，支持 Metrics 統計。
  • 埋點 SDK：通過 AOP 或侵入式埋點，記錄調用鏈路信息，確保日志全量且格式統一。
• 優勢：全量日志跟蹤，支持問題排查、性能分析及調用關系可視化。

29. 如何優化架構緩解流量壓力提升并發性能？

• 可預估用戶量場景：如游戲房間，通過調度服務分配集群，限制單服房間數，精準控制資源。
• 不可預估用戶量場景：如直播互動：
  • 聊天：合并重復消息，通過隊列緩沖，批量拉取降低壓力。
  • 答題：客戶端延遲請求，預加載題目，異步提交結果。
  • 點贊：客戶端合并操作，服務端通過多層匯總（本地緩存→二級緩存→核心緩存）分散壓力。
  • 打賞 / 購物：按用戶 ID 分片，通過代理服務動態擴容，支持熱遷移切片。
• 服務降級：通過隊列緩沖或限流，犧牲部分實時性保證系統穩定。

30. 復雜架構為何需要分層設計？

• 分層優勢：
  • 簡化設計：不同團隊專注某一層（如表現層、邏輯層），降低復雜度。
  • 復用性高：提取通用層（如 Manager 層）供多系統使用。
  • 便于擴展：針對瓶頸層（如 CPU 密集的邏輯層）單獨擴容，降低成本。
• 分層實踐：參考阿里架構，分為終端顯示層、開放接口層、Web 層、Service 層、Manager 層、DAO 層，各層職責清晰，通過 Manager 層封裝通用能力，Service 層編排業務邏輯，實現高內聚低耦合。

31. 分布式事務常見解決方案及適用場景

• 核心問題：保證跨服務操作的數據一致性（如下單時扣庫存與創建訂單需同時成功或失敗）。
• 解決方案：
  • 2PC（兩階段提交）：分準備和提交階段，強一致性但性能差，適合銀行等對一致性要求極高的場景。
  • TCC（Try-Confirm-Cancel）：業務層拆分三個操作，靈活性高但開發成本高，適合核心業務（如支付）。
  • 本地消息表：通過本地事務記錄消息，定時同步至 MQ，最終一致性，適合非核心場景（如積分發放）。
  • SAGA 模式：長事務拆分為短事務鏈，失敗時逆向補償，適合長流程業務（如訂單履約）。
  • 選擇原則：優先最終一致性方案降低復雜度，核心場景按需選擇強一致性方案。

32. 緩存三大問題（雪崩、穿透、擊穿）及解決辦法

• 緩存雪崩：大量緩存同時失效，請求直達數據庫。
  解決：過期時間加隨機值避免同時失效；多級緩存（本地緩存 + 分布式緩存）；熔斷降級保護數據庫。
• 緩存穿透：查詢不存在的數據，緩存無命中，頻繁訪問數據庫。
  解決：布隆過濾器過濾無效請求；緩存空值（短期過期）；接口層校驗攔截。
• 緩存擊穿：熱點 Key 突然失效，大量請求沖擊數據庫。
  解決：互斥鎖（如 Redis 的 SETNX）控制并發重建緩存；熱點數據設置永不過期；異步后臺更新緩存。

33. JVM 性能優化核心要點

• 內存模型：區分堆（新生代、老年代）、方法區、直接內存，避免 OOM（如新生代過小導致頻繁 GC，老年代溢出）。
• 垃圾回收：
  • 年輕代用 Minor GC（復制算法），老年代用 Major GC（標記 - 清除 / 整理）。
  • 選合適收集器：G1 適合大堆場景，ZGC/Shenandoah 適合低延遲需求。
• 調優參數：
  • 堆大小：-Xms=-Xmx避免動態擴容；新生代占比 1/3~1/2。
  • 收集器參數：-XX:+UseG1GC啟用 G1，-XX:MaxGCPauseMillis控制延遲。
• 問題排查：用 jstack 分析線程阻塞，jmap 查看內存快照，Arthas 實時診斷線上問題。

34. 并發編程關鍵技術及實踐

• 線程池：核心參數（核心線程數、最大線程數、隊列、拒絕策略）需匹配業務（CPU 密集型：線程數≈核數；IO 密集型：線程數≈2 * 核數）。
• 線程安全：
  • 同步機制：synchronized（自動釋放鎖）、ReentrantLock（可中斷、超時）。
  • 可見性：volatile 禁止指令重排，保證多線程數據可見。
  • 原子類：AtomicInteger 等通過 CAS 避免鎖競爭。
• 并發容器：
  • ConcurrentHashMap（分段鎖→CAS 優化，線程安全）。
  • CopyOnWriteArrayList（讀寫分離，適合讀多寫少）。
• 鎖優化：偏向鎖→輕量級鎖→重量級鎖的升級機制，減少鎖競爭（如縮小同步代碼塊范圍）。

35. 微服務治理核心組件及作用

• 服務注冊發現：Nacos/Eureka 管理服務地址，支持動態擴縮容，避免硬編碼。
• 配置中心：Nacos/Apollo 集中管理配置，動態推送更新（如開關、限流閾值），無需重啟服務。
• 熔斷降級：Sentinel/Hystrix 監控服務健康，故障時熔斷避免級聯失敗，降級返回兜底數據。
• API 網關：Spring Cloud Gateway 路由請求、鑒權、限流、日志收集，統一入口簡化調用。
• 鏈路追蹤：Sleuth+Zipkin 追蹤跨服務調用，定位性能瓶頸和異常節點。

36. 分布式 ID 生成方案及選型

• 核心需求：保證全局唯一、趨勢遞增（利于數據庫索引）、高可用、高性能。
• 常見方案：
  • UUID/GUID：簡單易用，但無序且占空間大，不適合作為數據庫主鍵。
  • 數據庫自增 ID：單機可行，分布式場景下需分庫分表配合自增步長，易引發 ID 沖突。
  • 雪花算法（Snowflake）：64 位 ID，包含時間戳、機器 ID、序列號，支持分布式且趨勢遞增，需保證機器 ID 唯一。
  • Redis 自增：利用INCR命令生成，性能高但依賴 Redis 可用性，需做好持久化。
• 選型建議：高并發場景優先選雪花算法，簡單場景可用 Redis 自增，避免 UUID 作為主鍵。

37. 分庫分表后如何解決跨庫事務問題

• 挑戰：傳統單機事務無法覆蓋多庫表操作，易出現數據不一致。
• 解決方案：
  • 最終一致性方案：基于本地消息表 + 定時任務，通過消息隊列異步補償，適合非核心業務。
  • TCC 模式：Try（預留資源）、Confirm（確認提交）、Cancel（取消釋放），業務侵入性高，適合核心場景（如支付）。
  • SAGA 模式：將長事務拆分為短事務鏈，失敗時執行逆向補償操作，適合流程型業務。
• 注意事項：優先保證核心業務數據一致性，非核心業務可接受最終一致性以降低復雜度。

38. 如何設計高可用的 Redis 集群

• 架構選型：
  • 主從復制：主庫寫入，從庫只讀，解決單節點讀壓力，但主庫故障需手動切換。
  • 哨兵模式（Sentinel）：自動監控主從節點，主庫故障時自動切換從庫為主庫，提升可用性。
  • Redis Cluster：分片存儲數據，每個分片有主從節點，支持水平擴容，適合大規模數據場景。
• 關鍵優化：
  • 避免大 Key（如超過 100KB），防止阻塞集群。
  • 合理設置內存淘汰策略（如allkeys-lru），防止 OOM。
  • 開啟 AOF+RDB 混合持久化，兼顧數據安全性和恢復速度。

39. 如何優化 MySQL 查詢性能

• 索引優化：
  • 建立合適索引（如主鍵索引、聯合索引），避免索引失效（如使用!=、函數操作索引列）。
  • 聯合索引遵循 “最左前綴原則”，合理安排字段順序。
• SQL 優化：
  • 避免SELECT *，只查詢必要字段。
  • 減少子查詢，改用 JOIN；避免OR，改用UNION。
  • 大表分頁用WHERE id > 上一頁最大ID替代LIMIT offset, rows。
• 架構優化：
  • 讀寫分離：主庫寫入，從庫讀取，分散壓力。
  • 分庫分表：按業務維度（如用戶 ID）拆分，降低單表數據量。
  • 緩存熱點數據：將高頻查詢結果放入 Redis，減少數據庫訪問。

40. 微服務接口設計原則

• 單一職責：一個接口只處理一個業務場景（如 “創建訂單” 和 “查詢訂單” 分離），避免接口臃腫。
• 冪等性：通過唯一標識（如訂單號）保證重復調用結果一致，防止重復提交（如支付接口）。
• 版本控制：接口 URL 包含版本號（如/api/v1/order），便于迭代兼容舊版本。
• 限流降級：接口層設置限流規則（如 QPS 閾值），異常時返回降級響應（如默認數據）。
• 清晰的錯誤碼：自定義錯誤碼（如 10001 代表參數錯誤），便于問題排查和前端處理。

41. 如何設計分布式鎖

• 核心要求：互斥性、安全性（避免死鎖）、可用性、公平性。
• 實現方案：
  • Redis 分布式鎖：使用SET key value NX PX命令加鎖，Lua 腳本解鎖，需設置過期時間防止死鎖，集群場景需考慮 RedLock 算法。
  • ZooKeeper 分布式鎖：基于臨時節點，節點創建成功即獲鎖，會話過期自動釋放，天然避免死鎖，性能略低于 Redis。
• 注意事項：加鎖后需驗證鎖持有者身份，避免誤釋放；長時間任務需定時續期鎖（如 “看門狗” 機制）。

42. 如何應對大促場景下的數據庫壓力

• 事前準備：
  • 擴容數據庫實例，增加從庫數量分擔讀壓力。
  • 預熱緩存，將熱點數據（如商品信息）提前加載到 Redis。
  • 分庫分表擴容，拆分大表降低單表壓力。
• 事中優化：
  • 讀寫分離，強制熱點讀走緩存。
  • 限制非核心業務訪問（如關閉評論、推薦等非交易功能）。
  • 使用隊列異步處理非實時操作（如訂單日志、統計數據）。
• 事后處理：
  • 監控數據庫慢查詢，及時優化 SQL。
  • 復盤流量峰值，調整擴容策略和緩存方案。

43. 如何設計一個延遲隊列

• 應用場景：訂單超時未支付自動關閉、定時任務（如到期提醒）。
• 實現方案：
  • JDK DelayQueue：基于內存，簡單易用但不適合分布式場景，數據易丟失。
  • Redis zset：將延遲任務作為 zset 成員，score 為過期時間戳，定時掃描到期任務，適合中小規模場景。
  • 消息隊列延遲消息：如 RocketMQ 的延遲級別、RabbitMQ 的死信隊列，可靠性高，適合分布式系統。
• 選型建議：分布式場景優先用消息隊列延遲消息，簡單場景可用 Redis zset。

44. 如何保證緩存與數據庫數據一致性

• 更新策略：
  • Cache Aside Pattern：更新數據庫后刪除緩存，讀數據時先查緩存，未命中則查庫并回寫緩存，避免緩存臟數據。
  • 讀寫鎖：更新時加寫鎖，防止并發讀寫導致的數據不一致。
• 異常處理：
  • 緩存刪除失敗時，通過定時任務對比數據庫與緩存數據，修復不一致。
  • 對熱點數據設置較短過期時間，加速臟數據淘汰。
• 核心原則：優先保證數據庫數據正確，緩存作為輔助，允許短暫不一致但需最終一致。