基准环境

• 机器：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 原生命令在局部更新/读取场景下，解码与操作开销大幅低于基于脚本的实现。

小结

1. 极低延迟：空字符串与小对象下，延迟普遍 <0.2 ms。
2. 高吞吐量：简单路径查询可达 ~100K req/s；数值运算也能维持 >75K req/s。
3. 可扩展性：文档体量增大时，根级操作延迟线性上升，但仍可满足毫秒级需求；部分路径访问保持亚毫秒稳定。
4. 优于脚本：相比 Lua 全文解码，RedisJSON 的“就近解码”带来显著性能与资源优势。

通过本次基准，我们可以清晰看到 RedisJSON 在不同载荷与操作模式下的性能特性，为生产环境评估提供了可靠参考。