- Java80
- 计算机基础67
- 数据库46
- 分布式28
- 技术文章精选集26
- AI 应用开发24
- 系统设计19
- AI 编程实战16
- AI15
- 高性能15
- 框架14
- 开发工具11
- 走近作者10
- 知识星球10
- 面试准备10
- 高可用9
- 开源项目8
- 计算机书籍7
- 学习路线6
- 走近项目5
- AI 编程原理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 放到更大的协调模型里理解,可以结合 分布式协调详解。
这篇文章从同一个服务部署多个实例的场景出发,介绍本地锁的作用范围、分布式锁解决的问题,以及使用时需要注意的边界。
为什么需要分布式锁?
当多个进程需要互斥地操作同一份外部共享资源时,本地锁无法协调这些进程,分布式锁可以提供跨进程的互斥能力。
这里的“共享资源”可以是数据库中同一件商品的库存记录、Redis 中同一个缓存条目等。不同 JVM 通常不共享 Java 堆内存,但可以通过网络访问同一份外部数据。 需要协调的是这些进程对外部数据的操作。
本地锁为什么管不住多个服务实例?
分布式系统面试很少让你单独背一个 CAP 定义。面试官通常会从某个业务问题开始追问:服务为什么要拆到多个节点?网络超时后能不能重试?锁提前过期怎么办?跨服务的数据如何保持一致?
这篇文章是 JavaGuide 分布式系统专题的复习入口,按分布式理论、RPC 与网关、分布式 ID/锁/事务、配置中心与 ZooKeeper 四部分整理。每部分只列复习时需要抓住的问题,答案和实现细节放在对应专题文章中。
时间比较紧的话,可以先看 分布式系统常见面试题总结,把不会的问题标出来,再回到本文补原理和工程细节。
刚接触分布式系统时,很多人会先被一串名词砸中:CAP、BASE、Paxos、Raft、分布式锁、分布式事务。
这些概念都绕不开,但入门时直接钻进去,容易把分布式系统学成一堆互不相干的术语。更好的切入口是一个更土但更实用的问题:原来一台机器、一个进程、一个数据库就能完成的事情,为什么后来要拆到多台机器上?拆完以后,为什么一个超时、一次重试、一条消息重复投递,都会牵出这么多设计问题?
这篇文章先把“分布式系统是什么”讲清楚。Paxos、Raft、分布式事务不会展开推导,只把它们放回主线里,知道它们大概在解决哪类麻烦。
什么是分布式系统?
网上已经有很多关于分布式事务的文章了,为啥还要写一篇?
- 第一是我觉得大部分文章理解起来挺难的,不太适合一些经验不多的小伙伴。这篇文章我的目标就是让即使是没啥工作经验的小伙伴们都能真正看懂分布式事务。
- 第二是我觉得大部分文章介绍的不够详细,很多分布式事务相关的重要概念都没有提到。
开始聊分布式事务之前,我们先来回顾一下事务相关的概念。
版本说明:本文 Seata 相关内容基于 1.7+ / 2.x 文档,RocketMQ 事务消息基于 4.9+ / 5.x 文档。不同版本的默认参数、API 和部署方式可能存在差异,落地时要以项目实际版本文档为准。
