集群不是乱炖：一文看懂分布式系统的门道
一、什么是分布式系统？
分布式系统（Distributed System） 是指：
由多台通过网络连接的计算机节点组成，它们通过协同工作，共同完成同一个任务，对外表现为一个统一整体的系统。
在这样的系统中，每个节点（通常是一台服务器或容器实例）都承担部分功能，如计算、存储或服务请求处理。
这些节点之间通过网络通信、数据同步和任务协作，实现对外提供 高可用（High Availability）、高性能（High Performance）、可扩展（Scalable） 的整体能力。
🧩 换句话说
分布式系统的核心思想是：把一个大型任务拆分成多个子任务，由多台机器并行处理，再将结果合并为最终输出。
这样设计的好处是：
-
当单台机器性能不足时，可以通过“加机器”来提升整体性能（水平扩展）。
-
即使某些节点宕机，系统也能自动切换，继续对外服务（高可用）。
-
不同节点可承担不同功能（计算、存储、缓存等），形成灵活的系统架构。
💡 举个例子
当你在 淘宝 搜索“蓝牙耳机”时，实际上：
有的服务器负责接收搜索请求；
有的服务器负责检索商品信息；
有的服务器负责展示图片与价格；
还有的服务器在后台计算推荐结果。
虽然这些任务由成千上万台服务器协同完成，但对你而言，只是一次“搜索操作”。
这就是分布式系统的魅力——多个节点协同工作，对外如同一个统一的整体。
二、分布式系统的核心目标
在分布式架构中，系统的设计目标不仅仅是“能运行”，而是要在复杂网络环境与高并发场景下保持稳定、可靠、可扩展。
通常，一个完善的分布式系统应同时关注以下五个核心目标：
| 目标 | 含义 | 实现思路与典型技术 |
|---|---|---|
| 高可用性（High Availability, HA） | 即使部分节点或服务发生故障，系统仍能持续对外提供服务，不会整体崩溃。 | 多副本机制、主从切换、负载均衡（Nginx、K8s Service）、健康检查、自动故障转移（Failover） |
| 可扩展性（Scalability） | 系统能够通过增加节点或资源来提升整体处理能力，而不需大幅改动架构。 | 水平扩展（Scale-out）、分片（Sharding）、无状态服务设计、微服务架构、分布式缓存（Redis Cluster） |
| 一致性（Consistency） | 在多个节点同时处理数据的情况下，系统要确保数据的一致正确。 | CAP 理论、分布式事务（2PC、TCC、Saga）、共识算法（Raft、Paxos）、强/最终一致性模型 |
| 容错性（Fault Tolerance） | 系统具备自动检测与恢复故障的能力，个别组件异常不会导致整体失效。 | 副本冗余、心跳检测、熔断与降级（Hystrix/Sentinel）、Leader 选举（Zookeeper、Etcd） |
| 高性能（High Performance） | 能够高效地处理大量并发请求，并保证用户的快速响应体验。 | 缓存（Redis）、异步化（MQ、异步任务）、批处理、CDN 加速、负载均衡调度 |
各目标之间的关系
| 关系 | 说明 |
|---|---|
| 高可用性 ≈ 容错性 + 监控恢复能力 | 有容错机制还不够，系统必须具备自动恢复与流量转移能力。 |
| 一致性 vs 可用性 | 根据 CAP 理论，系统常需在一致性和可用性之间做权衡（例如 AP 型系统侧重可用性，CP 型系统侧重一致性）。 |
| 可扩展性支撑性能提升 | 可扩展的系统更容易提升性能与吞吐量，尤其在横向扩容时成本更低。 |
💡 举例理解
以电商系统为例，当用户下单时：
高可用性：订单服务一台机器宕机时，负载均衡自动转发到其他节点；
可扩展性：双十一高峰时，可快速扩容订单处理节点；
一致性：多个节点同时写入订单数据，必须保证库存与金额一致；
容错性：某个节点因网络波动超时，系统可自动剔除并重新加入；
高性能：通过 Redis 缓存商品详情，Kafka 异步下单，显著降低数据库压力。
三、分布式系统的整体架构模块
分布式系统可分为以下主要模块：
┌──────────────────────────────────────────┐
│ 应用层（微服务） │
│ ┌─────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 用户服务 │ │ 订单服务 │ │ 支付服务 │ │
│ └─────────┘ └──────────┘ └──────────┘ │
├──────────────────────────────────────────┤
│ 服务注册与治理层 │
│ (Eureka / Nacos / Consul) │
├──────────────────────────────────────────┤
│ 通信与网关层 │
│ (API Gateway / gRPC / MQ) │
├──────────────────────────────────────────┤
│ 数据与缓存层 │
│ (MySQL / Redis / MongoDB / Elasticsearch)│
├──────────────────────────────────────────┤
│ 消息与异步层 │
│ (Kafka / RabbitMQ / RocketMQ) │
├──────────────────────────────────────────┤
│ 分布式协调与一致性 │
│ (Zookeeper / Etcd / Raft / Paxos) │
├──────────────────────────────────────────┤
│ 存储与分布式文件系统 │
│ (HDFS / Ceph / MinIO / S3) │
├──────────────────────────────────────────┤
│ 监控与日志层 │
│ (Prometheus / ELK / SkyWalking / Grafana)│
├──────────────────────────────────────────┤
│ 运维与容器化层 │
│ (Docker / Kubernetes / Jenkins) │
└──────────────────────────────────────────┘
四、核心模块逐层详解（含技术原理 + 对比分析）
在分布式系统中，每个模块都承担着不同的职责：
有的负责服务发现与通信，有的负责数据一致性与存储，还有的保障监控与自动化运维。
它们共同协作，构成一个高可用、可扩展、可维护的系统整体。
4.1 服务注册与发现（Service Registry）
-
📘 作用
在传统单体架构中，服务地址是固定的（如
localhost:8080），但在分布式系统中：-
服务实例会频繁扩容 / 缩容；
-
IP 地址和端口动态变化；
-
服务节点可能随时宕机。
👉 因此我们需要一个注册中心来动态管理这些服务的地址与状态。
它的核心职责：
-
服务注册（Register）：服务启动后向注册中心汇报自身信息；
-
服务发现（Discovery）：消费者通过注册中心找到可用实例；
-
健康检查（Health Check）：宕机实例会被自动摘除；
-
负载均衡（Load Balance）：多个实例间自动分配流量。
-
-
📦 常见实现
技术 特点 一致性算法 Eureka Netflix 开源，去中心化设计，AP 优先 心跳机制 Nacos 支持配置中心 + 注册中心，CP/AP 可切换 Distro 协议 Consul 基于 Raft，强一致性（CP 模型） Raft 算法 -
⚙️ 原理概述
服务实例 → 注册中心 → 消费者 ↑ ↓ ← 定期心跳与状态同步 →注册中心作为“系统路由表”，让每个服务都能动态定位目标地址。
-
🧠 技术对比
对比点 Eureka Nacos Consul 模型 AP CP/AP 可切换 CP 特性 高可用、无 Leader 支持配置、命名空间 一致性强、性能略慢 场景 Spring Cloud 企业级微服务平台 K8s、Service Mesh 💡 推荐实践：
若你使用 Spring Cloud Alibaba 技术栈，Nacos 是首选；若你偏好云原生或多语言环境，Consul 更通用。
4.2 通信与网关层（Gateway & RPC Layer）
-
📘 作用
所有外部请求都需要统一的入口来：
-
路由转发到目标服务；
-
进行身份认证、权限控制；
-
实现限流、熔断、灰度发布等策略。
此外，内部服务之间还需要高性能通信机制（如 RPC）。
-
-
📦 常见技术
技术 类型 特点 Nginx / Kong 反向代理 / API Gateway 高性能、插件丰富 Spring Cloud Gateway Java 网关，Spring 集成度高 支持动态路由与过滤器 gRPC / Dubbo 高性能 RPC 框架 二进制传输、强类型通信 -
⚙️ 流程示意
客户端请求 → API Gateway → 鉴权/限流 → 业务服务内部服务调用：
Service A → gRPC / Dubbo → Service B -
🧠 对比总结
通信方式 特点 适用场景 REST 简单、通用、HTTP 基础 对外开放接口 gRPC 二进制高效、支持流式传输 内部微服务通信 MQ 异步解耦 异步任务处理 💡 推荐组合：
对外使用 API Gateway + REST，
对内使用 gRPC 或 Dubbo 实现高性能通信。
4.3 消息与异步通信层（Messaging & Async Layer）
-
📘 作用
在高并发系统中，异步消息机制能有效解决：
-
服务解耦（生产者/消费者独立）；
-
削峰填谷（缓冲突发流量）；
-
提升性能（异步处理任务）。
-
-
📦 常见技术
技术 模型 优势 缺点 Kafka 发布/订阅 吞吐量高、顺序性好 延迟略高、复杂度高 RabbitMQ 队列模型 路由灵活、可靠性强 吞吐量一般 RocketMQ 混合模型 支持事务消息、性能佳 部署稍复杂 Redis Stream 轻量队列 简单快速 功能有限 -
⚙️ Kafka 消息流转示意
Producer → Broker（写入日志） → ISR 同步 → ConsumerGroup 消费Kafka 的设计基于日志分区模型：每个主题分成多个分区（Partition），每个分区按顺序追加消息。
-
🧠 技术选型建议
场景 推荐技术 大数据流式处理 Kafka 电商下单、异步通知 RabbitMQ 分布式事务消息 RocketMQ 简单异步队列 Redis Stream
4.4 分布式存储与数据库层
-
📘 数据类型与典型技术
类型 示例 特点 关系型数据库 MySQL、PostgreSQL 支持事务、一致性高 文档数据库 MongoDB JSON 存储，灵活扩展 缓存型数据库 Redis、Memcached 高速读写、内存存储 搜索引擎 Elasticsearch 全文检索、聚合分析 分布式文件系统 HDFS、Ceph、MinIO 海量存储、容灾能力强 -
⚙️ 分片与副本机制
-
分片（Sharding）：按规则将数据分布在不同节点（如
user_id % 4）； -
副本（Replica）：同一份数据保留多个副本，用于容灾与高可用。
💡 实践案例
用户数据按 ID 分片存入 4 个库，每个库包含 1 主 2 从；
主节点写入，从节点分担读取压力。
-
4.5 分布式一致性与协调层（Coordination & Consensus）
-
📘 作用
在多节点环境下，需要保证：
-
主节点选举；
-
配置同步；
-
元数据一致。
-
-
📦 技术对比
技术 算法 特点 Zookeeper ZAB 稳定、常用于协调与选举 Etcd Raft 性能高、云原生友好 Raft 协议 简化 Paxos，更易理解与实现 💡 示例
-
Kafka 使用 Zookeeper 管理 Broker 与 Controller；
-
Kubernetes 使用 Etcd 存储集群状态；
-
Redis Sentinel 通过选举机制自动主从切换。
-
4.6 缓存系统（Caching Layer）
-
📘 缓存层次
-
本地缓存：位于 JVM 内存（Caffeine、Guava），速度快但不可共享；
-
分布式缓存：Redis / Memcached，用于集群共享数据。
-
-
⚙️ Redis 核心机制
模块 说明 Redis Cluster 分片 + 主从复制 + 故障自动转移 Sentinel 主从监控与切换 Pipeline / Lua 批量与原子操作支持 -
💡 缓存三大问题与应对
问题 含义 解决方案 穿透 查询不存在的 key 布隆过滤器拦截 击穿 热点 key 过期瞬间被高并发访问 加互斥锁 / 逻辑过期 雪崩 大量缓存同时过期 随机过期时间、分批更新
4.7 分布式事务（Distributed Transaction）
-
📘 核心目标
在多个服务 / 数据库参与的场景中，保证数据操作的最终一致性。
-
📦 常见模型
模型 特点 场景 2PC（两阶段提交） 强一致性，性能低 核心金融系统 TCC 业务层补偿机制 高并发系统 本地消息表 基于消息最终一致 电商异步处理 Saga 长事务补偿机制 分布式长流程 💡 示例
下单 → 扣库存 → 扣余额
若扣余额失败 → 通过 Saga 回滚库存，保证一致性。
4.8 监控与日志系统（Observability Layer）
-
📘 技术栈组成
模块 技术 作用 日志采集 Filebeat / Logstash 收集日志文件 日志存储 Elasticsearch 检索与聚合 指标监控 Prometheus 系统指标采集 告警展示 Grafana / Alertmanager 图形化与告警通知 链路追踪 SkyWalking / Jaeger 分布式调用链分析 💡 示例
Gateway → OrderService → InventoryService → DatabaseSkyWalking 可精确展示整条调用链耗时与异常点，快速定位性能瓶颈。
4.9 运维与容器化层（DevOps & Containerization）
-
📘 核心目标
让分布式系统“可部署、可扩缩、可回滚”。
-
📦 技术生态
层级 技术 功能 容器化 Docker 封装运行环境 调度与编排 Kubernetes 自动部署、扩缩容、健康检查 持续集成 Jenkins / GitLab CI 自动构建与发布 服务网格 Istio 流量治理、熔断、可观测性 -
⚙️ DevOps 流程
开发提交代码 → Jenkins 构建镜像 → 推送 Harbor → K8s 部署 → Prometheus 监控💡 这让系统可以在分钟级完成更新与回滚，实现持续交付（CD）。
五、整体运行流程（以电商系统为例）
当用户在电商平台发起「下单」请求时，背后其实会触发一条完整的分布式系统调用链，涉及网关、注册中心、服务调用、消息系统、缓存、数据库、日志与监控等多个子系统的协同。
5.1 全链路示意图
┌──────────┐
│用户前端 │
└─────┬────┘
│HTTP 请求 (下单)
▼
┌──────────────┐
│ API Gateway │ ← 统一接入层（鉴权、限流、灰度）
└─────┬────────┘
│查询服务地址
▼
┌──────────────┐
│Nacos 注册中心 │ ← 维护服务实例列表
└─────┬────────┘
│返回订单服务节点地址
▼
┌──────────────┐
│ OrderService │ ← 下单逻辑
└─────┬────────┘
│调用库存服务（gRPC）
▼
┌──────────────┐
│ InventorySvc │ ← 扣减库存
└─────┬────────┘
│异步消息通知
▼
┌───────────────────────────┐
│ Kafka Topic: order_events │ ← 异步解耦，削峰填谷
└─────┬─────────────────────┘
│消息消费
▼
┌──────────────┐
│ PaymentSvc │ ← 扣款、回调订单状态
└─────┬────────┘
│状态回写
▼
┌─────────────────────┐
│ Redis Cache + MySQL │ ← 更新订单缓存 & 持久化存储
└─────┬───────────────┘
│日志、监控收集
▼
┌───────────────────────────────┐
│ ELK + Prometheus + SkyWalking │
└───────────────────────────────┘
5.2 各模块详细说明
5.2.1 API Gateway（统一入口层）
-
功能：
-
用户请求的统一入口；
-
鉴权（JWT/Token 验证）；
-
限流（令牌桶算法）；
-
灰度发布（部分流量进入新版本）。
-
优化点：
使用 Nginx + Spring Cloud Gateway； * 对静态内容启用 CDN 缓存； *
对动态请求增加熔断与重试机制。
5.2.2 服务注册与发现（Nacos）
-
OrderService、InventoryService、PaymentService 启动后自动注册到 Nacos。
-
Gateway 或其他微服务调用前，通过 Nacos 获取最新可用节点地址。
-
支持：
-
健康检查（自动剔除下线节点）
-
负载均衡（Ribbon、LoadBalancer）
-
好处：不再依赖硬编码 IP，支持自动伸缩与容灾。
5.2.3 微服务通信（gRPC）
-
OrderService → InventoryService：使用 gRPC。
-
原因：
-
二进制传输（Protocol Buffers）性能高；
-
多语言支持；
-
天然支持流式数据传输。
-
优化点：
对库存操作采用幂等性设计（防止重试扣重），并使用 Redis 锁防止超卖。
5.2.4 消息异步解耦（Kafka）
-
当订单创建成功后，OrderService 发送一条消息到
order_events主题。 -
PaymentService 异步订阅该主题，执行支付逻辑。
-
好处：
-
解耦（订单系统与支付系统独立运行）
-
削峰（高峰期缓冲请求）
-
异步（下单响应更快）
-
补充机制：
- 使用 Kafka ACK + 重试机制 确保消息不丢；
- 使用 死信队列（DLQ） 处理异常消息。
5.2.5 数据层：Redis + MySQL
-
Redis： 缓存热点数据（订单详情、库存数）
-
使用分布式锁 + TTL 防击穿；
-
开启主从 + 哨兵机制提高可用性。
-
-
MySQL： 持久化核心业务数据
-
主从复制，分库分表（按用户ID取模）；
-
Binlog 用于同步增量数据（可投递至 Kafka）。
-
写入流程示例：
PaymentService 回调：
- 更新 MySQL (订单状态)
- 删除 Redis 缓存（保证一致性）
- 异步写操作日志
5.2.6 日志与监控系统（ELK + Prometheus + SkyWalking）
| 模块 | 功能 |
|---|---|
| Filebeat / Logstash | 收集应用日志 |
| Elasticsearch (ELK) | 查询与聚合日志数据 |
| Prometheus | 采集系统指标（CPU、延迟、QPS） |
| Grafana | 可视化大屏与报警 |
| SkyWalking / Jaeger | 调用链追踪（可定位慢服务与异常节点） |
💡 当某笔订单处理缓慢时，SkyWalking 能精确标出“是 Kafka 消费慢还是数据库写入延迟”。
5.3 整体流程串联
① 用户提交订单请求
② API Gateway 校验身份 + 路由到 OrderService
③ OrderService 查询 Nacos 获取 InventoryService 地址
④ gRPC 调用扣减库存
⑤ Kafka 异步投递 “待支付” 事件
⑥ PaymentService 消费消息 → 扣款成功 → 回调订单状态
⑦ Redis 缓存更新 + MySQL 落地
⑧ ELK 记录日志，Prometheus 采集指标
⑨ SkyWalking 生成完整链路追踪数据
5.4 性能与容错设计要点
| 目标 | 设计方案 |
|---|---|
| 高可用（HA） | 各服务多实例部署，Nacos + Gateway 健康检查自动切换 |
| 高性能 | Redis 缓存 + Kafka 异步 + gRPC 二进制传输 |
| 一致性 | TCC / 本地消息表 + Redis 延迟双删 |
| 容错性 | 熔断、限流、重试、DLQ、分布式锁 |
| 可观测性 | 全链路日志 + 指标监控 + 调用追踪 |
通过这一整条「下单 → 支付 → 状态更新」链路，我们可以看到分布式系统如何协同工作：
- Nacos 保证服务可发现
- Kafka 保证服务解耦与异步处理
- Redis 提供高速缓存层
- MySQL 提供强一致性持久层
- SkyWalking + Prometheus 提供可观测性
- Gateway 保证系统入口安全与流控
最终达成的目标是：
「高可用 + 高性能 + 一致性 + 可观测 + 可扩展」的分布式电商系统。
六、不同技术选型全景对比与推荐
| 模块 | 方案 | 核心特性 | 优点 | 缺点 | 适用场景 | ✅ 推荐 |
|---|---|---|---|---|---|---|
| 注册中心 | Eureka | AP 模型、无中心架构 | 高可用、Spring 集成好 | 不维护一致性，易出现脏数据 | 小型 Spring Cloud 系统 | |
| Consul | 基于 Raft 的强一致 | 一致性强、支持健康检查 | 性能稍低、配置偏复杂 | 多语言微服务、强一致需求场景 | ||
| Nacos | 支持注册 + 配置管理、CP/AP 可切换 | 功能最全、动态扩展方便 | 依赖 JVM、内存占用高 | 云原生架构、微服务平台 | ⭐ Nacos | |
| 网关层 | Nginx | C 实现反向代理 | 高性能、成熟稳定 | 无微服务感知 | 静态资源、统一入口 | |
| Zuul | Java 网关，基于 Servlet | Spring 集成好 | 性能较低（阻塞IO） | 传统 Spring Cloud 系统 | ||
| Spring Cloud Gateway | 基于 Reactor 异步IO | 插件化、性能优、支持限流鉴权 | JVM 内存开销较大 | 云原生微服务 | ⭐ SCG | |
| 消息队列 | RabbitMQ | 队列模型，AMQP 协议 | 稳定、支持路由/确认机制 | 吞吐较低、集群复杂 | 企业系统、交易类场景 | |
| Kafka | 发布订阅、基于日志 | 吞吐高、可扩展、顺序性好 | 实时性略差、语义复杂 | 日志流、监控流、埋点系统 | ⭐ Kafka | |
| RocketMQ | 混合模型，支持事务消息 | 吞吐高、可靠、支持分布式事务 | 部署略复杂 | 金融/交易系统 | ||
| 缓存系统 | Redis | 单线程 IO 多路复用 | 高速、功能丰富（Lua、Stream） | 单机内存受限 | 热点缓存、分布式锁 | ⭐ Redis |
| Memcached | 简单 KV 缓存 | 性能稳定 | 不支持持久化 | 临时缓存 | ||
| Hazelcast | JVM 内嵌分布式缓存 | 分布式共享内存 | 对 Java 依赖强 | 特定企业内网场景 | ||
| 一致性与协调 | Zookeeper | Zab 协议 | 稳定成熟、生态广泛 | 配置复杂、性能偏低 | Kafka、Hadoop 集群协调 | |
| Etcd | Raft 协议 | 性能优、K8s 核心依赖 | 功能简单 | K8s、服务注册配置 | ⭐ Etcd | |
| Raft | 共识算法 | 理论完善、实现简单 | 需自行封装 | 学术研究、自研组件 | ||
| 日志系统 | ELK | Elasticsearch + Logstash + Kibana | 功能强大、可搜索分析 | 资源占用高 | 大型日志分析系统 | ⭐ ELK |
| Loki | 轻量日志聚合，兼容 Prometheus | 成本低 | 查询能力较弱 | 容器环境、轻量场景 | ||
| Fluentd | 统一日志收集框架 | 插件丰富 | 配置复杂 | 多格式日志输入 | ||
| 调度与编排 | Kubernetes | 云原生标准，声明式编排 | 自动扩缩容、健康检查、生态完善 | 学习曲线高 | 云原生部署、微服务平台 | ⭐ Kubernetes |
| Docker Swarm | 原生 Docker 编排 | 简单轻量 | 功能有限 | 小规模部署 | ||
| Apache Mesos | 通用资源调度器 | 高扩展性 | 生态已退潮 | 大数据、混合负载 |
🔍 补充分析：整体技术选型思路
| 架构层级 | 推荐技术 | 选型理由 |
|---|---|---|
| 服务发现层 | Nacos | 集成注册 + 配置中心，支持多模式（CP/AP） |
| 网关层 | Spring Cloud Gateway | 原生支持微服务安全、限流、路由、灰度 |
| 消息层 | Kafka | 适合高并发、高吞吐场景 |
| 数据缓存层 | Redis Cluster | 支持分片 + 主从 + 哨兵 |
| 协调层 | Etcd / Zookeeper | 确保集群一致性与选举安全 |
| 日志监控层 | ELK + Prometheus + Grafana | 全链路日志与可视化监控体系 |
| 调度层 | Kubernetes | 自动部署、弹性伸缩、云原生生态核心 |
七、总结与思维导图
7.1 总结回顾
分布式系统的本质，是用多台计算机协同解决单机无法承载的复杂任务。
它的目标是实现 高可用、高性能、可扩展、一致性与容错性，并通过一整套组件协同实现：
-
服务治理层：管理服务的注册、发现、健康检测（如 Nacos、Consul）
-
通信层：统一流量入口与安全控制（如 Gateway、gRPC）
-
消息异步层：实现系统间解耦与削峰填谷（如 Kafka、RabbitMQ）
-
数据与缓存层：存储业务数据、提升访问性能（如 MySQL、Redis）
-
一致性协调层：维持分布式状态一致与主从选举（如 Etcd、Zookeeper）
-
文件存储层：负责大文件与对象数据管理（如 HDFS、MinIO）
-
监控与日志层：提供全链路观测与告警（如 ELK、Prometheus、SkyWalking）
-
容器与调度层：支撑自动部署与弹性伸缩（如 Docker、Kubernetes）
-
事务与一致性层：确保跨服务调用的可靠性（如 TCC、Saga、2PC）
7.2 分布式系统核心思维导图
分布式系统（Distributed System）
├─ 🌐 服务治理（Service Registry）
│ ├─ Nacos —— 注册 + 配置中心，支持 CP/AP
│ └─ Consul —— 基于 Raft，强一致
│
├─ 🚪 网关通信（Gateway & RPC）
│ ├─ Spring Cloud Gateway —— 路由、限流、鉴权
│ └─ gRPC —— 高性能二进制通信框架
│
├─ 📬 消息队列（Message Queue）
│ ├─ Kafka —— 高吞吐日志流系统
│ ├─ RabbitMQ —— 可靠 AMQP 队列
│ └─ RocketMQ —— 支持事务消息
│
├─ 💾 数据与缓存（Data & Cache）
│ ├─ MySQL —— 关系型数据库，事务强
│ ├─ Redis —— 分布式缓存，支持 Lua、Stream
│ └─ Elasticsearch —— 搜索与聚合
│
├─ 🔗 一致性与协调（Consistency & Coordination）
│ ├─ Zookeeper —— Zab 协议，主从选举
│ └─ Etcd —— Raft 协议，K8s 内核存储
│
├─ 🗂 文件存储（Distributed Storage）
│ ├─ HDFS —— 大数据文件系统
│ ├─ MinIO —— S3 兼容对象存储
│ └─ Ceph —— 块存储 + 对象存储
│
├─ 📈 监控与日志（Monitoring & Logging）
│ ├─ ELK —— 日志采集与分析
│ ├─ Prometheus —— 指标监控与告警
│ └─ SkyWalking —— 分布式调用链追踪
│
├─ 🐳 容器与调度（Container & Orchestration）
│ ├─ Docker —— 环境封装与镜像化
│ └─ Kubernetes —— 自动部署、伸缩与调度
│
└─ 🔄 分布式事务（Distributed Transaction）
├─ 2PC —— 两阶段提交，强一致但性能差
├─ TCC —— Try/Confirm/Cancel，灵活可补偿
└─ Saga —— 长事务模型，支持异步补偿
💡 一句话总结
分布式系统就像一支庞大的“交响乐团”：
各个模块（服务、消息、缓存、数据库、监控…）各司其职，
而注册中心与协调机制则是“指挥”，
让整个系统在复杂环境下依然能稳定、有序地运行。
扫一扫
270
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
