2.1 硬件与操作系统#

2.2 软件版本#

2.3 JVM 参数（关键）#

16G 内存要同时跑 4 个 Java 服务 + NameServer + Broker + JMeter + MySQL + Redis，堆必须精打细算：

全部进程稳定运行时约占用 3 GB 出头，16G 内存刚好能覆盖，但已没有余量——这也是吞吐数字偏保守的原因之一。

2.4 部署拓扑#

1
┌────────────────────────── 笔记本（R7 6800H / 16G / Win11）──────────────────────────┐
2
│                                                                                     │
3
│  JMeter(压测机) ──HTTP──> merchant-admin:10010 ─┐                                   │
4
│                          engine:10020           ├─> MySQL 8.0（64 张分表）          │
5
│                          settlement:10030       ├─> Redis 5.0.14                   │
6
│                          distribution:10040     └─> RocketMQ 5.3.4（NS + Broker）   │
7
│                                                                                     │
8
│  服务间协作：MySQL 共享表 + RocketMQ 消息（Nacos 已禁用，无 RPC 调用）             │
9
└─────────────────────────────────────────────────────────────────────────────────────┘

说明：Nacos 在各服务配置中均为 enabled: false——该项目服务间没有远程调用（协作靠共享表 + MQ），服务发现形同虚设，直连端口调用即可。

4.1 场景#

结算页要遍历用户全部可用券计算最优组合。项目里有两个版本：

• 同步版 /coupon-query-sync：串行遍历
• 并行版 /coupon-query：CompletableFuture 并行金额试算 + Redis Pipeline 批量读模板

4.2 结果（80 线程 × 1000 循环 = 8 万请求/组）#

4.3 反直觉结论：并行版比同步版慢 6.5%#

这是本次压测第一个值得写的发现。原因分析：

1. 金额试算是 CPU 轻量任务（几次比较和加减），单次计算微秒级，并行化的收益封顶就这么点
2. CompletableFuture 线程上下文切换的开销 > 计算本身
3. 并行收集结果用了 synchronizedList，高并发下锁竞争进一步吃掉吞吐

真正有效的优化是 Redis Pipeline：把逐个 hGetAll 模板的 N 次网络往返合并成 1 次批量请求——这解释了为什么同步版 + Pipeline 反而是最快的组合。

结论：并行化适合 IO 密集型任务，CPU 轻量任务并行只会更慢。“用了 CompletableFuture”不等于”更快”，压测数据说话。

5.1 链路#

1
布隆过滤器(防穿透) → Redis Hash 模板校验 → Lua 原子扣减库存+记领取次数
2
→ RocketMQ 异步落库(消费幂等 + 64 分表批量插入 + 延时消息到期关闭)

前置准备：创建 stock = limitPerPerson = 2000 万的立减券模板；Lua 脚本的位运算返回值字段从 14 bit 改 16 bit（支持 6 万+ 的领取计数）。

5.2 结果（100 线程 × 400 循环 = 4 万请求）#

5.3 压测插曲：4 万条消息在消费端全军覆没#

第一轮压测后对账发现：接口层 4 万次全部成功，但消费端一条都没落库，消息在无限重试。

排查路径：消费日志 → 每条消息都报 @user_script:4: ERR syntax error → 定位到幂等防重切面里的这段 Lua：

1
-- 修复前（Redis 7.0+ 语法）
2
return redis.call('SET', key, value, 'NX', 'GET', 'PX', expire_time_ms)

SET key val NX GET PX 这个组合语法是 Redis 7.0 才引入的。本机 Redis 5.0.14 直接报语法错误，导致幂等组件失效 → 全部消息消费失败 → 退避重试。

修复（等价改写，Lua 内天然原子）：

1
-- 修复后（Redis 2.6+ 兼容）
2
local old = redis.call('GET', key)
3
if old then
4
    return old
5
end
6
redis.call('SET', key, value, 'PX', expire_time_ms)
7
return false

教训两点：

1. 写中间件相关代码时要确认目标版本，“新语法”在旧版本上不是降级而是直接报错
2. 压测必须做全链路对账——如果只看接口成功率，这个 Bug 完全发现不了

5.4 其他本阶段踩坑#

• RocketMQ 5.x 定时消息（timer wheel）最大延迟 3 天，模板有效期设到 3 天外会创建失败
• 消费失败重试是退避式的（10s/30s/1m/2m/…/2h），修完代码不会立刻追平，要有耐心等收敛

6.1 场景#

批量发券：EasyExcel 流式读取 100 万行用户名单 Excel（29.4MB），逐行 Lua 预扣库存，攒批 5000 条发 MQ，消费端批量落库（两级 MQ 拆解）。

6.2 结果#

任务状态正常完成（status=3），但少了 5000 条，失败表却一条记录都没有——数据静默丢失。

6.3 排查过程#

第一步：MySQL 复查。 多次计数确认 995000 不变，排除”还在重试补齐”的可能。

第二步：mqadmin 查消费组状态。 Topic 全部 ACK（diff=0），重试队列只有 1 条且已消费，无死信队列——说明末批消息被”成功”消费了，但数据没进库。

第三步：拉取 broker 末尾消息做尸检。 用 queryMsgByOffset 拉出 4 个队列的末尾消息，真相浮出水面——连续两条数据消息的 batchUserSetSize 分别是 5002、5003（连续两行的 Set 快照，差 1），最后一条 EndFlag 消息紧随其后。

6.4 根因：三个设计缺陷叠加#

缺陷 1：消息风暴。 发送侧的条件写的是 SCARD >= 5000 时发送（而非 == 5000）。消费组一旦滞后、Redis Set 积压超 5000，Excel 每读一行就发一条 MQ 消息。100 万行的任务实际发出 9349 条消息，是理论值（200 批 + 1 结束标识）的 4.7 倍。

缺陷 2：快照错位多扣库存。 消费端用消息里的 batchUserSetSize 快照决定扣库存数量和 SPOP 数量。消息乱序消费时，快照与 Set 实际内容错位——某条消息按快照扣了 5000 库存，SPOP 实际弹出 0 条（早被别的消息弹走了），事务却正常提交。总扣减 1000001 = 995000 落库 + 5000 空扣 + 1 次单测验证，账目完全闭合。

缺陷 3（核心）：Redis SPOP 无法随 MySQL 事务回滚。 那条进入重试队列的消息（中途一次瞬时失败触发重试），首次消费时 SPOP 弹出 5000 条 → 后续 MySQL 事务回滚 → 但 Redis 的弹出不会跟着回滚。消息重试时 Set 内容已变，弹到的是下一批数据，首次弹出的 5000 条永久丢失。落库 995000 + 失败表 0 + Set 清空 + 无死信，所有账目都能对上——这是”非事务资源先于事务提交被消费”的经典分布式一致性缺口。

缺陷 4（附赠）： 通知组消费者对 notifyType="" 做 StrUtil.split("") 得到 [""]，parseInt("") 抛 NumberFormatException，导致通知组每批消息退避重试 16 次（不影响落库，但浪费消费资源）。

6.5 修复方向#

1. 发送侧：改为”SCARD 恰好等于 5000 才发消息”，消除消息风暴
2. 消费侧：扣库存/SPOP 数量改用实际弹出条数，消除快照错位
3. 数据不丢的思路：SPOP 改为”先弹到临时 key 暂存、落库成功后再确认删除”；或改用游标模式（按批次号定位数据，先落库后清理）；或引入本地消息表做对账兜底

6.6 关于”5000 条 v1 → v2 提升 60 倍”的说法#

教程宣称同步版 5000 条要 1 分钟、优化后 1 秒内（60 倍）。我没有复刻 v1 实测，但可以给出有锚点的推算：

• v2 实测吞吐 1103 行/秒 → 5000 条约 4.5 秒
• v1 同步逐条：每行 3 次 DB 往返（查重 + 扣库存 + 插入）≈ 200 行/秒 → 5000 条约 25~30 秒
• 端到端约 6 倍；单看落库环节（逐条 200 行/秒 → 5000 条/批约 2500 行/秒）是一个数量级

为什么不是 60 倍？因为本机 v2 的瓶颈根本不在落库，而在 Excel 逐行处理时每行 3 次 Redis 往返（GET 进度 + Lua 扣减 + SET 进度）——它稀释了批量落库的收益。这也提示了下一步优化方向：进度记录攒批写，或用 Pipeline 合并往返。