基准环境
- 机器：AWS EC2 c4.8xlarge（同机部署 Redis Server 与 ReJSONBenchmark 工具，通过网络栈连接）
- 测试工具：ReJSONBenchmark（Go 实现、可配置并发）
- 模式：非管线（non-pipelined）
- 版本：RedisJSON Preview（尚未完全优化）
基线对比：PING
| 工具 | 并发 | 吞吐 (req/s) | 平均延迟 (ms) | 99% 延迟 (ms) |
|---|---|---|---|---|
redis-benchmark |
50 | 140,587 | ≤1 | ≤1 |
| ReJSONBenchmark | 16 | 116,292 | 0.14 | 0.21 |
洞察：Go 测试工具在 PING 下吞吐略低于 redis-cli，但延迟依旧亚毫秒级。
JSON 操作性能
| 测试场景 | 操作 | 吞吐 (req/s) | 平均延迟 (ms) |
|---|---|---|---|
| 空字符串（2B） | JSON.SET / JSON.GET | 80,277 / 92,191 | 0.20 / 0.17 |
| 小对象（380B, pass-100.json） | SET 根 / GET 根 | 41,513 / 48,374 | 0.38 / 0.33 |
| GET 标量路径 | 94,801 | 0.17 | |
| GET 子文档 | 81,634 | 0.19 | |
| 中等数组（1.4 KB） | SET 根 / GET 根 | 16,117 / 15,194 | 0.99 / 1.05 |
| GET 元素 / 子字段 | 78K–99K | ~0.20 | |
| 大对象（3.5 KB） | SET 根 / GET 根 | 14,239 / 8,366 | 1.12 / 1.91 |
| 超大文档（18 KB / 40 KB） | SET 根 / GET 根 (18 KB) | 3,394 / 891 | 4.71 / 17.92 |
| SET 根 / GET 根 (40 KB) | 1,625 / 443 | 9.84 / 36.08 | |
| 数值运算 | NUMINCRBY / NUMMULTBY | 78,640 / 77,171 | ~0.20 |
结论：
- 文档越小，吞吐越高、延迟越低；
- 部分路径操作（标量、子文档）性能远超访问整个根文档；
- 数值原子操作也能保持 >77K req/s 的高吞吐。
与 Server-Side Lua 脚本对比
根级 SET/GET：RedisJSON、Lua(cjson/cmsgpack) 性能相近（80–90K req/s）。
路径级 SET/GET：
- RedisJSON：直接内存访问，无需整体解码，保持 >75K req/s 且延迟稳定；
- Lua：每次都解码整个对象，随着文档增大性能急剧下降（大文档时 <20K req/s）。
洞察：RedisJSON 原生命令在局部更新/读取场景下，解码与操作开销大幅低于基于脚本的实现。
小结
- 极低延迟：空字符串与小对象下，延迟普遍 <0.2 ms。
- 高吞吐量：简单路径查询可达 ~100K req/s；数值运算也能维持 >75K req/s。
- 可扩展性：文档体量增大时，根级操作延迟线性上升，但仍可满足毫秒级需求；部分路径访问保持亚毫秒稳定。
- 优于脚本：相比 Lua 全文解码，RedisJSON 的“就近解码”带来显著性能与资源优势。
通过本次基准，我们可以清晰看到 RedisJSON 在不同载荷与操作模式下的性能特性，为生产环境评估提供了可靠参考。