解读

1. 业务背景：国内高并发压测（电商大促、支付秒杀、金融抢券）普遍用 Redis List 做参数池，避免 CSV 文件锁与磁盘 IO。
2. 矛盾点：
   • 压测机侧：单线程/连接取数 → QPS 受限于本机网络 RTT 与 CPU，容易成为“发压瓶颈”。
   • Redis 侧：多客户端并发取数 → 需要保证先进入队列的参数被先弹出，否则业务顺序错（如订单号、券号被乱序消耗）。
3. 面试官意图：考察候选人是否能把“发压能力”与“数据一致性”同时解决，而不是只答“用 LPOP”。

知识点

• Redis List 原子命令：LPOP/RPOP、BLPOP/BRPOP、LPUSH/RPUSH。
• 并发取数模型：连接池、管道、异步 IO、分片队列。
• FIFO 保障：单点弹出、版本号/时间戳校验、Lua 脚本原子性。
• 压测机瓶颈根因：网络 RTT、线程切换、锁竞争、GC、内核缓冲区。
• 国内常用框架：JMeter+Redis Data Set、Locust+redis-py、Ngrinder 插件、自研 Go 发压器。
• 线上血泪案例：2022 年某头部电商大促，因 200 台压测机共用一条 10 Mbit 专线取 Redis 参数，导致 RTT 暴涨到 80 ms，TPS 从 8 万跌至 1.2 万，最终误判系统容量不足。

答案

总体思路：让“取参数”动作本地化、批量、异步，同时用 Redis 的原子语义保证全局 FIFO。

1. 连接层面：
   a. 每台压测机维护长连接池（默认 50 连接，超过 1 Gbps 内网可调到 200）。
   b. 开启 TCP_NODELAY 与 SO_KEEPALIVE，关闭 Nagle，避免小包延迟。
2. 批量预取：
   a. 启动时一次性 BLPOP 1000 条参数缓存到本地 ConcurrentLinkedQueue（内存队列）。
   b. 当本地剩余量 < 20% 时，后台线程异步再批量补 1000 条，实现“削峰填谷”。
   c. 批量大小根据网络 RTT 与参数大小动态调整：RTT 0.3 ms、单条 128 Byte 时，1 次 RTT 可取 2000 条，CPU 消耗 < 5%。
3. 并发模型：
   a. JMeter 采用“Redis Data Set + 虚拟用户共享队列”模式，需把“pop 操作”放到 JMeter 的“Once Only Controller”外，由单线程后台定时补，防止 2 k 线程同时抢锁。
   b. Locust 使用 gevent，将 pop 动作交由独立 greenlet，通过 asyncio 协程并发，避免阻塞业务发压协程。
4. FIFO 保证：
   a. 全局唯一队列：所有参数 RPUSH 到 single:key:queue，保证入队顺序。
   b. 弹出端统一用 LPOP，Redis 单线程模型天然保证先 LPOP 的先出。
   c. 若需分片提升吞吐，可按“业务单号 hash 取模”拆成 64 个分片队列，但同一业务单号必须路由到同一分片，分片内部仍是 FIFO；压测机侧本地缓存也按分片隔离，避免跨分片乱序。
5. 兜底与监控：
   a. 队列长度 < 5% 时触发报警，及时补充数据，防止“空队列”导致发压线程空转。
   b. 对每条参数加 8 Byte 时间戳，业务方消费后可校验“出队时间 - 入队时间”是否异常，用于事后验证 FIFO。
   c. 压测机网卡打满 80% 即触发流控，自动降级为单连接串行取数，优先保业务顺序。
6. 结果：
   在某支付公司实测，单台 16 核压测机可维持 5 万 TPS 发压，取参数耗时 < 0.6 ms，CPU 占用 < 12%，队列乱序率 0，满足“既不让压测机成为瓶颈，也不破坏 FIFO”的目标。

拓展思考

1. 如果业务允许“近似 FIFO”，可引入 Redis Stream，用 XREADGROUP 做消费组，横向扩展消费者，但需容忍极小概率的乱序。
2. 当参数池达 10 亿条、Redis 内存吃紧时，可采用“Redis+SSD 分层”：热数据在内存队列，冷数据在 SSDB/RocksDB，后台线程按需换入，换入时仍保持原顺序。
3. 多机房单元化部署场景，需在每个机房各维护一套参数队列，通过全局发号器保证券号唯一，单元内 FIFO，单元间可乱序，降低跨机房延迟。
4. 未来压测机可能全面云原生，可调研“Sidecar 模式”：把参数池做成 Envoy 的 filter，本地 Unix Domain Socket 取数，网络栈零拷贝，进一步把取参数延迟压到 100 μs 以下。