分布式系统面试很少让你单独背一个 CAP 定义。面试官通常会从某个业务问题开始追问：服务为什么要拆到多个节点？网络超时后能不能重试？锁提前过期怎么办？跨服务的数据如何保持一致？
这篇文章是 JavaGuide 分布式系统专题的复习入口，按分布式理论、RPC 与网关、分布式 ID/锁/事务、配置中心与 ZooKeeper 四部分整理。每部分只列复习时需要抓住的问题，答案和实现细节放在对应专题文章中。
时间比较紧的话，可以先看 分布式系统常见面试题总结，把不会的问题标出来，再回到本文补原理和工程细节。
刚接触分布式系统时，很多人会先被一串名词砸中：CAP、BASE、Paxos、Raft、分布式锁、分布式事务。
这些概念都绕不开，但入门时直接钻进去，容易把分布式系统学成一堆互不相干的术语。更好的切入口是一个更土但更实用的问题：原来一台机器、一个进程、一个数据库就能完成的事情，为什么后来要拆到多台机器上？拆完以后，为什么一个超时、一次重试、一条消息重复投递，都会牵出这么多设计问题？
这篇文章先把“分布式系统是什么”讲清楚。Paxos、Raft、分布式事务不会展开推导，只把它们放回主线里，知道它们大概在解决哪类麻烦。
一个定时任务部署了 3 个实例，到了凌晨 2 点，到底谁来跑这批任务？
如果 3 个实例都跑，数据可能被重复处理；如果 3 个实例都等别人跑，任务就会漏掉。缓存集群、消息队列、配置中心、分布式锁也会遇到类似问题：节点多了以后，系统必须有人决定“谁负责什么”“谁现在还活着”“这次变更按什么顺序生效”。
这就是分布式系统里的协调问题。
不过，这里要先区分两件事：只选出一个执行者，和业务只生效一次。
选主、分布式锁或数据库抢占可以减少多个实例同时执行，但无法单独保证端到端的 exactly-once。执行节点可能已经处理成功，却在更新任务状态前宕机；调度系统为了避免漏任务，只能再次派发。Kubernetes CronJob 官方文档也提醒过，CronJob 创建 Job 的时间是近似的，某些情况下可能创建两个 Job，也可能没有创建 Job，因此 Job 本身应该设计成幂等。
系统设计基础专题关注后端开发里最容易被忽略、但长期影响最大的工程能力：接口怎么设计、代码怎么命名、坏味道怎么识别、测试怎么写、需求到交付的过程如何组织。
这些内容看起来不像缓存、消息队列、分库分表那样“硬核”，但它们决定了系统能不能被团队长期维护。
高可用面试题经常从一句“系统怎么保证不挂”开始，随后追问单点故障、限流熔断、超时重试、接口幂等和异地容灾。只罗列组件通常答不完整，还要说明故障如何被发现、影响怎样被控制、服务如何恢复，以及数据能否保持正确。
这篇文章是 JavaGuide 高可用专题的复习入口，按高可用基础、冗余与容灾、限流降级熔断、超时重试幂等、性能测试与故障治理五部分整理。答案和实现细节放在对应专题文章中。
高性能系统面试通常从一个具体症状开始：接口变慢、数据库 CPU 升高、消息开始积压，或者大促流量超过了现有容量。回答时先确认 QPS、P99、数据量和读写比例，再沿着请求链查入口、应用、缓存、数据库和消息队列，直接报出“加缓存、上 MQ、分库分表”很容易被继续追问。
我做 AgentInvest 多智能体股票分析系统时，把任务交给了四个角色。研究员先完成基础研究，技术分析师和舆情分析师并行补充，投资经理最后汇总。每个角色内部使用 ReAct 调用工具，外层流水线控制顺序、并发和失败条件。
角色跑起来以后，工程问题才真正出现。子任务拆到什么程度，两个 Worker 能不能同时写状态，一个分支超时后是否继续，都会直接影响最终结果。面试官追问多 Agent 项目时，通常也会沿着这些问题往下问。
这份 高可用系统知识体系 面向后端学习、系统设计和面试复习，围绕“减少故障、隔离故障、快速恢复、降低重复请求和异常流量影响”整理本站高可用相关文章。
这份 分布式系统知识体系 面向后端学习、系统设计和面试复习，按“分布式入门 -> 通信调用 -> 服务治理 -> 一致性与协调 -> 工程实践”的顺序整理本站分布式相关文章。
这份 高性能系统知识体系 面向后端学习、系统设计和面试复习，围绕“减少延迟、提升吞吐、削峰填谷、降低数据库压力、优化数据访问路径”整理本站高性能相关文章。
