连接池隔离需独立池+有边界：为各服务配专属池、硬限大小与超时、加健康检查与监控、php-fpm/nginx协同隔离。

连接池隔离不是加个配置就完事，关键是让每个依赖服务“各用各的池”，互不抢资源、不互相拖垮。核心就两条：独立池 + 有边界。

为每个下游服务配专属连接池

别让支付、用户、订单全挤在一个池子里。一个接口变慢或超时，就会把整个池子占满，其他调用全被堵死。

• Java（如 HikariCP / Resilience4j）：按服务名创建独立数据源，比如 dataSource-payment、dataSource-user，各自配置 maxPoolSize、connectionTimeout
• Python（SQLAlchemy + asyncpg）：用不同 engine 实例，绑定不同 connection pool 参数，避免共用 pool 对象
• Redis：每个业务模块用独立 RedisClient，连接池参数（max_connections、socket_timeout、health_check_interval）单独设，不复用全局 client

硬性限制池子大小和等待行为

池子不能无限扩张，也不能让请求无休止排队——排队等于积压，积压等于线程卡死，卡死等于雪崩起点。

• 设置 max_connections ≤ 下游服务单实例承载能力 × 0.7（留缓冲）
• 拒绝策略选 CALLER_RUNS 或直接抛异常，不进队列；避免队列堆积引发延迟放大
• 所有连接必须设 socket_timeout（建议 1–2 秒） 和 connection_timeout（≤ 500ms），防住慢建连和慢响应

配合健康检查与实时监控

光隔离不够，得知道池子是不是真健康。连接空转、假连接、连接泄漏，都会让“看起来有连接”实际不可用。

• 开启 health_check_interval（如 Redis 每 30 秒 ping 一次），自动剔除失效连接
• 接入 OpenTelemetry 或 Prometheus，重点看：active connections、pool usage rate、connection acquire timeout count
• 当拒绝率 > 5% 或平均获取耗时 > 200ms，自动告警并触发容量评估

特别注意 PHP-FPM 和 Nginx 的协同隔离

Web 层若没隔离，连接池再好也白搭。PHP 脚本崩溃、死循环会吃光整个 FPM 进程池，导致所有站点 502。

• 为每个网站建独立 PHP-FPM pool（如 site-a.com），配专属 socket、user、open_basedir
• pool 内设 request_terminate_timeout = 30s，Nginx 配 fastcgi_read_timeout 30s，双向超时对齐
• Nginx 启用 fastcgi_next_upstream error timeout http_500 http_502，池失败时快速切走，不堆积