《Java面试85题图解版（三）》上篇：高阶架构设计篇

📂 Java面试85题图解版 · 全系列7篇

📌 全系列总目录 | 💡 每道题 = 结构图 → 场景比喻 → 对比表 → 一句话总结

阅读提示：这是"图解+比喻+一句话总结"面试题库的第五篇，覆盖分布式系统与架构设计共8道题。从CAP理论到CQRS，每道题都是大厂面试官在最后环节用来"定级"的高价值题目。结构图 → 场景比喻 → 关键对比表 → 一句话总结，通勤刷两遍，面试有话说。

📂 本篇题目导航

题号	题目	比喻关键词
69	CAP理论与BASE理论	异地恋
70	分布式ID生成方案	四种发号方式
71	秒杀系统设计	抢周杰伦演唱会票
72	分布式事务方案对比	婚宴预订流程
73	微服务通信与注册发现	外卖平台
74	Service Mesh服务网格	物业管家 vs 私家管家
75	接口幂等性	菜鸟驿站取快递
76	CQRS命令查询分离	图书馆前台 vs 书库

第69题：CAP 理论与 BASE 理论

一图看清

复制代码

CAP：一致性(C) + 可用性(A) + 分区容错性(P) → 最多同时满足两个
网络分区(P)必然存在 → 系统只能是 CP 或 AP

CP（强一致+牺牲部分可用性）：ZooKeeper、etcd
AP（高可用+牺牲实时一致性）：Eureka、Cassandra

BASE：对AP的延伸实践
  Basically Available（基本可用）
  Soft state（软状态）
  Eventually consistent（最终一致性）

比喻记忆 ：异地恋

CAP：你和另一半在两个城市（网络分区必然存在）。要么每天视频保持信息一致但累得要死（CP），要么各自活动偶尔报备但可能互相不知道对方在干嘛（AP）。
BASE：接受偶尔晚回消息（基本可用），允许过程中信息不对称（软状态），但最终会和好如初（最终一致性）。

🔍 关键差异速记

模型	核心取舍	典型产品
CP	强一致，部分不可用	ZooKeeper、etcd、Consul
AP	高可用，最终一致	Eureka、Cassandra、DynamoDB

💡 一句话总结 ：CAP三选二，网络分区必须保留P，留CP或AP，BASE为AP提供实践指南。

第70题：分布式 ID 生成方案

一图看清

复制代码

UUID：本地生成，简单唯一 → 无序、字符串长、DB主键插入性能差
数据库自增/号段：有序递增，依赖DB → 一次取一个号段缓存（美团Leaf）
Redis INCR：性能高 → 需持久化机制防止丢号
雪花算法Snowflake：64bit，时间戳+机器ID+序列号 → 趋势递增，时钟回拨是坑
改进版：百度UidGenerator、美团Leaf → 解决时钟回拨问题

比喻记忆 ：四种发号方式

UUID：每个人自己编一个长随机号，保证不重，但号码毫无规律，不好归档。
数据库自增：只有一个发号机，大家排队领号。美团Leaf是"一次领100个号自己慢慢发"。
Redis：高速发号机，快但万一断电丢了一批号。
雪花算法：给每台机器分配一个编号前缀，各发各的，自带时间戳。唯一问题：机器时间如果倒流，可能发出重复号。

🔍 方案对比速记

方案	优点	缺点
UUID	极简，无依赖	无序，DB性能差
数据库号段	有序，可靠	依赖DB
Redis	快	持久化复杂
雪花算法	快，有序，无依赖	时钟回拨需处理

💡 一句话总结 ：UUID无序，数据库可靠有瓶颈，雪花算法主流但需处理时钟回拨。

第71题：如何设计秒杀系统

一图看清

复制代码

前端层：页面静态化+CDN加速、按钮防重复点击、验证码分流
网关层：恶意请求拦截、限流（令牌桶/漏桶）、负载均衡
服务层：消息队列削峰、Redis预减库存(DECR原子)、分布式信号量控制进入量
数据层：DB乐观锁最终扣减、读写分离、对账补偿

比喻记忆 ：周杰伦演唱会抢票

前端：把座位图贴在全国各便利店（CDN），每人只能填一次表（按钮置灰）。
网关：保安分批放500人进大厅（限流），先解个数学题证明你是人（验证码）。
服务层：进大厅先拿排号（消息队列削峰），大厅最多容纳2000人（分布式信号量），超出者在外等着。
数据层：库房小黑板上画正字扣数（Redis预减），付了款才在正式账本上记账（DB扣减）。每晚保安对账（补偿）。

🔍 各层职责速记

层级	核心职责	关键技术
前端	减少无效请求	CDN、按钮置灰、验证码
网关	限流与安全	令牌桶/漏桶、IP黑名单
服务	削峰与业务	MQ削峰、Redis预扣、信号量
数据	库存一致性	DB乐观锁、对账补偿

💡 一句话总结 ：秒杀=CDN散流+网关限流+队列削峰+Redis预扣+DB最终一致，层层过滤保护核心库存。

第72题：分布式事务方案对比

一图看清

复制代码

刚性事务：
  2PC（两阶段提交）→ 强一致，锁资源，同步阻塞，单点故障
  3PC（三阶段提交）→ 增加超时机制，降低阻塞，实现复杂

柔性事务（最终一致）：
  TCC → Try预留-Confirm确认-Cancel回滚，侵入大，性能较高
  SAGA → 事件驱动长事务，有正向+补偿，适合长流程
  可靠消息 → 本地事务+消息队列，保证最终一致性
  Seata AT → 无侵入代理SQL+undo log，自动补偿

比喻记忆 ：婚宴预订流程

2PC：司仪说"我先去酒店确认，再去花店确认，都OK才签"。全程锁死，别人订不了。
TCC：先试菜预留龙虾（Try），确认举行出菜（Confirm），取消就退菜（Cancel）。三个步骤都要提前写好。
SAGA：下单→付定金→试婚纱→酒店布置，每步成功自动发消息给下一步。哪步失败一步步倒退（补偿），链条越长越复杂。
可靠消息：你记下"发请柬"在待办表，存好了一定发，存不好回滚。
Seata AT：全包婚礼策划，你说"我要在北京结婚"，策划师自动订酒店、记撤销方案，出问题全回滚。

🔍 五大方案速记

方案	一致性	性能	侵入性	适用场景
2PC	强一致	低	低	短事务、资源少
TCC	最终	较高	高	资金扣减、红包
SAGA	最终	高	中	长流程（下单→物流）
可靠消息	最终	高	中	异步解耦场景
Seata AT	最终	较高	低	快速接入，不想写补偿

💡 一句话总结 ：2PC全票通过才执行，TCC三部曲预留→确认→取消，SAGA正走补退，Seata AT无侵入。

第73题：微服务通信方式与注册发现

一图看清

复制代码

同步通信：
  RPC（Dubbo/gRPC）→ TCP，高性能，耦合较强
  HTTP/REST（OpenFeign）→ 通用，文本协议，易调试

异步通信：
  消息队列（Kafka/RabbitMQ）→ 解耦削峰，最终一致

注册发现：
  服务提供者 → 注册中心（Nacos/Eureka/Consul） → 服务消费者
  健康检查 + 自动剔除 + 负载均衡

比喻记忆 ：外卖平台

RPC：直接打商家电话，快但得双方同语言（协议）。
HTTP：在平台页面下单，谁都能看懂，稍微慢一点但通用。
消息队列：外卖单号流转，下了单不用等着，后厨按单号做，好了通知配送员。
注册中心：商家入驻平台（注册），用户打开App就能搜到（发现）。商家关门（下线），平台立刻下架（剔除）。

🔍 通信方式对比

方式	耦合度	性能	适用场景
RPC	较高	TCP，高效	内网高性能调用
HTTP/REST	中	文本协议，略慢	跨语言，易调试
消息队列	低	最终一致	削峰解耦，异步

💡 一句话总结 ：同步RPC/HTTP实时调，异步消息解耦削峰，注册中心动态管服务。

第74题：Service Mesh 服务网格

一图看清

复制代码

传统微服务治理：SDK集成（Spring Cloud/Dubbo），语言绑定，升级维护成本高
Service Mesh：治理能力下沉到Sidecar代理（Envoy），应用无感知
  控制面（Istio Pilot）：管理配置、路由、安全策略
  数据面（Envoy）：代理流量，处理通信

比喻记忆 ：物业管家 vs 私家管家

传统SDK：每家自己雇一个管家（代码里引入依赖），各家规矩不同，管家风格也不一样，换管家（升级SDK）全家跟着折腾。
Service Mesh：小区物业统一配备管家（Sidecar代理），每家分配一个，负责接待、安保、收发快递。住户不用自己操心，标准统一。换语言换管家，规矩不变。

🔍 核心差异

维度	传统SDK	Service Mesh
侵入性	代码引入依赖	零侵入，Sidecar透明代理
多语言	每种语言一套SDK	统一代理，语言无关
升级	应用重启	Sidecar热更新
复杂度	简单	增加网络开销和运维复杂度

💡 一句话总结 ：Service Mesh将服务治理下沉到Sidecar，业务代码零侵入，多语言统一管理。

第75题：接口幂等性保证

一图看清

复制代码

幂等：一次请求和多次相同请求，结果一致，无副作用

方案：
  Token机制 → 先取Token，提交时校验并删除（防重复提交）
  分布式锁 → 获取锁执行业务，释放锁（防并发）
  数据库唯一索引 → 重复插入直接报错（兜底）
  乐观锁 → UPDATE...WHERE version=?，影响行数0即已处理（状态流转）

比喻记忆 ：菜鸟驿站取快递

Token机制：App先领取件码，到驿站出示，工作人员扫完作废。你弟再用同一个码，已经无效。
分布式锁：自提柜同时只能一人开柜门。你取完关上门，下一个才能开。
唯一索引：每个快递有唯一运单号，系统里重复录入直接报错"已存在"。
乐观锁：包裹从"待取"变"已取"，更新时检查状态是否还是"待取"，不是就说明你弟已帮你取了。

🔍 方案对比

方案	原理	适用场景
Token	提交时校验并删除Token	表单重复提交
分布式锁	Redis/ZK加锁	库存扣减、余额
唯一索引	DB唯一约束	流水号兜底
乐观锁	版本号比对	状态流转

💡 一句话总结 ：幂等=前端Token+中间锁+DB唯一索引/乐观锁，三层防护确保一次和多次一致。

第76题：CQRS 命令查询职责分离

一图看清

复制代码

写操作 → 命令模型(Command) → 写入数据库
                                   ↓ 事件同步
读操作 → 查询模型(Query) → 专用读视图（已优化结构，免JOIN）

适用场景：
  读写比例差异大、读需要多表聚合、读写性能要求不同

比喻记忆 ：图书馆前台 vs 书库

命令模型：书库管理员，负责新书上架、旧书下架、分类调整。关注数据正确。
查询模型：前台检索电脑，书单提前整理好（查询视图），读者搜"村上春树"直接出结果，不用每次去书库翻找。
同步：书库变动后通知检索系统更新索引，稍微延迟但可接受。

💡 一句话总结 ：CQRS读写分离模型：写走命令保一致，读走查询保效率，各自独立优化。

上一篇： 进阶深化（下）：Redis缓存

下一篇： 高阶特性实战篇 ------ 全系列终篇：Java 21虚拟线程（共享管家）、云原生容器化、千万大表优化、JVM调优案例、策略模式实战......面试弹药库配齐。

👉 点击关注我 📂 返回全系列导航