一致性、复制、分片、缓存、消息、流量治理、容错恢复与系统设计权衡 (2025-2026)
| 上层 | 依赖的下层 | 关系说明 |
|---|---|---|
| 共识与复制 | 节点与网络 | 副本协议再优雅，也绕不过网络分区、节点宕机、时钟偏差和消息乱序这些物理现实。 |
| 分片与路由 | 复制层 | 数据拆分后不仅要知道“放在哪里”，还要解决副本同步、主从切换和热点迁移。 |
| 缓存 / 消息 / 服务治理 | 数据组织 | 缓存命中、消息顺序、读写路径、降级策略都高度依赖底层数据分布和一致性模型。 |
| 业务一致性 | 服务治理层 | 幂等、补偿、重试、事务边界和状态机不是独立技巧，而是分布式复杂度的业务投影。 |
| 高可用 | 全栈能力 | 真正的高可用不是多部署几台机器，而是从副本、路由、容量、故障转移到恢复流程都设计清楚。 |
| 系统设计 | 权衡与约束 | 分布式系统没有免费午餐，吞吐、延迟、一致性、可用性、成本和认知负担永远在互相拉扯。 |
强一致、最终一致、会话一致、因果一致并不是谁先进谁落后，而是面向不同业务约束的工程选择。
副本的核心价值是容错、读扩展和就近访问，但副本一旦存在，就必须面对复制延迟、冲突、脑裂和切换代价。
Raft / Paxos 不是为了显得高深，而是为了在多节点失败场景中，对日志顺序和领导者选举形成可证明的约束。
如果业务并不需要跨地域强一致，就不要轻易为“理论完美”支付过高的性能和复杂度成本。
单机容量、吞吐和 IO 都有上限。数据规模一旦突破单点边界，分片就是必然，而不是可选优化。
范围分片: 易于顺序扫描但容易热点；哈希分片: 分布均匀但跨分片查询麻烦；目录路由: 灵活但路由表本身要治理。
难点不在“把数据拆开”，而在扩容迁移、跨分片事务、热点键、全局索引和故障切换期间如何保持服务稳定。
缓存主要解决热点读、低延迟和下游保护问题，但它同时引入回源风暴、双写不一致、过期策略和穿透雪崩等新风险。
消息队列适合削峰填谷、异步处理、事件广播和服务解耦，但也会把同步复杂度换成顺序、重复消费、积压和幂等等问题。
缓存和队列都不是“万能性能插件”，它们应该围绕关键业务路径设计，而不是哪里慢就先塞一个中间层。
超时、重试、限流、熔断、隔离、降级、负载均衡、服务发现，是分布式系统的日常安全带。
很多事故不是因为单个组件彻底坏掉，而是每一层都做了“合理”的重试，最后把下游打穿。
没有超时预算的重试通常比不重试更危险；没有隔离的共享线程池和连接池，会让局部故障迅速扩散为系统性故障。
只要系统存在重试、消息重复、客户端超时重发或人工补偿，幂等就不再是“高级技巧”，而是基本设计前提。
2PC、TCC、SAGA、Outbox 各有代价。很多业务场景更现实的做法，是把事务拆成状态机和补偿流程，而不是强行追求跨系统原子提交。
成熟系统设计的关键，不只是请求正常时怎么走，而是失败、重试、超时、回滚、人工介入时还能不能把状态收回来。
| 类别 | 主流项目 | 定位 | 适用场景 | 关键代价 |
|---|---|---|---|---|
| 协调 / 选主 | ZooKeeper / etcd / Consul | 服务发现、选主、配置协调 | 控制平面、注册发现、元数据管理 | 需要谨慎维护一致性核心节点 |
| 缓存 | Redis / KeyDB | 热点读、低延迟访问、计数与会话 | 高频读路径、限流、排行榜 | 一致性与内存成本 |
| 消息队列 | Kafka / RabbitMQ / RocketMQ / Pulsar | 异步解耦、事件流、缓冲 | 异步任务、事件驱动、日志流 | 顺序、重复、积压治理复杂 |
| 分布式数据库 | CockroachDB / TiDB / Cassandra / HBase | 多节点存储与复制 | 高可用数据层、弹性扩展 | 模型和运维复杂度显著上升 |
| 服务治理 | Envoy / Istio / Sentinel / Resilience4j | 流量控制、熔断、限流、观测 | 微服务治理与故障隔离 | 控制面和调试心智增加 |
| 工作流 / 编排 | Temporal / Cadence / Conductor | 长事务、状态机、补偿编排 | 复杂业务流程、异步事务 | 需要新的编排模型和治理方式 |
| 方案 | 优点 | 代价 | 适合谁 |
|---|---|---|---|
| 单体 + 本地事务 | 简单、稳定、认知负担低 | 扩展边界有限 | 早期产品、小中型业务 |
| 微服务 + 同步治理 | 职责拆分明确、团队边界清晰 | 调用链变长，故障治理要求高 | 中大型组织 |
| 事件驱动架构 | 扩展性强、解耦明显、实时处理友好 | 一致性与排障复杂度高 | 业务流程复杂、系统众多的团队 |
| 工作流编排平台 | 长事务和补偿更可视、更可控 | 需要额外平台和建模成本 | 订单、支付、履约、审批等链路型系统 |
| 业务类型 | 优先目标 | 更常见选择 | 备注 |
|---|---|---|---|
| 支付 / 账务 | 正确性 | 强一致 + 对账补偿 | 宁可慢一点，也不能账错 |
| 库存 / 订单 | 正确性 + 可恢复 | 强约束核心链路 + 最终一致外围链路 | 常需要预留冻结和补偿机制 |
| 内容分发 / Feed | 可用性 + 吞吐 | 最终一致 + 缓存扩展 | 旧一点的数据通常可接受 |
| 埋点 / 日志 / 事件流 | 吞吐 + 成本 | 异步日志流 | 重点在缓冲、丢失控制和可追踪性 |
调用成功率、尾延迟、重试次数、队列积压、缓存命中率、副本延迟、选主状态、错误码分布和限流触发次数，都应该有明确监控。
自动恢复负责处理常规波动，人工介入负责处理状态错乱和复杂补偿。成熟系统会提前定义两者边界，而不是靠临场发挥。
恢复能力不能只存在于“最懂这个系统的那个人”脑子里，必须沉淀成可复用流程、脚本和 Runbook。
| 类别 | 推荐工具 | 说明 |
|---|---|---|
| 缓存 | Redis / KeyDB | 热点缓存、限流、会话、计数器 |
| 消息队列 | Kafka / RabbitMQ / RocketMQ / Pulsar | 异步解耦、事件流、削峰 |
| 协调服务 | etcd / ZooKeeper / Consul | 配置、选主、服务发现、元数据管理 |
| 服务治理 | Envoy / Istio / Sentinel / Resilience4j | 流量控制、熔断、限流、容错策略 |
| 工作流编排 | Temporal / Cadence / Conductor | 长事务、状态机、补偿流程 |
| 压测与故障注入 | k6 / JMeter / Chaos Mesh / Toxiproxy | 容量验证、故障演练、网络异常模拟 |
| 观测 | Prometheus / Grafana / Tempo / Jaeger | 追踪调用链、观察重试、积压和尾延迟 |
事件驱动继续扩大: 业务系统会越来越多地把异步事件流作为常见集成方式，而不只是“补充链路”。
工作流编排平台化: 长事务、补偿和状态机编排会更多从业务代码中逐步抽离出来，交给更专门的平台能力。
托管分布式基础设施继续增强: 更多团队会使用云托管数据库、队列和协调服务，而不是全量自建。
跨地域一致性设计: 全球化业务和多活部署会继续推动延迟与一致性之间更细粒度的权衡。
AI 负载带来的新系统模式: 向量检索、推理路由、异步编排会把传统分布式问题带到新的业务形态中。
Serverless 与事件总线融合: 一部分系统会继续向更细粒度的事件处理模型迁移。
过早分布式: 业务还没复杂到那个阶段时，提前引入一整套复杂基础设施通常得不偿失。
恢复能力缺位: 很多系统能把流量打进去，却没有把错误状态收回来的能力。
观测不足: 没有链路和状态可见性，分布式系统出了问题很容易变成“全员猜谜”。