分布式系統面試，別只盯著算法題
分布式系統面試，別只盯著算法題
面試官問分布式系統，很多人第一反應是背算法題，比如Paxos、Raft流程畫得清清楚楚。但真正到技術面時，面試官往往不會讓你默寫協議，而是拋出一個業務場景，比如“用戶下單后庫存扣減怎么保證不超賣”，或者“服務間調用超時了怎么辦”。這些才是分布式系統面試核心問題的真實面貌：它不是孤立的八股文，而是對一致性、可用性、分區容錯性之間權衡的理解。
從CAP理論出發，理解取舍的底層邏輯
任何分布式系統都繞不開CAP理論。但很多候選人的理解停留在“三者只能取其二”這個口訣上。面試官真正想聽的，是你能否結合具體場景解釋為什么不能同時滿足。比如在一個電商系統中，網絡分區是不可避免的。當分區發生時，你是選擇保持可用性但犧牲一致性，還是保持一致性但拒絕寫入？前者如最終一致性的DNS緩存，后者如ZooKeeper的強一致性模型。面試官期待的不是背誦，而是你能否說出：在支付場景下，寧可拒絕服務也不能出現賬目不一致；而在用戶頭像更新場景下，短暫的不一致完全可以接受。這種對業務場景的敏感度，才是分布式系統面試核心問題要考察的第一層能力。
一致性協議，不是背流程而是看設計權衡
Raft和Paxos是面試高頻點，但面試官很少讓你手寫協議。更常見的問題是：“Raft為什么引入Leader？Paxos的Multi-Paxos和Raft有什么區別？”回答的關鍵在于理解Leader的作用是為了簡化決策流程，減少消息交互次數。如果你能進一步指出，Raft通過強Leader和日志連續性保證了更簡單的實現，但代價是Leader成為單點瓶頸，而Paxos雖然更靈活，但實現復雜且容易出錯，這就說明你真的理解了設計取舍。另一個常問的點是：ZAB協議和Raft有什么異同。ZAB用于ZooKeeper，它強調崩潰恢復后的消息順序性，而Raft更強調Leader的權威性。這些細節差異，恰恰是分布式系統面試核心問題中區分“背答案”和“真理解”的關鍵。
分布式事務，別只記住兩階段提交
兩階段提交是經典方案，但面試官會追問它的缺陷：協調者單點、同步阻塞、數據不一致風險。如果你能自然引出三階段提交、TCC、Saga等方案，并說明各自適用場景，就能體現出深度。比如TCC適用于短事務、高并發場景，但需要業務方實現Try、Confirm、Cancel三個接口，對代碼侵入性強；Saga則適合長事務，通過補償機制實現最終一致性，但需要處理補償失敗的情況。面試官還會問：為什么很多互聯網公司不用XA協議？因為XA是強一致性方案，在跨庫跨服務場景下性能損耗大，而業務上往往能接受短暫不一致。這種對性能和業務容忍度的權衡，才是分布式系統面試核心問題中真正有價值的思考。
服務發現與負載均衡，細節決定成敗
服務發現聽起來簡單，但面試官會問：Eureka和Consul的區別是什么？為什么Eureka強調AP，而Consul傾向CP？Eureka的設計哲學是“寧可返回一個可能不健康的節點，也不讓客戶端拿不到任何節點”，這適合內部服務調用，容忍短暫的不一致；Consul則通過Raft保證強一致性，適合對配置信息準確性要求高的場景。負載均衡方面，面試官會問：一致性哈希解決了什么問題？如果節點數量變化，如何減少數據遷移？如果你能說出虛擬節點、哈希環、數據傾斜等概念，并解釋為什么Redis集群采用一致性哈希而Kafka采用分區分配，就能展現出對分布式系統設計細節的熟悉。這些看似零散的知識點，其實都是分布式系統面試核心問題中考察系統設計能力的縮影。
分布式緩存，穿透、擊穿、雪崩的應對邏輯
緩存問題是面試中幾乎必問的場景題。面試官會問：緩存穿透怎么解決？布隆過濾器的誤判率如何控制？緩存擊穿時，為什么互斥鎖比“永不過期”方案更可靠？緩存雪崩時，為什么隨機過期時間比統一過期更有效？這些問題背后考察的是對緩存與數據庫一致性的理解。比如更新緩存時，先刪緩存還是先更新數據庫？如果先刪緩存，在更新數據庫的間隙，另一個請求會把舊數據加載到緩存，導致臟數據。如果先更新數據庫再刪緩存，又可能因為刪除失敗導致不一致。面試官期待的不是標準答案，而是你能分析出不同方案的優缺點，并說出在實際項目中如何通過消息隊列、延遲雙刪等機制來兜底。這種對細節的推敲，才是分布式系統面試核心問題中真正拉開差距的地方。
消息隊列，冪等性與順序性的權衡
消息隊列在分布式系統中承擔解耦和削峰的作用，但面試官會問：如何保證消息不丟失？如何保證消息不重復消費？如何保證消息的順序性？這些問題背后是對消息中間件原理的理解。比如Kafka通過ACK機制和副本同步保證不丟失，但需要權衡吞吐量；RabbitMQ通過確認機制和持久化保證可靠性，但性能相對較低。順序性方面，Kafka只能保證分區內有序，跨分區無法保證，因此需要業務上合理設計分區鍵。冪等性則依賴業務層實現，比如通過去重表或版本號。面試官還會問：為什么RocketMQ支持事務消息而Kafka不支持？這涉及到對兩階段消息和本地事務表的理解。這些問題的本質，是考察你能否在消息可靠性、吞吐量、順序性之間做出合理取舍，而這正是分布式系統面試核心問題中反復出現的主題。
面試官真正想看到的，不是你能背出多少概念，而是你能在具體場景下做出合理的權衡。分布式系統的核心在于“沒有銀彈”，每一個設計選擇都意味著某種妥協。能清晰說出為什么在A場景選A方案、在B場景選B方案，并講清楚背后的代價，這才是分布式系統面試核心問題想要篩選出的能力。