Redis × Database / 连接池观察台
命中率提高一点，为什么排队会少一大截？
同一波 GET /users/:id 请求到来时，Redis 命中的请求在缓存层结束；只有未命中请求争抢数据库连接。调节参数，观察回源量跨过连接池容量倍数时出现的“台阶”。
GET /users/:id
模拟结果
Redis 命中600
数据库回源200
需要批次5
估算完成时间400 ms
首批排队请求160
00 ARRIVE请求同时到达
01 CACHERedis 分流
02 POOL占用数据库连接
03 DRAIN按批次清空队列
请求分流命中 75% · 回源 25%
连接池占用
40 条连接会被首批回源请求占满。
每格代表 2 条连接，共显示 20 格
首批之后的等待队列
池满时，多出来的查询必须等待前一批释放连接。
160 个等待占回源 80%
5 批 × 80 ms ≈ 400 ms
完成时间不是平滑增加，而是一级一级跳
横轴是在当前命中率下逐步增加的并发请求数；每多凑够一池回源请求，就多付一次数据库查询耗时。
当前缓存命中率0% 命中时的对照
800 个请求中，600 个由 Redis 直接返回；200 个回源数据库，40 条连接需处理 5 批。
02 / 计算口径
这个模型算的是什么
回源量 = ⌈请求数 × (1 − 命中率)⌉
批次数 = ⌈回源量 ÷ 连接池大小⌉
完成时间 ≈ 批次数 × 单次查询耗时
首批排队 = max(0, 回源量 − 连接池大小)
批次数 = ⌈回源量 ÷ 连接池大小⌉
完成时间 ≈ 批次数 × 单次查询耗时
首批排队 = max(0, 回源量 − 连接池大小)
03 / 假设与边界
它是教学估算，不是性能压测报告
- 把这一波请求视为同时到达，每个未命中请求占用一条数据库连接。
- 假设所有数据库查询耗时相同，Redis 命中返回时间相对很小，不计入总耗时。
- 不包含网络抖动、线程调度、连接获取超时、慢 SQL、连接池预热和下游限流。
- “完成时间”表示清空这一波数据库查询的理想化估算，不代表单个请求的真实 P95/P99 延迟。
真正压测时，应结合接口链路、连接池等待指标、数据库吞吐与延迟分位数一起判断；这里的价值是先看懂“命中率 → 回源量 → 批次 → 排队”的因果链。