这份 分布式系统知识体系 面向后端学习、系统设计和面试复习，按“分布式入门 -> 通信调用 -> 服务治理 -> 一致性与协调 -> 工程实践”的顺序整理本站分布式相关文章。

分布式系统面试很少让你单独背一个 CAP 定义。面试官通常会从某个业务问题开始追问：服务为什么要拆到多个节点？网络超时后能不能重试？锁提前过期怎么办？跨服务的数据如何保持一致？

这篇文章是 JavaGuide 分布式系统专题的复习入口，按分布式理论、RPC 与网关、分布式 ID/锁/事务、配置中心与 ZooKeeper 四部分整理。每部分只列复习时需要抓住的问题，答案和实现细节放在对应专题文章中。

时间比较紧的话，可以先看 分布式系统常见面试题总结，把不会的问题标出来，再回到本文补原理和工程细节。

刚接触分布式系统时，很多人会先被一串名词砸中：CAP、BASE、Paxos、Raft、分布式锁、分布式事务。

这些概念都绕不开，但入门时直接钻进去，容易把分布式系统学成一堆互不相干的术语。更好的切入口是一个更土但更实用的问题：原来一台机器、一个进程、一个数据库就能完成的事情，为什么后来要拆到多台机器上？拆完以后，为什么一个超时、一次重试、一条消息重复投递，都会牵出这么多设计问题？

这篇文章先把“分布式系统是什么”讲清楚。Paxos、Raft、分布式事务不会展开推导，只把它们放回主线里，知道它们大概在解决哪类麻烦。

什么是分布式系统？

这份 高可用系统知识体系 面向后端学习、系统设计和面试复习，围绕“减少故障、隔离故障、快速恢复、降低重复请求和异常流量影响”整理本站高可用相关文章。

不管是平时刷的购物网站、用的在线支付，还是公司内部的核心业务系统，用户对"服务不可用"的容忍度越来越低。一次持续几分钟的故障，可能就会带来大量用户流失甚至直接的经济损失。

所以，如何让系统在各种异常情况下依然能提供稳定的服务，就成了后端开发和架构设计中绕不开的话题。这篇文章会把高可用系统设计的核心思路和常见方案梳理一遍，包括 SLA 指标、单点故障治理、限流熔断、服务降级、缓存高可用、异步削峰、冗余容灾、灰度发布和故障恢复等。

什么是高可用？可用性的判断标准是啥？

高可用（High Availability，简称 HA） 是指系统在绝大部分时间内能够持续提供正常服务的能力。高可用代表系统即使在发生硬件故障或者系统升级的时候，服务仍然是可用的。

高可用面试题经常从一句“系统怎么保证不挂”开始，随后追问单点故障、限流熔断、超时重试、接口幂等和异地容灾。只罗列组件通常答不完整，还要说明故障如何被发现、影响怎样被控制、服务如何恢复，以及数据能否保持正确。

这篇文章是 JavaGuide 高可用专题的复习入口，按高可用基础、冗余与容灾、限流降级熔断、超时重试幂等、性能测试与故障治理五部分整理。答案和实现细节放在对应专题文章中。

这份 高性能系统知识体系 面向后端学习、系统设计和面试复习，围绕“减少延迟、提升吞吐、削峰填谷、降低数据库压力、优化数据访问路径”整理本站高性能相关文章。

高性能系统面试通常从一个具体症状开始：接口变慢、数据库 CPU 升高、消息开始积压，或者大促流量超过了现有容量。回答时先确认 QPS、P99、数据量和读写比例，再沿着请求链查入口、应用、缓存、数据库和消息队列，直接报出“加缓存、上 MQ、分库分表”很容易被继续追问。

这份 系统设计知识体系 面向后端学习、工程实践和面试复习，围绕“把业务需求拆成稳定、可维护、可扩展的工程方案”整理本站系统设计相关文章。

订单支付、售后审核、商品检测这类业务，都需要回答两个问题：当前处于什么状态，接下来允许做什么？当一个业务又包含多个任务、条件分支和异步等待时，还需要知道哪些任务已经完成，哪些任务可以继续执行。

状态机适合表达状态变化的规则，流程编排侧重组织任务及其依赖。 两者可以一起使用：流程引擎调度任务，任务内部用状态机约束“待执行、执行中、成功、失败”等状态的变化。

状态机解决什么问题？

一个常见的业务状态机包含以下元素：

元素	作用	售后申请示例
状态（State）	描述当前业务阶段	待审核、待退款、已退款、已驳回
事件（Event）	触发一次状态变化	审核通过、审核拒绝、退款成功
转移（Transition）	定义状态之间允许的路径	待审核收到审核通过事件后进入待退款
守卫条件（Guard）	判断当前是否允许转移	审核记录完整且退款金额合法
动作（Action）	转移过程中执行的操作	保存审核结果、创建退款任务