首先，需要了解系统为什么使用分布式。

随着互联网的发展，传统单工程项目的很多性能瓶颈越发凸显，性能瓶颈可以有几个方面：

  1. 应用服务层：随着用户量的增加，并发量增加，单项目难以承受如此大的并发请求导致的性能瓶颈。
  2. 底层数据库层：随着业务的发展，数据库压力越来越大，导致的性能瓶颈。

场景1：应用系统集群的 Session 共享

应用系统集群最简单的就是服务器集群，比如：Tomcat 集群。应用系统集群的时候，比较凸显的问题是 Session 共享，Session 共享我们一是可以通过服务器插件来解决。另外一种也可以通过 Redis 等中间件实现。

场景2：应用系统的服务化拆分

服务化拆分，是目前非常火热的一种方式。现在都在提微服务。通过对传统项目进行服务化拆分，达到服务独立解耦，单服务又可以横向扩容。服务化拆分遇到的经典问题就是分布式事务问题。目前，比较常用的分布式事务解决方案有几种：消息最终一致性、TCC 补偿型事务等。

场景3：底层数据库的压力分摊

如果系统的性能压力出现在数据库，那我们就可以读写分离、分库分表等方案进行解决。

三个场景对应”应用层、服务层、数据层”三层瓶颈，框架正确但每层都还有未展开的决策面：何时才值得分布式（触发阈值）、每层的完整方案谱系、以及分布式化引入的新成本。本文补全成”瓶颈 → 方案 → 代价”的决策手册。

前置问题：何时才值得分布式

分布式不是架构升级而是成本交换：用”网络不可靠、数据一致难、运维复杂”换”水平扩展能力”。触发信号：

  • 单机 QPS/CPU/内存达上限且垂直扩容（加机器配置）边际成本高于拆分
  • 数据量超单机存储/备份窗口不可接受
  • 团队规模需要独立交付节奏（组织瓶颈也是瓶颈）
  • 可用性要求超单机极限（多机房容灾）

无以上信号时，单体+缓存+读写分离能走很远——分布式是药不是饭。

应用层：从集群到无状态

  • 水平扩容前提是无状态化：Session 外置（Redis/Token，见 Session 篇）、本地缓存改集中缓存或一致性哈希本地缓存
  • 负载均衡：四层（LVS/IP哈希）/七层（Nginx/网关，按 URL/Header 路由）；会话保持 vs 无状态化的取舍
  • 静态资源分离：CDN 承接图片/JS/CSS，源站只留动态请求——最便宜的一次”分布式”

服务层：拆分的依据与事务代价

  • 拆分依据：业务边界（DDD 限界上下文）> 技术分层；先拆”变化频率不同”与”负载特征不同”的模块
  • 拆分收益：独立部署/独立扩容/故障隔离/技术异构
  • 拆分代价（原文点到事务，补全清单）：分布式事务（消息最终一致/TCC/Saga/Seata）、跨服务查询拼装、链路追踪、服务治理（注册/熔断/限流）、运维成本翻倍
  • 渐进路线：单体模块化 → 模块独立部署 → 真微服务；一步到位的拆分多半要合回来

数据层：方案谱系按代价排序

  1. 缓存（Redis）：挡读压力，成本最低，先做
  2. 读写分离：主写从读，读扩展线性；代价是主从延迟（读己之写需路由主库）
  3. 分库分表：写压力与容量的终极手段；代价是跨片查询/事务/全局 ID/扩容迁移（见分库分表两篇）
  4. 异构存储分流：搜索去 ES、分析去 OLAP（ClickHouse）、文件去对象存储——按访问模式把数据放到对的引擎，比万能分片更优雅
  5. 多机房/单元化：容灾与就近访问，成本最高，巨头选项

横切场景（原文三场景之外的常见分布式需求）

  • 分布式锁：跨实例互斥（库存扣减、调度单活）——Redis/ZK 方案与误删/续期问题
  • 分布式 ID：雪花/号段（见主键方案篇）
  • 分布式事务/最终一致：跨服务业务原子性
  • 分布式缓存一致性：binlog 订阅失效（Canal）
  • 分布式调度：单活任务（XXL-Job/Quartz 集群）
  • 分布式限流：集群级配额（Redis 令牌桶/Gateway 全局限流）

决策 checklist

  • 瓶颈定位有数据吗（监控/压测，而非感觉）？
  • 垂直扩容与缓存/读写分离是否已用尽？
  • 拆分边界画在哪、跨边界调用有几个、事务怎么保证？
  • 新增的运维能力（监控/追踪/发布）跟得上吗？
  • 回退方案有吗（拆分可逆性）？

分布式场景的回答结构 = 三层瓶颈（应用/服务/数据）× 方案谱系（按代价排序）× 触发阈值与代价清单；记住”分布式是成本交换”这一个判断框架，所有方案选型都有了统一的度量衡。