分布式常見面試題整理

一、分布式理論：

CAP理論
分布式系統最多同時滿足一致性（C）、可用性（A）、分區容錯性（P）中的兩個，無法三者兼得。
BASE理論
對CAP中一致性和可用性的權衡，強調基本可用（BA）、軟狀態（S）和最終一致性（E），適用于高可用場景。
2PC（兩階段提交）
分布式事務協議，分準備（投票）和提交/回滾兩個階段，保證強一致性但存在同步阻塞和單點問題。
3PC（三階段提交）
2PC的改進，增加預提交階段減少阻塞，但仍可能數據不一致。
ZAB協議
ZooKeeper的核心協議，通過選舉Leader和原子廣播實現數據一致性，用于分布式協調。
Raft協議
更易理解的共識算法，通過選舉Leader、日志復制保證一致性，替代Paxos用于分布式系統一致性管理。

二、Zookeeper:

ZooKeeper是什么？
分布式協調服務，提供數據發布/訂閱、分布式鎖、集群管理等功能，基于ZAB協議保證一致性。
Zookeeper怎么保證主從節點的數據同步？
通過ZAB協議：Leader接收寫請求，廣播提案（Proposal），Follower/Observer同步日志并ACK，超過半數確認后Leader提交事務。
Zookeeper為什么能用做注冊中心？
支持臨時節點和Watcher機制，服務注冊（創建節點）、下線（節點自動刪除）、發現（監聽節點變化）實時通知。
Zookeeper中有哪些類型的數據節點？
- 持久節點（PERSISTENT）
- 臨時節點（EPHEMERAL）
- 持久順序節點（PERSISTENT_SEQUENTIAL）
- 臨時順序節點（EPHEMERAL_SEQUENTIAL）
Zookeeper中Watcher機制是什么？
事件監聽回調：客戶端對節點注冊Watcher，節點變化（增刪改）時服務端觸發事件通知，但是一次性的（需反復注冊）。
Zookeeper集群中有哪些服務器角色？
- Leader：處理寫請求，發起提案和提交。
- Follower：參與投票和選舉，同步Leader數據。
- Observer：同步數據但不投票，擴展讀性能。
Zookeeper中的領導者選舉是如何實現的？
基于ZAB協議：節點啟動或Leader崩潰時進入選舉狀態，投票優先投zxid（事務ID）最大、其次serverid最大的節點，超過半數當選。
ZAB協議包括哪些內容？
- 崩潰恢復：選舉新Leader，數據同步到最新狀態。
- 消息廣播：Leader將寫請求以提案廣播，半數確認后提交。
Zookeeper能解決腦裂問題嗎？
能。基于過半機制（Quorum），寫請求需多數節點確認，分裂后僅多數派分區能選舉Leader和服務，少數派分區拒絕請求。
為什么Zookeeper集群的節點個數要用奇數個？
容錯與成本平衡：n節點集群容忍(n-1)/2個故障。奇數節點在相同容錯能力下（如3節點和4節點均容錯1故障）更節省資源。
Zookeeper能用來做什么？
- 注冊中心（如Dubbo）
- 分布式鎖（臨時順序節點）
- 配置管理（持久節點+Watcher）
- 集群選主（臨時節點+選舉）
Zookeeper實現分布式鎖的原理？
- 爭搶鎖：所有客戶端在指定目錄下創建臨時順序節點。
- 判斷最小節點：最小節點獲鎖。
- 監聽前序節點：非最小節點監聽前一個節點，釋放時觸發通知。
- 避免驚群：僅監聽前一個節點。
Zookeeper實現配置中心的原理？
- 存儲配置：配置信息存儲在持久節點。
- 動態更新：客戶端監聽節點Watcher，配置變更時服務端通知，客戶端拉取新配置。
Zookeeper和Dubbo的關系？
Zookeeper作為Dubbo的注冊中心，服務提供者注冊地址到ZK，消費者從ZK發現服務列表，并監聽變化實現動態路由。

三、分布式緩存：

什么是Redis？
開源內存數據結構存儲，用作數據庫、緩存、消息隊列，支持多種數據結構與持久化。
為什么要用緩存？
- 高性能：內存讀寫快，降低數據庫壓力。
- 高并發：緩解數據庫負載，提升系統吞吐量。
為什么用Redis不用Map？
- Redis是分布式緩存，支持多服務共享；本地Map僅單機有效。
- Redis提供持久化、豐富數據結構、過期策略等。
Redis線程模型？
單線程Reactor模型（6.0前）：單線程處理命令+IO多路復用，避免上下文切換，保證原子性。
Redis和Memcached區別？
- Redis：支持多種數據結構、持久化、主從復制，適用復雜場景。
- Memcached：只支持KV、多線程、無持久化，純緩存場景性能更高。
Redis常見數據結構及使用場景？
- String：緩存、計數器
- Hash：存儲對象
- List：消息隊列、棧
- Set：標簽、好友關系
- ZSet：排行榜
- Bitmap：位統計
- HyperLogLog：基數估算
- Stream：消息流（5.0+）
Redis故障恢復？
通過持久化：
- RDB：快照恢復，數據可能丟失。
- AOF：日志重放，數據更完整（可配置fsync策略）。
保證Redis中為熱點數據？
設置內存上限+淘汰策略（如LRU/LFU），自動淘汰冷數據。
如何實現Redis事務？
- MULTI開啟事務，命令入隊。
- EXEC執行（原子性，但無回滾）。
- WATCH監控Key（樂觀鎖）。
緩存雪崩及解決？
- 問題：大量緩存同時過期，請求直接擊穿數據庫。
- 解決：隨機過期時間、集群高可用、永不過期（后臺更新）。
緩存穿透及解決？
- 問題：查詢不存在的數據（如惡意攻擊），繞過緩存。
- 解決：布隆過濾器、空值緩存、接口校驗。
緩存擊穿及解決？
- 問題：熱點Key過期，瞬間高并發查詢數據庫。
- 解決：互斥鎖（如Redis SETNX）、永不過期（邏輯過期）。
并發競爭Key問題？
- 用WATCH+事務（樂觀鎖）。
- 或分布式鎖（如Redisson）保證串行訪問。
什么是RedLock？
Redis官方分布式鎖算法：向多個獨立Redis實例申請鎖，過半成功才算獲取，避免單點故障。
緩存與數據庫雙寫一致性？
- 策略：先更新數據庫，再刪除緩存（延遲雙刪）。
- 補充：讀請求先讀緩存，未命中讀庫+回寫。
單節點實現分布式鎖？
SET key random_value NX PX 3000（原子設值+過期時間），解鎖時用Lua腳本校驗值再刪除。
Redis使用場景？
緩存、會話存儲、排行榜、消息隊列、分布式鎖等。
Redis功能？
持久化、主從復制、哨兵、集群、事務、Pub/Sub等。
Redis為什么單線程？
避免鎖競爭和上下文切換，內存操作+IO多路復用已足夠高效（6.0后多線程僅處理網絡IO）。
Redis的Java客戶端？
Jedis（同步阻塞）、Lettuce（異步非阻塞）、Redisson（分布式功能封裝）。
Jedis和Redisson區別？
- Jedis：輕量級API，直接操作Redis。
- Redisson：分布式對象（如鎖、隊列）封裝，更高級抽象。
Redis實現分布式鎖？
- 命令：SETNX+過期時間（防死鎖）。
- 推薦：Redisson的RLock，支持可重入、續期。
Redis持久化方式？
- RDB：快照，二進制壓縮文件。
- AOF：日志追加，可配置每秒/每次同步。
- 混合持久化（4.0+）：RDB+AOF。
Redis內存優化？
- 使用合適數據結構（如Hash代替多個String）。
- 配置最大內存+淘汰策略。
- 縮短鍵值長度，使用整數池。
Redis分布式鎖缺陷？
- 非強一致性（主從切換可能鎖失效）。
- 需自己解決續期、原子性等問題（推薦Redisson）。
Redis性能問題及解決？
- 慢查詢：優化命令，避免大數據操作。
- 內存不足：增加內存或優化數據。
- 網絡瓶頸：集群分片或客戶端優化。
Redis淘汰策略？
- volatile-lru/ttl：過期鍵中淘汰。
- allkeys-lru/lfu：所有鍵中淘汰。
- random：隨機淘汰。
- noeviction：不淘汰（默認）。
單線程Redis為什么快？
- 內存操作。
- IO多路復用（epoll）。
- 單線程無鎖競爭。
Redis應用場景？
緩存、會話共享、分布式鎖、排行榜、消息隊列、地理空間計算等。

四、消息隊列：

MQ選型考慮因素？
吞吐量（Kafka/RocketMQ）、延遲（RabbitMQ）、可靠性、功能（事務/延遲消息）、生態和運維成本。
RabbitMQ消息發送過程？
生產者→交換機（Exchange）→路由綁定（Binding）→隊列（Queue）→消費者。
RabbitMQ保證消息穩定性？
- 持久化（交換機、隊列、消息）。
- 生產者確認（Confirm）、消費者手動ACK。
- 集群鏡像隊列。
避免消息丟失？
- 生產者：開啟Confirm機制（確認Broker接收）。
- Broker：持久化+鏡像隊列。
- 消費者：手動ACK（處理完再確認）。
持久化缺點？
磁盤IO性能下降（但內存+磁盤組合仍可接受）。
消息持久化成功條件？
- 交換機、隊列持久化。
- 消息投遞模式（delivery_mode=2）。
- 寫入磁盤（刷盤策略）。
RabbitMQ廣播類型？
- 直連（Direct）、主題（Topic）、扇出（Fanout）、頭（Headers）。
實現延遲消息隊列？
插件（rabbitmq_delayed_message_exchange）或TTL+死信隊列（DLX）。
RabbitMQ節點類型？
- 磁盤節點（元數據持久化）。
- 內存節點（元數據內存，性能高）。
每個節點是完整拷貝嗎？
不是。僅元數據（隊列結構等）同步，消息數據需配置鏡像隊列才復制。
唯一磁盤節點崩潰？
集群無法修改元數據（如創建隊列），但內存節點仍可服務（需至少一個磁盤節點存活）。
集群節點停止順序？
先停內存節點，最后停磁盤節點（避免元數據丟失）。
RabbitMQ使用場景？
異步解耦、流量削峰、延遲消息、順序消息（單隊列）。
重要角色？
生產者、消費者、Broker（服務器）、交換機、隊列。
重要組件？
連接（Connection）、信道（Channel）、虛擬主機（vhost）。
vhost作用？
邏輯隔離（不同業務組獨立使用），類似命名空間。
什么是Kafka？
分布式流處理平臺，高吞吐、持久化、多訂閱，用于日志、消息隊列等。
為什么用消息隊列？
解耦、異步、削峰。
Kafka中ISR、AR？
- AR：所有副本。
- ISR：與Leader同步的副本（含Leader）。
- ISR伸縮：副本滯后（超過replica.lag.time.max.ms）被踢出，追上后加入。
Broker作用？
存儲消息，處理讀寫請求。
Zookeeper在Kafka中的作用？可不用嗎？
- 存儲元數據（Broker、Topic、分區信息）、選Controller。
- 2.8.0后支持不用Zookeeper（KRaft模式）。
Follower同步數據？
拉取（Pull）Leader數據，寫入本地日志。
Broker被踢出ISR？
同步滯后（如網絡慢、宕機）超過閾值（replica.lag.time.max.ms）。
Kafka為什么快？
- 順序讀寫磁盤。
- 零拷貝（sendfile）。
- 分區并行+批量壓縮。
Producer優化速度？
批量發送（linger.ms、batch.size）、壓縮、異步發送。
ack含義？
- 0：不等待確認（可能丟失）。
- 1：Leader確認（可能丟失）。
- -1（all）：ISR所有副本確認（可靠）。
Message格式？
偏移量+時間戳+Key+Value+頭部字段。
Consumer Group作用？
實現發布訂閱（不同Group獨立消費）和隊列（同Group內競爭消費）。
消息丟失和重復消費？
- 丟失：ack配置不當、未處理完消費者宕機。
- 重復：生產者重試、消費者提交偏移量失敗。
為什么不支持讀寫分離？
Leader處理讀寫，利用順序寫和頁緩存，避免數據不一致和網絡開銷。
消息順序性？
分區內順序（同一分區消息順序消費），但全局不保證。
實現延遲隊列？
使用時間戳+多個Topic（或Kafka自2.1+支持內部延遲）。
事務實現？
跨分區原子寫（Producer端），使用事務協調器。
選舉及策略？
- Controller選舉：基于Zookeeper（臨時節點）。
- Partition Leader：Controller指定（ISR中首選）。
RocketMQ選型原因？
對比Kafka（高吞吐但延遲高）、RabbitMQ（低延遲但吞吐低），RocketMQ平衡吞吐、延遲、事務消息、中文生態。
RocketMQ分布式存儲？
主題分多個隊列（Queue），分布在不同Broker，每個隊列多副本。
Broker宕機處理？
- 主從切換（Slave同步數據，自動提升為Master）。
- 集群消費模式（重試其他Broker）。
發現Broker？
通過NameServer（服務發現）獲取Broker路由信息。
RocketMQ核心部分？
NameServer（元數據）、Broker（存儲）、Producer、Consumer。
NameServer部署幾臺？
可多臺（通常2-4），集群部署避免單點，但節點間無數據同步（各存全量數據）。
Broker注冊到哪個NameServer？
配置的所有NameServer（全部注冊）。
獲取Broker信息？
客戶端定時從NameServer拉取路由表。
感知Broker宕機？
NameServer心跳檢測（Broker定時上報），超時則剔除。
Master同步Slave？
異步或同步復制（取決于配置）。
Slave掛掉影響？
無直接影響（Master仍服務），但降低可用性（無法故障切換）。
Master掛掉？
- 自動切換：Slave提升為Master（需配置Dledger或故障轉移）。
- 手動干預：依賴運維腳本。
Dledger機制？
Raft協議實現，保證多副本數據一致性，自動選主和故障轉移。

五、分布式鎖：

需要使用分布式鎖的場景？
秒殺庫存扣減、集群定時任務調度、共享資源訪問（如文件修改）、防止重復提交等。
常見的分布式鎖解決方案？
- 基于數據庫（唯一索引、悲觀鎖）
- 基于Redis（SETNX+過期時間）
- 基于ZooKeeper（臨時順序節點）
- 基于Etcd（租約機制）
Redis分布式鎖實現方法？
命令：SET lock_key random_value NX PX 3000（原子操作設值+過期時間）。
釋放：Lua腳本校驗值再刪除（防誤刪）。
缺陷：主從切換可能鎖失效（可用RedLock算法緩解）。
ZooKeeper分布式鎖實現原理？
- 爭搶鎖：所有客戶端在鎖目錄下創建臨時順序節點。
- 判斷最小節點：序號最小的節點獲鎖。
- 監聽前序節點：未獲鎖的客戶端監聽前一個節點，釋放時通知下一個節點。
- 優點：強一致性，無鎖失效問題；缺點：性能較低。
ZK和Redis分布式鎖優缺點？
- Redis：
  優點：性能高、實現簡單。
  缺點：非強一致性（主從同步延遲可能鎖失效）。
- ZooKeeper：
  優點：強一致性、可靠性高。
  缺點：性能較低、依賴ZK集群。
Mysql如何做分布式鎖？
- 方法1：基于唯一索引（插入成功獲鎖，刪除釋放）。
- 方法2：基于悲觀鎖（SELECT ... FOR UPDATE）。
  缺點：數據庫性能瓶頸，鎖無自動失效（需超時機制）。
業界大公司的分布式鎖框架？
- Google：Chubby（基于Paxos，類似ZK）。
- 阿里巴巴：基于Redis的分布式鎖（Redisson封裝）。
- Netflix：基于ZooKeeper的分布式鎖。
- Apache：Curator（ZK客戶端，提供分布式鎖封裝）。

六、分布式服務調用：

什么是RPC？
遠程過程調用，像調用本地方法一樣調用遠程服務，隱藏網絡細節。
RPC over HTTP vs RPC over TCP？
- HTTP：通用、穿透性好（如Rest），但性能較低。
- TCP：自定義協議（如Dubbo），性能高，但更復雜。
Dubbo核心組件？
- Provider：服務提供者
- Consumer：服務消費者
- Registry：注冊中心（如Zookeeper）
- Monitor：監控中心
- Container：服務運行容器
Dubbo服務調用過程？
消費者通過代理調用→從注冊中心獲取服務列表→負載均衡選Provider→網絡傳輸（序列化/反序列化）→執行并返回結果。
集群容錯方案？
- Failover（默認）：失敗自動重試其他節點。
- Failfast：快速失敗，立即報錯。
- Failsafe：忽略錯誤，記錄日志。
- Failback：失敗后臺記錄，定時重試。
- Forking：并行調用多個節點，取最先返回的結果。
- Broadcast：廣播調用所有節點，任意一個報錯則報錯。
服務調用是阻塞的嗎？
默認同步阻塞調用，但支持異步調用（Future或回調）。
Dubbo支持的協議及場景？
- dubbo協議（默認）：TCP長連接，高性能，適合大并發小數據量。
- rmi協議：JDK標準，適合短連接大數據包。
- http協議：基于HTTP，易跨語言。
- hessian協議：基于HTTP，適合多語言交互。
Dubbo vs Spring Cloud？
- Dubbo：性能高（RPC），適合內部服務調用。
- Spring Cloud：生態全（HTTP+Rest），適合微服務全家桶。
  根據團隊技術棧和需求選擇。
負載均衡策略？
- Random（默認）：隨機選擇。
- RoundRobin：輪詢。
- LeastActive：選最不活躍的節點（請求數最少）。
- ConsistentHash：一致性Hash，相同參數總是請求同一節點。
序列化框架？
默認Hessian2，還支持Kryo（高性能）、FST、JSON等。
服務降級？
- 配置mock值：強制返回默認值（如null）。
- 容錯mock：失敗時執行mock邏輯。
服務暴露過程？
服務提供者啟動→向注冊中心注冊服務→本地暴露服務（啟動Netty服務器監聽請求）。
服務引入過程？
消費者啟動→從注冊中心訂閱服務→獲取提供者列表→創建代理對象（用于遠程調用）。
支持一個服務多個協議？
支持，可在@Service注解中配置多個協議（如dubbo和hessian），不同協議不同端口。
支持一個服務多個注冊中心？
支持，可配置服務同時注冊到多個注冊中心（如Zookeeper和Nacos）。
支持一個服務多個版本？
支持，通過版本號（version）區分，消費者可指定調用特定版本的服務。

七、微服務：

如何理解微服務？
將單體應用拆分為一組小型、獨立部署的服務，每個服務圍繞特定業務能力構建，服務間通過輕量級通信協作。
微服務特點？
- 單一職責
- 獨立部署、擴展和技術選型
- 去中心化治理
- 容錯性強
- 通過API交互
SOA vs 微服務？
- SOA：強調集成（ESB總線）、復用、粗粒度服務。
- 微服務：強調獨立、輕量通信（HTTP/RPC）、細粒度服務、快速交付。
微服務優缺點？
- 優點：靈活技術棧、獨立擴縮容、故障隔離、易于迭代。
- 缺點：運維復雜、網絡延遲、數據一致性難、測試部署復雜。
Spring Cloud Netflix組件？
- Eureka：服務注冊發現
- Ribbon：客戶端負載均衡
- Feign：聲明式HTTP客戶端
- Hystrix：熔斷降級
- Zuul：網關（舊版）
Spring Cloud Alibaba組件？
- Nacos：注冊中心+配置中心
- Sentinel：流量控制、熔斷降級
- Seata：分布式事務
- Dubbo：RPC調用
斷路器作用？
防止服務雪崩：當下游服務故障時，快速失敗或降級，避免資源耗盡。
Spring Cloud實現服務注冊？
服務提供者通過@EnableDiscoveryClient向注冊中心（如Eureka/Nacos）注冊實例信息。
Eureka vs Zookeeper？
- Eureka：AP架構，保證可用性，適合注冊中心。
- Zookeeper：CP架構，保證一致性，適合分布式協調。
Ribbon作用？
客戶端負載均衡：從注冊中心獲取服務列表，根據策略（如輪詢、隨機）選擇實例調用。
Feign作用？
聲明式REST客戶端：基于注解和接口定義HTTP請求，整合Ribbon和Hystrix。
Hystrix作用？
熔斷器：實現服務熔斷、降級、線程隔離，提高系統彈性。
Spring Cloud Bus作用？
消息總線：用于廣播配置變更（配合Config），實現批量刷新配置。
網關作用？
- 路由轉發
- 認證鑒權
- 限流熔斷
- 日志監控
  （如Spring Cloud Gateway）
Spring Cloud vs Dubbo？
- Spring Cloud：生態全（HTTP+Rest），適合微服務全家桶。
- Dubbo：性能高（RPC），適合內部服務調用。
- 現在可融合（Spring Cloud Alibaba整合Dubbo）。
Restful？
一種架構風格：資源用URI標識，通過HTTP方法（GET/POST/PUT/DELETE）操作，無狀態、可緩存。
如何拆分服務？拆分原則？
- 根據業務領域（DDD限界上下文）
- 單一職責、高內聚低耦合
- 團隊結構（康威定律）
- 避免分布式大單體
服務網格（Service Mesh）？
- 是什么：基礎設施層，處理服務間通信（如Istio、Linkerd）。
- 特點：解耦業務代碼與通信邏輯（Sidecar代理）。
- 解決：服務發現、負載均衡、熔斷、安全、可觀測性等。
DDD（領域驅動設計）？
通過領域模型和通用語言解決復雜業務問題，核心包括：
- 限界上下文（Bounded Context）
- 實體、值對象、聚合根
- 領域事件、倉儲、工廠
  用于指導微服務拆分和架構設計。

八、分布式事務：

什么是分布式事務？
跨多個數據庫或服務的事務操作，需要保證所有操作要么全部成功，要么全部失敗。
常用解決方案？
- 2PC/3PC（強一致性）
- TCC（補償型）
- 消息事務（最終一致性）
- Saga（長事務）
- 本地消息表
XA方案流程？
基于數據庫XA協議：
1. 事務管理器（TM）啟動全局事務。
2. 資源管理器（RM）執行分支事務（預提交）。
3. TM收集所有RM狀態，決定提交或回滾。
  缺點：同步阻塞，性能低。
2PC（兩階段提交）？
- 階段一（準備）：協調者詢問所有參與者是否可提交，參與者執行事務但不提交。
- 階段二（提交/回滾）：若所有參與者同意，協調者通知提交；否則回滾。
  缺點：同步阻塞、單點問題、數據不一致（協調者宕機）。
3PC（三階段提交）？
在2PC基礎上增加超時機制和預提交階段：
- CanCommit：詢問參與者是否具備條件。
- PreCommit：預執行事務。
- DoCommit：提交或回滾。
  減少阻塞，但仍可能數據不一致。
TCC（Try-Confirm-Cancel）？
業務層補償型方案：
- Try：預留資源（如凍結庫存）。
- Confirm：確認操作（扣減庫存）。
- Cancel：取消操作（釋放庫存）。
  需業務實現補償邏輯，保證最終一致性。
Seata解決方案？
- AT模式（默認）：基于undo_log日志，實現兩階段提交（無侵入）。
- TCC模式：需業務實現Try/Confirm/Cancel接口。
- Saga模式：長事務補償流程。
- XA模式：基于數據庫XA協議。
如何選擇方案？考慮維度：
- 一致性要求（強/最終）
- 性能（吞吐、延遲）
- 業務侵入性
- 復雜度與維護成本
- 技術棧兼容性
Saga模式？
長事務解決方案：將大事務拆分為多個本地事務，每個事務有對應補償操作。失敗時逆向執行補償。
適用于業務流程長、低一致性要求的場景。
常見分布式事務框架及原理？
- Seata：AT/TCC/XA/Saga模式。
- RocketMQ事務消息：半消息機制實現最終一致性。
- LCN（早期）：基于代理連接池，模擬兩階段提交。
消息隊列解決分布式事務？
使用事務消息（如RocketMQ）：
1. 發送半消息（對消費者不可見）。
2. 執行本地事務。
3. 根據本地事務結果提交或回滾消息。
4. 消費者消費消息，保證最終一致性。