短链系统压测报告

被测系统：nageoffer / shortlink（Spring Boot 3.0.7 + ShardingSphere-JDBC 5.3.2 + Redis Stream） · 服务器：10.176.36.38 · 压测时间：2026-10-07 · 压测工具：JMeter 5.6.3（CLI）

覆盖范围：读路径（短链跳转，A7 / B4 / C1 / C2 / C4 / C9，第一~五章） + 写路径（创建接口 G1 / G2 对比，见 2.2）

一、测试环境#

1.1 服务器配置#

注：宿主机为非独占环境，基准负载已达 17~21，是本次测试的主要噪声来源，所有结论均按“同一时段内相对对比”口径给出。

1.2 部署与运行参数#

1.3 测试条件#

二、结果总览#

2.1 读路径 · 短链跳转#

2.2 写路径 · 短链创建接口对比#

三、逐项结果#

A7 · 分片数据一致性#

复核 t_link_N 与 t_link_goto_N 的对应关系，两侧分别导出 (full_short_url, gid) 后做双向差集与 join 比对。

B4 · 缓存预热#

先清空 short-link:goto:* 制造冷启动，再用 20 并发 × 120s 遍历全部可达短码。

C1 · 冷 / 热缓存对比#

同一批 10000 个短码、50 并发、每码只访问一次。冷：先清空 goto:*；热：紧接着再跑一遍（缓存已被上一遍预热）。重复 3 轮。

C2 · 缓存穿透#

100 并发 × 60s 持续请求 1000 个确保不存在的随机短码（先用全量真实短码做去重校验）。

C4 · 限流降级（生产态）#

在未做任何修改的生产配置下打创建接口。被限流的响应是 HTTP 200 + 业务码，因此必须断言响应体而不能只看状态码。

• 限流按 80:20 分工：用户级风控（Redis LUA 计数器，20 请求/秒窗口）挡掉 80%，Sentinel 单机 QPS=1 兜住剩下的 19%。
• 被限流的请求是快速失败（66~219 ms），真正的成功请求反而最慢（661~872 ms）——说明降级生效且没有把线程池堵死。
• 600 次请求只有 24 行落库（4.0%），限流真正拦掉了 96% 的写压力。
• 风控计数 key short-link:user-flow-risk-control:admin 事后 TTL=-2（已被清理），未出现计数泄漏。

C9 · Redis 内存膨胀#

用一条全新创建的短链（45seFe，其 UV/UIP Set 此刻还不存在）做干净基线，20 线程 × 500 轮 = 10000 次访问，每次带全局唯一 X-Forwarded-For、且不带 Cookie（迫使服务端每次新生成 uv UUID）。

上表的 Redis 全局 used_memory 是混合口径（同时含统计 Stream 与幂等键的开销），不能直接除以请求数当作 Set 的成本。因此再对两个 key 逐条做 MEMORY USAGE + OBJECT ENCODING 精确计量：

G1 / G2 · 短链创建接口对比#

四、附带发现①：布隆过滤器缺口（严重）#

缺陷 createShortLinkByLock 从不把 fullShortUrl 写入布隆过滤器。

读源码对比两条创建链路的收尾逻辑：

// createShortLink —— 有
stringRedisTemplate.opsForValue().set(GOTO_SHORT_LINK_KEY + fullShortUrl, ...);
shortUriCreateCachePenetrationBloomFilter.add(fullShortUrl);
return ...;

// createShortLinkByLock —— 无
stringRedisTemplate.opsForValue().set(GOTO_SHORT_LINK_KEY + fullShortUrl, ...);
// 全方法内没有任何 shortUriCreateCachePenetrationBloomFilter.add(...)
return ...;

后果：by-lock 链路创建的短链只活在 Redis goto 缓存里。一旦缓存被清空 / 过期 / 驱逐，restoreUrl 会在布隆过滤器处被短路 —— 连 DB 都不查：

boolean contains = shortUriCreateCachePenetrationBloomFilter.contains(fullShortUrl);
if (!contains) {
    ((HttpServletResponse) response).sendRedirect("/page/notfound");
    return;                       // ← 到此为止，t_link_goto 里的记录形同不存在
}

4.1 全量冷缓存普查#

清空 goto:* 后，用并发 50 逐个访问全部 21624 个短码（墙钟 135.9 s，159.1 req/s）。

随机抽 5 个不可达短码，逐一核查两个分片表 —— 记录全部存在：

4.2 最小可复现实验（A / B 对照）#

造两条链：A 走 POST /api/short-link/v1/create，B 走 POST /api/short-link/v1/create/by-lock；其余参数完全一致。在两条都删掉 Redis 缓存的同样条件下对比。

补充验证：

1. 实验后 B 的 t_link_goto_15 记录依然健在（1 行）——排除“数据被删”。
2. 手工把 B 的缓存 key 写回去，立刻恢复 302 → http://127.0.0.1:21003/ ——佐证阻塞点就在「布隆过滤器 + 缓存」这一层，DB 无需任何改动。

五、附带发现②：统计 Stream 积压（严重）#

在压测收尾时读取 Redis Stream 状态，发现积压 23 万条未消费消息。

根因在 RedisStreamConfiguration：

@Bean
public ExecutorService asyncStreamConsumer() {
    return new ThreadPoolExecutor(
        1,                       // corePoolSize
        1,                       // maximumPoolSize  ← 消费者只有 1 个线程
        60, TimeUnit.SECONDS,
        new SynchronousQueue<>(),       // ← 队列容量 0，完全不缓冲
        ...,
        new ThreadPoolExecutor.DiscardOldestPolicy()   // ← 满了直接丢弃任务
    );
}
// 另有 .batchSize(10) / .pollTimeout(3s)

而单条消息的处理成本极高（ShortLinkStatsSaveConsumer#actualSaveShortLinkStats）：

• 1 次 Redisson 读锁（按 fullShortUrl）
• 1 次 DB 查询取 gid
• 8 次 DB 写：access_stats / locale / os / browser / device / network / access_logs / t_link.incrementStats / stats_today
• 1 次同步外网 HTTP：HttpUtil.get(AMAP_REMOTE_URL, ...) 高德 IP 归属地解析，未设置任何超时
• 1 次 XDEL（仅成功后才删）

附录 · 指标口径说明#

本报告的每一个指标都是「分子 / 分母」或「单位量」。下表给出确切定义，便于独立复核。