- Java78
- 计算机基础65
- 数据库45
- 分布式27
- 技术文章精选集26
- AI 应用开发23
- 系统设计18
- 高性能15
- AI 编程实战13
- 框架13
- AI11
- 开发工具11
- 走近作者10
- 知识星球10
- 高可用10
- 面试准备9
- 开源项目8
- 计算机书籍7
- 学习路线6
- 走近项目5
- AI 编程技巧5
- 代码质量4
- AI 编程1
- 程序人生1
- Java面试指北1
什么是网关?
API 网关(API Gateway)是位于客户端与后端服务之间的统一入口,所有客户端请求先经过网关,再由网关路由到具体的目标服务。
在这组分布式文章里,网关属于“流量入口”这一层。RPC 主要讲服务之间怎么互相调用,网关讲外部请求进入系统后怎么做路由、鉴权、限流、灰度和协议适配。如果你只想看 Spring Cloud Gateway 的路由、Predicate、Filter 和限流细节,可以继续读 Spring Cloud Gateway 面试题总结。
为什么要用配置中心?
微服务架构下,应用被拆分为大量独立部署的服务,每个服务都有自己的配置(服务地址、数据库参数、功能开关等)。配置项数量会随着服务数量、环境数量和集群数量一起增长。传统配置文件方式存在以下问题:
- 修改需重启:无论配置在代码库还是外部文件中,很多应用都需要重启进程才能让新配置生效。
- 与发版耦合:如果配置放在代码库中,配置变更往往要跟代码发版绑定,难以独立灰度和回滚。
- 安全性不足:敏感配置(数据库密码、API Key)直接写在代码库中容易泄露。
- 缺乏权限控制:无法对配置的查看、修改、发布等操作进行细粒度权限管控。
- 配置分散难管理:多环境(开发/测试/生产)、多集群的配置分散在各处,难以统一维护。
提示
看到百度 Geek 说的一篇结合具体场景聊分布式 ID 设计的文章,感觉挺不错的。于是,我将这篇文章的部分内容整理到了这里。原文传送门:分布式 ID 生成服务的技术原理和项目实战 。
网上绝大多数的分布式 ID 生成服务,一般着重于技术原理剖析,很少见到根据具体的业务场景去选型 ID 生成服务的文章。
分布式 ID 介绍
这篇文章主要讲“ID 生成方案怎么选”,例如 UUID、数据库号段、Redis、Snowflake、Leaf、Tinyid。看完方案对比后,如果你想继续了解订单号、优惠券码、TraceId、短网址这类业务 ID 怎么设计,可以读 分布式 ID 设计实战。
什么是 ID?
日常开发中,我们需要对系统中的各种数据使用 ID 唯一表示,比如用户 ID 唯一标识一个用户,商品 ID 唯一标识一件商品,订单 ID 唯一标识一笔订单。
通常情况下,我们一般会选择基于 Redis 或者 ZooKeeper 实现分布式锁,Redis 用的要更多一点,我这里也先以 Redis 为例介绍分布式锁的实现。
这篇文章默认你已经知道为什么需要分布式锁。如果你还没搞清楚锁粒度、owner token、锁超时和业务临界区,建议先看 分布式锁入门。如果你想把锁过期、旧客户端恢复、Fencing Token 放到更大的协调模型里理解,可以结合 分布式协调详解。
网上有很多分布式锁相关的文章,这里写了一个相对简洁易懂的版本。面向面试和日常工作场景,先把最常见的概念和边界讲清楚。
这篇文章我们先介绍一下分布式锁的基本概念。
为什么需要分布式锁?
在多线程环境中,如果多个线程同时访问并修改同一份共享资源(例如商品库存、外卖订单),且没有互斥、原子更新、乐观锁或唯一约束等保护,就可能出现数据不一致、重复处理、超卖等问题,影响程序的正确性和稳定性。
举个例子,假设现在有 100 个用户参与某个限时秒杀活动,每位用户限购 1 件商品,且商品的数量只有 3 个。如果不对共享资源进行互斥访问,就可能出现以下情况:
准备分布式系统面试,最容易踩的坑是把知识点背成一堆孤立概念:CAP 是一个点、RPC 是一个点、分布式锁是一个点、分布式事务又是一个点。
真正到面试里,面试官更关心的是:你能不能把这些技术放回真实系统里,讲清楚它们解决什么问题、带来什么代价、适合什么场景。
这篇文章是 JavaGuide 分布式系统内容的面试复习导航,不会重复搬运所有答案,而是帮你把分布式相关文章串起来,按面试准备顺序建立一条清晰路径。
分布式面试先抓主线
分布式系统面试通常围绕 4 条主线展开:
- 一致性与可用性的权衡:CAP、BASE、最终一致性、中心化与去中心化、共识算法。
- 跨节点通信与治理:RPC、注册发现、API 网关、配置中心。
- 分布式数据一致性问题:分布式 ID、分布式锁、分布式事务。
- 典型中间件与落地场景:ZooKeeper、Dubbo、Spring Cloud Gateway 等。
刚接触分布式系统时,很多人会先被一串名词砸中:CAP、BASE、Paxos、Raft、分布式锁、分布式事务。
这些概念都绕不开,但入门时直接钻进去,容易把分布式系统学成一堆互不相干的术语。更好的切入口是一个更土但更实用的问题:原来一台机器、一个进程、一个数据库就能完成的事情,为什么后来要拆到多台机器上?拆完以后,为什么一个超时、一次重试、一条消息重复投递,都会牵出这么多设计问题?
这篇文章先把“分布式系统是什么”讲清楚。Paxos、Raft、分布式事务不会展开推导,只把它们放回主线里,知道它们大概在解决哪类麻烦。
什么是分布式系统?
网上已经有很多关于分布式事务的文章了,为啥还要写一篇?
- 第一是我觉得大部分文章理解起来挺难的,不太适合一些经验不多的小伙伴。这篇文章我的目标就是让即使是没啥工作经验的小伙伴们都能真正看懂分布式事务。
- 第二是我觉得大部分文章介绍的不够详细,很多分布式事务相关的重要概念都没有提到。
开始聊分布式事务之前,我们先来回顾一下事务相关的概念。
版本说明:本文 Seata 相关内容基于 1.7+ / 2.x 文档,RocketMQ 事务消息基于 4.9+ / 5.x 文档。不同版本的默认参数、API 和部署方式可能存在差异,落地时要以项目实际版本文档为准。
