分布式核心知识

一、分布式基础概念

1. 什么是分布式

把一个单体系统拆分成多个独立服务,部署在不同服务器,通过网络协作完成业务,分担压力、提升并发与可用性。

2. 单体 vs 分布式

  • 单体:代码集中、部署简单,高并发/大流量易瓶颈,牵一发而动全身。
  • 分布式:服务解耦、可弹性扩容、团队并行开发,引入网络、数据一致性、调用复杂度等新问题。

3. 三大理论(面试必背)

CAP 定理

分布式系统无法同时满足 一致性©、可用性(A)、分区容错性§分区容错必选,只能在 C 和 A 之间取舍:

  • CP:保证一致性,牺牲可用性(如 ZooKeeper)
  • AP:保证可用性,牺牲强一致性(如 Eureka、大部分业务系统)
BASE 理论

对 CAP 的落地实践,互联网主流方案:

  • 基本可用:故障时保证核心功能可用,允许部分降级
  • 软状态:数据允许短暂不一致
  • 最终一致性:数据最终会达成一致,不要求实时一致
一致性算法
  • Paxos:经典强一致算法,实现复杂
  • Raft:简化版 Paxos,易实现,主流(Nacos、Etcd、RocketMQ 均使用)

二、分布式四大核心问题 & 解决方案

1. 分布式会话(Session 共享)

问题 :请求分发到不同服务/节点,原生 Session 不互通。

方案

  1. 统一会话存储:Redis 集中存放 Session
  2. 前端 Token:无状态登录,JWT 主流方案
  3. 粘性会话(不推荐,负载不均)

2. 分布式 ID

问题 :单机自增 ID 无法在多节点全局唯一。

常用方案

  1. UUID:简单,无序、过长、索引差
  2. 数据库自增:简单,单点瓶颈
  3. 雪花算法(SnowFlake):主流,64位二进制,有序、高性能
  4. Redis 自增:适合中小型系统
  5. 百度 UID、美团 Leaf:开源 ID 生成器

3. 分布式锁

问题:多服务/多节点竞争同一资源,保证互斥访问。

主流实现
  1. 基于 Redis
    • 核心:SET key value NX EX 过期时间
    • 问题:死锁、锁续期、锁误删、主从同步延迟
    • 成熟框架:Redisson(看门狗续期、可重入、公平锁)
  2. 基于 ZooKeeper
    • 临时有序节点 + 监听,性能略低于 Redis,一致性更强
  3. 基于数据库
    • 悲观锁/乐观锁,性能差,仅低并发场景使用

4. 分布式事务(最难考点)

问题:跨多个服务/库,保证事务要么全部成功、要么全部回滚。

四大经典方案
  1. 2PC(两阶段提交)
    准备阶段 → 提交/回滚;强一致,性能差,不适合高并发。
  2. TCC(补偿事务)
    Try(检查/预留) → Confirm(确认) → Cancel(回滚);代码侵入高,性能较好。
  3. 本地消息表(异步确保)
    本地事务 + 消息表 + 轮询补发;实现简单,业界常用。
  4. SAGA 模式
    长事务拆分,每个子事务配反向回滚操作。
主流框架

Seata:阿里开源,一站式分布式事务框架,支持 AT、TCC、SAGA 等模式,项目首选。


三、分布式核心组件(企业必用)

1. 注册中心(服务发现)

作用:服务注册、健康检测、地址拉取,解耦服务硬编码。

  • Nacos:国内主流,集注册中心+配置中心+动态DNS,兼容 AP/CP
  • Eureka:SpringCloud 原生,AP 架构,已停止更新
  • ZooKeeper:CP 架构,强一致,适合配置/选举,不建议纯服务注册

2. 配置中心

作用:统一管理配置、动态刷新,无需重启服务。

  • Nacos / Apollo / Spring Cloud Config

3. 网关 Gateway

作用:请求入口,统一路由、限流、熔断、鉴权、日志、灰度发布。

主流:Spring Cloud Gateway(替代旧版 Zuul)

4. 消息队列 MQ(异步解耦、削峰填谷)

核心场景:异步处理、流量削峰、服务解耦、数据同步。

主流中间件:

  • RocketMQ:阿里出品,功能全,事务消息优秀,国内电商首选
  • Kafka:高吞吐,大数据、日志收集首选
  • RabbitMQ:可靠性高,社区成熟

5. 熔断 & 限流 & 降级(高可用三板斧)

问题:服务雪崩(下游故障层层向上传导)。

  • 熔断:下游异常多,直接切断调用,避免雪崩(Sentinel、Resilience4j)
  • 限流:限制请求量,保护服务不被打垮(令牌桶、漏桶算法)
  • 降级:非核心功能暂时关闭,保证核心业务可用

主流组件:Sentinel(阿里,轻量、功能全,国内首选)、Hystrix(停更)

6. 远程调用(RPC)

作用:跨服务方法调用,像调用本地方法一样简单。

  • OpenFeign:SpringCloud 原生,HTTP 协议,易用
  • Dubbo:阿里开源,TCP 协议,高性能 RPC 框架,微服务经典
  • gRPC:谷歌,跨语言,适合跨语言调用

四、分布式高可用 & 高并发设计

  1. 集群部署:服务多节点,单点故障不影响整体
  2. 负载均衡
    • 客户端负载:Feign、Dubbo 内置(轮询、随机、加权轮询、一致性哈希)
    • 服务端负载:Nginx
  3. 缓存体系
    • 本地缓存:Caffeine、Guava
    • 分布式缓存:Redis(缓存穿透、击穿、雪崩三大问题及解决方案)
  4. 读写分离 & 分库分表
    • 读写分离:主库写、从库读,缓解单库压力
    • 分库分表:水平分表、垂直分表,解决单表数据量过大问题
    • 中间件:Sharding-JDBC、MyCat

五、高频面试题(精简答案)

  1. CAP 和 BASE 怎么理解?
    CAP 三选二,分区容错必然存在;BASE 是最终一致性,互联网分布式系统主流选型。
  2. Redis 分布式锁存在哪些问题?怎么解决?
    死锁(加过期时间)、锁误删(唯一标识)、续期(Redisson 看门狗)、主从延迟(Redlock)。
  3. 分布式事务有哪些方案?项目中用哪种?
    2PC、TCC、本地消息表、SAGA;项目常用 Seata AT 模式。
  4. 为什么要用消息队列?
    解耦、削峰、异步、流量控制。
  5. 服务雪崩怎么防护?
    熔断、限流、降级、超时控制、重试机制。
  6. Nacos 和 ZooKeeper 区别?
    Nacos 偏向 AP,可用性高,适合微服务注册;ZK 偏向 CP,一致性强,适合配置、选举。

六、学习路线(循序渐进)

  1. 理解 CAP/BASE 理论
  2. 分布式 ID、分布式锁
  3. 注册中心 + 配置中心(Nacos)
  4. RPC 远程调用(Dubbo/Feign)
  5. 网关 Gateway
  6. 熔断限流降级(Sentinel)
  7. 消息队列 MQ
  8. 分布式事务(Seata)
  9. 缓存、分库分表、读写分离
相关推荐
bukeyiwanshui1 小时前
20260528 Ceph 分布式存储 集群配置
分布式·ceph
我叫张小白。3 小时前
基于Redis与FastAPI的分布式共享会话体系
数据库·redis·分布式·缓存·中间件·fastapi·依赖注入
天河归来3 小时前
国产数据库安全可靠测评产品观察:从集中式、分布式到 HTAP 的发展趋势
数据库·分布式
小碗羊肉3 小时前
【Redis | 第五篇】分布式锁
数据库·redis·分布式
运维栈记3 小时前
Ceph 入门:一文读懂分布式存储的“瑞士军刀”
分布式·ceph
头歌实践平台3 小时前
HBase 完全分布式安装(新)
数据库·分布式·hbase
水木流年追梦3 小时前
大模型入门-大模型优化方法3
人工智能·分布式·python·深度学习·机器学习
是狐狸吖4 小时前
Redis分布式锁进阶第十六篇
数据库·redis·分布式
2603_954708314 小时前
微电网分布式电源接入技术的相关国家标准有哪些?
人工智能·分布式·物联网·架构·系统架构·能源