java面试题（九），现在都这么卷了，八股文还适用吗？

一、并发控制

1. 分布式锁的实现方案对比及适用场景？

方案	核心原理	优点	缺点
Redis锁	SETNX+过期时间或RedLock算法	高性能、易扩展	主从切换可能丢失锁、锁续期复杂
Zookeeper锁	临时顺序节点+Watcher监听	强一致性、无死锁、支持公平锁	性能低、依赖Zookeeper集群
数据库锁	唯一约束或乐观锁	实现简单、兼容性强	高并发下性能差、死锁风险

2. Redis分布式锁的缺陷及RedLock算法优化？

缺陷：
主从同步延迟：主节点宕机时，异步复制可能导致锁丢失。
锁续期问题：需额外机制续期，否则可能提前释放锁。
RedLock优化：
向N个Redis节点一次申请锁，半数以上成功才算获取锁。

3. Zookeeper分布式锁的实现原理（临时有序节点）？

加锁流程：
客户端在所路径下创建临时与有序节点（如/lock/resource_000001）
检查是否为最小序号节点，是则获取锁；否则监听前序节点变更时间
释放锁：
删除临时节点或会话结束自动释放
优势：
避免惊群效应（仅监听前序节点），保证公平性

4. 数据库乐观锁与悲观锁在分布式场景的应用？

类型	实现方式	使用场景
乐观锁	版本号或时间戳，更新时校验	读多写少、冲突概率低场景
悲观锁	SELECT … FOR UPDATE行锁	写操作频繁、数据强一致场景

5. 幂等性设计解决方案（Token/唯一索引/去重表）？

Token机制：请求前预生成唯一Token，服务端校验后删除
唯一索引：数据库对业务字段建立唯一索引防重复
去重表：记录请求唯一标识（如流水号），插入失败则拦截重复请求

6. 分布式系统如何实现CAS操作？

Redis实现：利用WATCH+MULTI命令监听键变化，事务提交时校验版本
数据库实现：通过UPDATE ... WHERE condition 原子操作，返回影响行数判断是否成功

7. 分布式锁的续期机制设计（如Watch Dog）？

Watch Dog：后台线程周期性（如1/3过期时间）续期锁，防止业务未完成锁超时释放
Zookeeper自动续期：会话心跳保持临时节点存活，无需额外机制。

8. 分布式系统如何解决ABA问题？

版本号递增：每次操作版本号+1，确保修改基于最新状态。
时间戳标记：记录操作时间戳，校验时间顺序有效性。

9. 分布式限流与单机限流的协同设计？

全局配额分配：中心节点分配每台机器限流阈值
分层限流：单机限流（Guava RateLimiter）兜底，结合分布式限流（如令牌桶算法），控制全局QPS

10. 分布式系统如何实现读写锁？

Zookeeper实现：
读锁：创建Read_前缀临时节点，仅需无Write_更小序号节点存在
写锁：创建Write前缀临时节点，需为最小序号节点

Redis实现：
通过Redisson的RReadWriteLock，结合Hash结构存储读写状态

11. 分布式信号量的实现原理？

Zookeeper实现：
创建固定数量临时节点作为信号量资源，获取时减少节点，释放时增加节点。
支持超时等待和公平获取
Redis实现：
通过DECR原子操作减少计数器

12. 分布式系统如何实现优先级队列？

有序数据结构：
使用Redis的ZSET，通过score字段标识优先级，消费者按ZRANGEBYSCORE顺序获取任务
消息队列（如Kafka、RabbitMQ）通过分区或插件支持优先级队列，高优先级任务分配到独立分区或插队处理。

分层调度架构：
Apache Pulsar支持多级存储，结合优先级标签实现任务分层处理。

13. 分布式系统如何避免缓存击穿/雪崩/穿透？

问题|解决方案
缓存穿透|布隆过滤器拦截无效请求+空值缓存
缓存击穿|互斥锁（Redis SETNX）限制并发并重建缓存
缓存雪崩|分散缓存过期时间（基础时间+随机偏移）
热点数据|预加载热点数据+永不过期策略

14. 分布式系统如何实现并发控制（如乐观锁版本号）？

数据库实现‌：更新时校验版本号
Redis实现‌：WATCH+MULTI监听键变化，事务提交时校验数据版本。

15. 分布式系统如何实现原子计数器？

Redis INCR：INCR|DECR命令原子递减计数器。高性能、低延迟。
数据库序列：自增字段或序列对象（如MySQL AUTO_INCREMENT），强一致性。

16. 分布式系统如何实现全局序列号生成？

雪花算法：时间戳（41bit）+ 机器ID（10bit）+ 序列号（12bit），保障分布式唯一性
Redis原子递增：通过INCRBY生成连续序列号，结合机器标识避免冲突

17. 分布式系统如何实现延迟任务调度？

Redis ZSET方案：任务ID作为成员，执行时间戳为score，定时扫描ZRANGEBYSCORE获取到期任务
消息队列延迟队列：RabbitMQ通过TTL+死信队列实现延迟投递

18. 分布式系统如何实现资源配额管理？

令牌桶算法：Redis维护令牌数，DECR原子操作消耗令牌，定时任务补充令牌
配额协调：Zookeeper临时节点记录资源分配状态，实时调整各节点配额。

19. 分布式系统如何实现批量任务并发控制？

分布式信号量：Redis通过DECR控制并发数，任务完成时INCR释放资源
分片锁机制：按任务ID哈希分片，每个分片独立加锁（如Redisson的RLock）

20. 分布式系统如何实现死锁检测与解除？

超时释放：锁设置自动过期时间（如Redis过期时间），避免死锁长期存在。
资源依赖图扫描：周期性检测节点资源持有与等待关系，强制释放循环依赖的锁。
协调器接入：Zookeeper通过会话心跳检测节点存活，节点失效时自动释放其持有的锁。

二、算法与协议

1. Paxos算法的工作流程及角色分工？

角色分工：
Proposer：提出提案（包含编号和值）并推动共识达成。
Acceptor：接受提案并投票，承诺不接受更低编号的提案。
Learner：学习最终选定值并同步到系统。
工作流程：
准备阶段：
Proposer发送Prepare(N)请求（N为唯一递增编号）。
Acceptor若未响应过更高编号的请求，则回复已接收的最大提案值；负责拒绝。
批准阶段：
Proposer收集半数以上Acceptor的响应后，发送Accept（N，V），请求Accept（N，V）。
Acceptor接受提案并持久化，Learner同步最大值。

2. Raft算法与Paxos的核心差异？

维度	Raft	Paxos
角色设计	明确Leader、Follower、Candidate角色	动态Proposer/Acceptor角色。
流程复杂度	通过日志复制和Leader选举简化流程	两阶段提交，存在活锁风险。
可理解性	易于工程实现和调试	理论严谨但实现复杂。
容错机制	Leader故障后快速选举新Leader	依赖多数派决策容错。

3. Gossip协议的传播机制及优缺点？

传播机制：
反熵模式：节点周期性随机选择邻居交换全量数据，最终一致。
传谣模式：仅传播新数据，降低带宽消耗。
优缺点：
优点：去中心化、高容错、动态扩展性强。
缺点：最终一致性延迟高、消息冗余可能引发网络风暴。

4. 一致性哈希算法的虚拟节点设计？

为每个物理节点生成多个虚拟节点（如200个），分散到哈希环。
数据定位时映射到虚拟节点，再转发至实际物理节点。

5. 分布式共识算法（如ZAB协议）的实现原理？

设置目标：为ZooKeeper设计，强一致性且高可用。
核心阶段：
恢复模式：选举Leader并同步历史日志到半数以上Follower。
广播模式：Leader将客户端请求封装为事务提案，按顺序广播并提交。

6. 分布式选举算法（如Bully算法）的实现？

核心规则：
节点故障时，存活节点中ID最大者发起选举冰冠波胜利消息。
低ID节点收到高节点选举消息后退出竞争。
缺陷：高ID节点频繁故障可能导致选举震荡。

7. 分布式ID生成算法（雪花算法/UIDGenerator）？

雪花算法‌：
时间戳（41bit） + 机器ID（10bit） + 序列号（12bit），单机每秒可生成409.6万ID。
‌UIDGenerator‌：
基于雪花算法优化，支持自定义时间基准和机器ID分配策略

8. 分布式系统如何实现Lease机制？

原理：中心节点向客户端授予租约（约10秒），客户端需定期续约。
应用场景：分布式锁自动释放、缓存失效控制。

9. 分布式快照算法（Chandy-Lamport算法）原理？

原理：
协调者向所有进程发送标记，进程接到后记录本地状态并转发标记。
收集所有进程状态及通道中为处理消息，形成全局一致性快照。

10. 分布式系统中的Vector Clock实现原理？

设计：每个事件关联向量时钟，节点更新时递增自身计数器并合并其他节点值。
作用：检测并发时间冲突，支持最终一致性系统。

11. 分布式系统如何实现Quorum机制？

NWR模型：
写操作成功需写入W个副本，读操作需读取R个副本，满足W+R>N（N为总副本数）。
保障强一致性（W=N、R=1）或高可用（如W=1、R=N）。

12. 分布式系统的CRDT（Conflict-Free Replicated Data Type）原理？

核心目标
允许分布式节点独立更新数据副本，无需协调即可自动解决冲突，最终达成一致性
实现分类
基于状态：节点同步完整状态，依赖合并操作的数学特性（交换性、结核性、幂等性）保证一致性。
基于操作：节点仅同步操作指令，需通信层保障操作传输的因果顺序。
数学特定
交换性：操作顺序不影响最终结果。
幂等性：重复操作不影响状态（如集合去重）。

13. 分布式事务的Two-Phase Commit优化方案？

传统2PC的核心问题
同步阻塞：参与者在PREPARE阶段锁定资源后，必须等待协调者的最终决策，无法释放资源。
单点故障：协调者宕机时，参与者可能长期阻塞甚至状态不一致。
数据不一致风险：网络分区或参与者宕机恢复后，部分节点可能未收到COMMIT/ABORT指令。
优化方案
超时机制与协调者容灾：参与者超时回滚、协调者集群化。
异步化与消息队列解耦：异步2PC、事务状态持久化。

14. 分布式系统的Leader-Follower模式设计？

角色分工
Leader：接受客户端请求并协调数据同步，负责决策与实物提交。
Follower：被动复制Leader数据，仅响应读请求或故障时参与选举。
核心机制
选举协议：基于Raft或ZAB协议，通过多数派投票选举出新Leader。
日志复制：Leader将操作封装为有序日志广播，Follower持久化后反馈确认。
容错性：
Leader故障后，Follower基于超时机制触发选举，保障服务连续性。

15. 分布式系统的水印（Watermark）机制？

核心作用
处理乱序事件流，动态标记时间进度，触发窗口计算并容忍延迟数据。
生成方式
周期性生成：基于数据流中的最大事件时间减去固定延迟（如当前最大事件时间-5秒）
启发式生成：结合数据到达速率动态调整延迟阈值，适应网络波动场景。
处理机制
窗口触发：当水印时间超过窗口结束时间，触发窗口聚合操作并关闭窗口
延迟数据处理：允许设置allowedLateneww，窗口关闭后仍可处理延迟到达但为超时的数据。

16. 分布式系统的Checkpoint机制设计？

核心目标
周期性保存分布式任务状态快照，支持故障恢复至一致性状态。
实现步骤
屏障注入：JobManager向数据源插入Checkpoint屏障，屏障岁数据流传播。
状态快照：同步阶段-任务接受屏障后暂停处理，将内存状态持久化到存储系统（如HDFS）。异步阶段-后台线程异步上传大状态文件（如RocksDB增量快照）
全局一致性：所有节点完成快照后，JobManager标记Checkpoint为完成
容错保障
Exactly-Once语义：通过两阶段提交协议（2PC）确保Sink端事务一致性。

17. 分布式系统的消息重试与去重策略？

重试机制：指数退避、死信队列。
去重方案：全局唯一标识、幂等性设计、定期检索、Token预防。

18. 分布式系统的容错编码（如Erasure Coding）？

核心原理
将数据分块为k个原始块，生成m个冗余校验块，总块数n = m + k，容忍最多m个块丢失。
采用Reed-Solomon编码，通过矩阵运算生成校验块。

19. 分布式系统的负载均衡算法？

负载指标采集‌
实时监控节点CPU、内存、队列长度等指标，计算综合负载权重8。
‌调度策略‌
‌加权轮询（WRR）‌：按节点权重分配请求，高权重节点获得更多流量。
‌一致性哈希优化‌：引入虚拟节点分散热点，新节点加入时仅迁移部分数据。
‌最小连接数‌：将新请求分配给当前活跃连接最少的节点。

20. 分布式系统的动态负载均衡算法？

时间序列预测
ARIMA模型：基于历史负载数据拟合自回归移动平均模型，预测未来负载趋势。
LSTM网络：使用循环神经网络捕捉复杂变换的长期依赖关系。
应用场景
弹性伸缩：根据预测结果提前扩容/缩容资源，避免资源不足或浪费。

21. RAFT与ZAB协议有何区别？

对比维度	RAFT协议	ZAB协议
设计目标	通用分布式一致性协议，强调简化实现与易于教学	专为Zookeeper定制，优化高频读，低频写的协调服务场景
角色划分	Leader（唯一处理写请求）、Follower、Candidate	Leader（事务协调）、Follower（参与投票），Observer（仅读，不参与投票）
选举机制	随机超时触发选举，高Term节点优先胜出，无需日志同步	选举需保证新Leader日志最新，依赖Epoch标识Leader周期
日志复制	Leader单向广播日志条目，半数以上节点存活即可工作，宕机节点重启后自动追补日志	两阶段提交：Proposal广播→半数ACK→Commit广播，保证全局顺序提交
容错性	半数以上节点存活即可工作，宕机节点重启后自动追补日志	依赖Zxid保证崩溃恢复后一致性，需重放日志
性能瓶颈	Leader单点处理写请求，新节点全量同步时负载高	事务广播需遍历所有节点，网络开销较大
适用场景	通用分布式系统（如ETCD、Consul），更适合用于通用一致性场景	分布式协调服务（如配置管理、分布式锁）更适合分布式协调服务的高效实现