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

什么是网关？

API 网关（API Gateway）是位于客户端与后端服务之间的统一入口，所有客户端请求先经过网关，再由网关路由到具体的目标服务。

核心价值

在微服务架构下，一个系统被拆分为多个服务。像安全认证、流量控制、日志、监控等功能是每个服务都需要的。如果没有网关，我们需要在每个服务中单独实现这些功能，导致：

• 代码重复：相同逻辑在多个服务中冗余实现
• 管理分散：缺乏统一的配置和监控视图
• 维护成本高：功能变更需要修改所有服务

为什么要用配置中心？

微服务架构下，应用被拆分为大量独立部署的服务，每个服务都有自己的配置（服务地址、数据库参数、功能开关等）。配置项数量会随着服务数量、环境数量和集群数量一起增长。传统配置文件方式存在以下问题：

• 修改需重启：无论配置在代码库还是外部文件中，很多应用都需要重启进程才能让新配置生效。
• 与发版耦合：如果配置放在代码库中，配置变更往往要跟代码发版绑定，难以独立灰度和回滚。
• 安全性不足：敏感配置（数据库密码、API Key）直接写在代码库中容易泄露。
• 缺乏权限控制：无法对配置的查看、修改、发布等操作进行细粒度权限管控。
• 配置分散难管理：多环境（开发/测试/生产）、多集群的配置分散在各处，难以统一维护。

网上绝大多数的分布式 ID 生成服务，一般着重于技术原理剖析，很少见到根据具体的业务场景去选型 ID 生成服务的文章。

分布式 ID 介绍

什么是 ID？

日常开发中，我们需要对系统中的各种数据使用 ID 唯一表示，比如用户 ID 唯一标识一个用户，商品 ID 唯一标识一件商品，订单 ID 唯一标识一笔订单。

我们现实生活中也有各种 ID，比如身份证 ID 唯一标识一个人，地址 ID 唯一标识一个地址。

简单来说，ID 就是数据的唯一标识。

什么是分布式 ID？

这里说的分布式 ID，主要指分布式系统中用于跨节点、跨库、跨服务唯一标识数据的 ID。它解决的是多节点并发生成 ID 时不能冲突的问题。

通常情况下，我们一般会选择基于 Redis 或者 ZooKeeper 实现分布式锁，Redis 用的要更多一点，我这里也先以 Redis 为例介绍分布式锁的实现。

基于 Redis 实现分布式锁

如何基于 Redis 实现一个最简易的分布式锁？

不论是本地锁还是分布式锁，核心都在于“互斥”。

在 Redis 中，SETNX 命令可以帮助我们实现互斥。SETNX 即 SET if Not eXists（对应 Java 中的 setIfAbsent 方法），如果 key 不存在的话，才会设置 key 的值。如果 key 已经存在，SETNX 啥也不做。

网上有很多分布式锁相关的文章，这里写了一个相对简洁易懂的版本。面向面试和日常工作场景，先把最常见的概念和边界讲清楚。

这篇文章我们先介绍一下分布式锁的基本概念。

为什么需要分布式锁？

在多线程环境中，如果多个线程同时访问并修改同一份共享资源（例如商品库存、外卖订单），且没有互斥、原子更新、乐观锁或唯一约束等保护，就可能出现数据不一致、重复处理、超卖等问题，影响程序的正确性和稳定性。

举个例子，假设现在有 100 个用户参与某个限时秒杀活动，每位用户限购 1 件商品，且商品的数量只有 3 个。如果不对共享资源进行互斥访问，就可能出现以下情况：

准备分布式系统面试，最容易踩的坑是把知识点背成一堆孤立概念：CAP 是一个点、RPC 是一个点、分布式锁是一个点、分布式事务又是一个点。

真正到面试里，面试官更关心的是：你能不能把这些技术放回真实系统里，讲清楚它们解决什么问题、带来什么代价、适合什么场景。

这篇文章是 JavaGuide 分布式系统内容的面试复习导航，不会重复搬运所有答案，而是帮你把分布式相关文章串起来，按面试准备顺序建立一条清晰路径。

分布式面试先抓主线

分布式系统面试通常围绕 4 条主线展开：

1. 一致性与可用性的权衡：CAP、BASE、最终一致性、共识算法。
2. 跨节点通信与治理：RPC、注册发现、API 网关、配置中心。
3. 分布式数据一致性问题：分布式 ID、分布式锁、分布式事务。
4. 典型中间件与落地场景：ZooKeeper、Dubbo、Spring Cloud Gateway 等。

网上已经有很多关于分布式事务的文章了，为啥还要写一篇？

1. 第一是我觉得大部分文章理解起来挺难的，不太适合一些经验不多的小伙伴。这篇文章我的目标就是让即使是没啥工作经验的小伙伴们都能真正看懂分布式事务。
2. 第二是我觉得大部分文章介绍的不够详细，很多分布式事务相关的重要概念都没有提到。

开始聊分布式事务之前，我们先来回顾一下事务相关的概念。

版本说明：本文 Seata 相关内容基于 1.7+ / 2.x 文档，RocketMQ 事务消息基于 4.9+ / 5.x 文档。不同版本的默认参数、API 和部署方式可能存在差异，落地时要以项目实际版本文档为准。

本文重构完善自6000 字 | 16 图 | 深入理解 Spring Cloud Gateway 的原理 - 悟空聊架构这篇文章。

什么是 Spring Cloud Gateway？

Spring Cloud Gateway 属于 Spring Cloud 生态系统中的网关，其诞生的目标主要是为了替代 Zuul 1.x。Zuul 1.x 基于 Servlet 阻塞 I/O 架构，在高并发场景下性能有限。而 Zuul 2.x 虽然采用了 Netty 非阻塞架构，但 Spring Cloud 官方并未正式集成 Zuul 2.x。Spring Cloud Gateway 起步要比 Zuul 2.x 更早。