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

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

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

方法论 | 基础核心篇 | 并发+JVM | Spring+数据库 | Redis缓存 |高阶架构← 你在看 | 高阶特性实战篇

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

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

📂本篇题目导航

第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：接受偶尔晚回消息（基本可用），允许过程中信息不对称（软状态），但最终会和好如初（最终一致性）。

🔍 关键差异速记

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

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

一图看清

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

比喻记忆：四种发号方式

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

🔍 方案对比速记

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

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

一图看清

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

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

• 前端：把座位图贴在全国各便利店（CDN），每人只能填一次表（按钮置灰）。
• 网关：保安分批放500人进大厅（限流），先解个数学题证明你是人（验证码）。
• 服务层：进大厅先拿排号（消息队列削峰），大厅最多容纳2000人（分布式信号量），超出者在外等着。
• 数据层：库房小黑板上画正字扣数（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无侵入。

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

一图看清

同步通信： RPC（Dubbo/gRPC）→ TCP，高性能，耦合较强 HTTP/REST（OpenFeign）→ 通用，文本协议，易调试 异步通信： 消息队列（Kafka/RabbitMQ）→ 解耦削峰，最终一致 注册发现： 服务提供者 → 注册中心（Nacos/Eureka/Consul） → 服务消费者 健康检查 + 自动剔除 + 负载均衡

比喻记忆：外卖平台

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

🔍 通信方式对比

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

第74题：Service Mesh 服务网格

一图看清

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

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

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

🔍 核心差异

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

第75题：接口幂等性保证

一图看清

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

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

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

🔍 方案对比

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

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

一图看清

写操作 → 命令模型(Command) → 写入数据库 ↓ 事件同步 读操作 → 查询模型(Query) → 专用读视图（已优化结构，免JOIN） 适用场景： 读写比例差异大、读需要多表聚合、读写性能要求不同

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

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

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

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

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

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