高并发系统设计-隔离

一、概述

1.1 什么是隔离

隔离（Bulkhead）源自船舶结构设计：

船体被分割成多个“水密舱”，即使某一舱进水，也不会导致整船沉没。

在分布式系统中对应为：

将不同业务流量或依赖资源隔离开，避免相互影响。

例如：

订单服务
支付服务
库存服务
推荐服务

如果没有隔离：

推荐服务慢查询
→ 占满线程池
→ 订单无法处理
→ 系统崩溃

1.2 为什么需要隔离

在高并发系统中，最危险的不是“单点失败”，而是：

资源被某一个模块耗尽

典型问题：

1. 线程池被占满

慢接口占用所有 worker → 新请求无法处理

2. 连接池被耗尽

某服务频繁调用DB → 连接池100个全部占满

3.某服务拖垮整个系统

推荐服务异常 → 影响订单服务 → 影响支付服务 → 全系统不可用

1.3 隔离的核心目标

隔离的本质是：

限制资源共享范围，防止“一个坏点影响全局”

目标：

• 防止资源争抢
• 防止链式崩溃
• 提高系统稳定性
• 控制故障范围

1.4 典型场景

场景1：电商系统

订单 / 支付 / 推荐 / 搜索

要求：

• 推荐挂了不能影响下单
• 搜索挂了不能影响支付

场景2：微服务调用

Service A → B → C → D

如果 D 崩溃：

• 不能拖死 A

场景3：第三方依赖

短信 / 邮件 / 地图 API

必须隔离：

• 外部服务不可靠

二、原理

2.1 隔离的核心思想

隔离本质是：

资源分配独立化 + 运行环境分离化

2.2 隔离的三种层次

1.线程/协程隔离

订单请求 → 线程池A

推荐请求 → 线程池B

支付请求 → 线程池C

2.连接池隔离

MySQL Pool A → 订单

MySQL Pool B → 日志

3.服务级隔离

订单服务独立部署

推荐服务独立部署

2.4 隔离的核心机制

1. 限制并发

常见实现方式：

• 计数器
• Redis Lua（企业推荐）
• Semaphore（信号量）
• 连接池（企业最常见）

2. 资源独立

不同业务使用不同连接池

3. 队列缓冲

请求 → Queue → Worker

4. 超时保护

避免资源长时间占用

三、最佳实践

3.1 按业务隔离

订单 / 支付 / 推荐 / 搜索

每个独立资源池

3.2 按优先级隔离

3.3 必须限制并发

每个模块独立最大并发

3.4 必须配合熔断

隔离 + 熔断 = 防止扩散

3.5 必须配合降级

资源不足 → fallback

3.6 推荐架构模型

            Gateway
               │
     ┌─────────┼─────────┐
     │         │         │
  Order     Payment   Search
   Pool       Pool      Pool
     │         │         │
 DB Pool   DB Pool   DB Pool