01 为什么Java面试总爱问分布式？
随着互联网业务的飞速发展，单体架构已难以满足高并发、高可用的需求。分布式系统通过将计算任务、数据存储分散到多台服务器上，实现了系统的横向扩展能力。在Java面试中问到分布式时，面试官不仅仅是在考察你对某个框架（如Spring Cloud, Dubbo）的使用，更是在考察你的系统思维、权衡取舍的能力以及对底层原理的理解。
许多候选人往往只记住了“怎么用”，却忽略了“为什么这么设计”。例如，为什么Redis要采用主从复制？为什么消息队列能保证最终一致性？这些问题的答案，都藏在你对分布式本质的理解中。接下来，我们将通过几个核心维度，深入剖析这一领域。
⚡ 高可用性 (High Availability)
系统无故障运行的能力。在面试中，常考察如何通过冗余部署、故障转移（Failover）机制来保证服务不中断。
⚡ 高并发 (High Concurrency)
系统同时处理大量请求的能力。涉及负载均衡、缓存策略、异步处理等核心技术手段。
⚡ 可扩展性 (Scalability)
系统通过增加节点来提升性能的能力。分为水平扩展（Scale-out）和垂直扩展（Scale-up）。
02 分布式理论基石：CAP与BASE
理解分布式系统，必须从理论开始。CAP定理和BAS E理论是分布式领域的“宪法”。在Java面试中问到分布式时，几乎必考这两个概念。
2.1 CAP定理的权衡
CAP定理指出，在一个分布式系统中，Consistency（一致性）、Availability（可用性）、Partition Tolerance（分区容错性）这三者无法同时满足，最多只能同时满足两个。
- 一致性 (C)：所有节点在同一时间拥有相同的数据。
- 可用性 (A)：每个请求都能在合理时间内收到非错误的响应。
- 分区容错性 (P)：系统在面对网络分区故障时，仍能继续运行。
由于网络分区在现代分布式系统中是不可避免的，因此P是必须的。这就意味着我们必须在C和A之间做出选择。
| 类型 | 代表系统 | 特点 | 应用场景 |
|---|---|---|---|
| CA | 传统关系型数据库 (单机) | 强一致性，高可用，无分区容错 | 金融交易核心模块 |
| CP | ZooKeeper, HBase | 强一致性，分区容错，牺牲可用性 | 注册中心，配置中心 |
| AP | Redis, DynamoDB | 高可用，分区容错，牺牲强一致性 | 社交网络，商品列表 |
2.2 BASE理论的实践
BASE理论是对CAP中AP的延伸，它主张通过牺牲强一致性来获得可用性，但要求数据达到最终一致性。
- Basic Availability (基本可用)：系统在出现故障时，允许损失部分可用性（如响应时间变长，功能降级）。
- Soft State (软状态)：允许系统存在中间状态，而该中间状态不会影响系统整体可用性。
- Eventual Consistency (最终一致性)：系统中的所有数据副本，在经过一段时间的同步后，最终能够达到一致的状态。
03 微服务架构与分布式治理
微服务是分布式思想在架构层面的具体落地。在Java面试中问到分布式时，面试官往往会聚焦于微服务组件之间的协作与治理。
3.1 注册中心：服务发现的枢纽
注册中心（如Zookeeper, Eureka, Nacos）是微服务架构的大脑，负责服务的注册与发现。
Zookeeper基于CP模型，利用ZNode和Watcher机制实现服务注册与配置管理。它保证了数据的强一致性，适合对一致性要求极高的场景，如Dubbo早期版本。
Eureka基于AP模型，采用心跳机制保持服务实例活跃。它允许在极端网络故障下，服务列表不一致，但能保证服务的高可用。
Nacos是阿里开源的最新选择，同时支持CP和AP模式切换，并集成了配置管理功能，是目前Spring Cloud Alibaba的核心组件。
3.2 负载均衡：流量的艺术
负载均衡分为服务端负载均衡和客户端负载均衡。
- 服务端负载均衡：如Nginx，流量先到达Nginx，再由Nginx转发给后端服务。适合外部流量入口。
- 客户端负载均衡：如Ribbon，服务消费者在本地维护服务提供者列表，自行决定调用哪个实例。适合微服务内部调用。
常见的负载均衡算法包括：轮询（Round Robin）、随机（Random）、加权轮询、一致性哈希（Consistent Hashing）。一致性哈希特别适用于缓存集群，能最大程度减少节点变动导致的缓存失效。
3.3 服务熔断与降级：系统的自我保护
当依赖的服务出现不可用或响应过慢时，为了防止雪崩效应，需要引入熔断机制。
熔断器 (Circuit Breaker)有三种状态：
- 关闭 (Closed)：正常状态，请求正常通过。
- 打开 (Open)：错误率超过阈值，直接拒绝请求或返回默认值。
- 半开 (Half-Open)：尝试允许少量请求通过，若成功则关闭熔断，若失败则继续打开。
降级 (Degradation)是指在系统负载过高时，暂时关闭某些非核心功能（如评论、推荐），以保证核心业务（如下单、支付）的正常运行。
04 分布式事务：最难啃的骨头
在单体应用中，本地事务（Local Transaction）通过ACID特性保证数据一致性。但在分布式系统中，跨服务、跨数据库的分布式事务成为了一大难题。这是Java面试中问到分布式时的高频难点。
4.1 常见解决方案
强一致性方案。分为准备阶段（询问参与者是否可提交）和提交阶段（执行提交或回滚）。
缺点：阻塞性强，单点故障风险，性能较差。通常用于数据库层面的XA事务。
应用层面的补偿型事务。
Try：预留业务资源；Confirm：确认执行业务；Cancel：释放预留资源。
优点：性能较好，无锁；缺点：代码侵入性强，需实现三个接口。
最终一致性方案。利用消息队列（如RocketMQ）的事务消息功能，保证本地事务与消息发送的最终一致性。
优点：解耦，性能高，适合互联网场景。
4.2 Seata框架简介
Seata（Simple Extensible Autonomous Transaction Architecture）是阿里开源的分布式事务解决方案。它提供了AT、TCC、SAGA、XA等多种模式，其中AT模式因其无侵入性而最受欢迎。AT模式通过全局锁和Undo Log实现全局事务的回滚，极大地简化了开发者的工作。
05 缓存与消息队列：性能的加速器
为了提升系统性能，Redis和RabbitMQ/Kafka是分布式架构中不可或缺的组件。
5.1 Redis缓存一致性
缓存与数据库的双写一致性是经典问题。
- 先更新数据库，再删除缓存：推荐做法。因为删除缓存比更新缓存更安全，避免脏数据。
- 延时双删：先删缓存，更新数据库，再延时删除缓存，解决并发下的不一致问题。
5.2 消息队列的可靠性
消息队列在分布式系统中承担着异步解耦、削峰填谷、流量控制等职责。如何保证消息不丢失？
- 生产者：开启Confirm机制，确保消息到达Broker。
- Broker：设置同步刷盘、多副本同步复制。
- 消费者：手动ACK，确保业务处理成功后再确认消费。
06 网友还关心：高频面试问答
基于对大量面试真题的分析，我们整理了以下Java面试中问到分布式时的高频问题及深度解答。