Redis 8.10：紧凑 Hash、JSONPath 扩展与增量备份

Redis Open Source 8.10 已正式发布。这一版本主要围绕三个方向改进：提高内存与处理效率，增强数据结构的表达能力，以及降低大规模部署的运维负担。

其中，紧凑 Hash 可以让结构相似的数据共享字段名，降低内存占用；新的批量导入方式减少重复传输和解析字段的开销。JSON、Streams、Sets、Lists 和 Time Series 的命令也得到扩展，使应用能够在 Redis 内完成更多处理，减少网络往返。增量备份与恢复则为多分片集群提供了资源峰值更低的备份方式。

Hash 与 Streams 的性能改进

Redis 团队在发布说明中列出了以下性能与内存优化结果。这些数字对应表中描述的操作和数据形态，不能直接套用于所有工作负载。

数据类型	操作或数据形态	改善情况
Hash	对新建、字段较多的 Hash 执行 HSET、HMSET	吞吐量最高提高 104%
Hash	多个键使用相同字段名 Schema	内存占用最高降低 50%
Streams	XREADGROUP，COUNT 100	吞吐量最高提高 28%
Streams	条目较多的 Stream	内存占用最高降低 26%

Compact Hash：共享字段名，减少重复存储

用户画像、会话和特征存储中，经常存在大量字段相同的 Hash。例如，数百万份用户记录都包含 name、email、country 和 last_login。以往每个 Hash 都要单独保存一份字段名。

Redis 8.10 引入 Hash 模板这种内部编码，让多个 Hash 共享同一组字段名，同时独立保存各自的值。对于大量结构相似的 Hash，内存占用最高可以降低 50%。

新命令 HIMPORT 则用于高效批量导入具有相同字段的 Hash。客户端先准备一次字段集：

Plain 复制代码

HIMPORT PREPARE user-profile name email country last_login

之后导入每条记录时，只需发送对应的值：

Plain 复制代码

HIMPORT SET user:1 user-profile "Alice" "alice@example.com" "UK" "2026-07-14"


HIMPORT SET user:2 user-profile "Bob" "bob@example.com" "US" "2026-07-14"

字段名不再为每个 Hash 重复传输和解析，网络与服务端处理开销随之降低，Hash 导入吞吐量最高可达到原来的 2 倍。已有 Hash 命令继续保持原有语义。运维人员也可以选择对符合条件的 Hash 启用自动模板转换，而不要求应用改用 HIMPORT。

这项机制尤其适合字段集稳定、记录数量大的用户画像、会话、特征存储，以及批量导入和 ETL 负载。

JSONPath：在 Redis 内完成更多过滤与计算

Redis JSON 使用 JSONPath 访问和操作文档中的特定部分，无需每次获取完整文档。Redis 8.10 扩展了 JSONPath 的语法与函数，让过滤、计算和聚合可以更多地在服务端完成。

新增能力包括算术与比较运算、in、nin 和过滤条件取反，也涵盖字符串、数组、对象及节点列表操作。字符串函数包括 match()、search() 和 concat()；数组函数包括 first()、last()、append() 和 index()。聚合函数提供 min()、max()、avg()、sum()、stddev()，还增加了 length()、count()、keys()、value() 等函数。

例如，可以直接计算折扣价格、数组平均值，或统计符合条件的项目数量：

Plain 复制代码

JSON.GET key '$.price * 0.8'


JSON.GET key '$.arr1.avg()'


JSON.GET key 'count($.items[?@.price > 10])'

把这部分过滤和后处理放到 Redis 中，可以减少返回客户端的数据量，也让应用代码更简洁。

Streams：限制跨多个 Stream 的总返回量

XREAD 和 XREADGROUP 原有的 COUNT 限制分别作用于每个 Stream。一次读取多个 Stream，或者条目本身较大时，总响应仍可能超出预期。

Redis 8.10 增加 MAXCOUNT 和 MAXSIZE：前者限制所有 Stream 合计返回的消息数量，后者限制整体响应的字节大小。

Plain 复制代码

XREAD COUNT 100 MAXCOUNT 200 STREAMS stream:1 stream:2 stream:3 0 0 0

这个示例最多从每个 Stream 读取 100 条消息，但所有 Stream 合计不超过 200 条。应用可以据此约束网络传输和内存消耗，避免出现过大的响应。

Sets：不取回成员，也能计算并集与差集大小

用户分群、权限集合、商品分类和搜索过滤经常使用 Set。很多场景只关心运算结果有多少成员，并不需要拿到成员本身。

Redis 已有用于交集基数计算的 SINTERCARD，8.10 又增加了并集与差集的对应操作：

Plain 复制代码

SUNIONCARD numkeys key [key ...] [APPROX] [LIMIT limit]


SDIFFCARD numkeys key [key ...] [LIMIT limit]

SUNIONCARD 返回并集的基数，SDIFFCARD 返回第一个集合减去后续集合后的基数。应用因此不必为了计数传回大量成员，也不必先创建临时 Set。

SUNIONCARD 还可以通过 APPROX 使用基于 HyperLogLog 的快速估算，其标准误差为 0.81%。

Lists：原子移动一批元素

Redis List 常用于队列、栈和处理流水线。LMOVE、BLMOVE 已经能够在两个 List 之间原子移动单个元素，8.10 则引入批量形式：

Plain 复制代码

LMOVEM source destination <LEFT|RIGHT> <LEFT|RIGHT>
       [<COUNT|EXACTLY> count <OBO|BULK>]


BLMOVEM source destination <LEFT|RIGHT> <LEFT|RIGHT> timeout
        [<COUNT|EXACTLY> count <OBO|BULK>]

COUNT 表示最多移动指定数量的元素；EXACTLY 则要求可用元素达到指定数量，才移动整批。应用还可以选择逐个移动的 OBO 顺序，或保留所移动元素相对顺序的 BULK 模式。

批量任务领取、队列处理、流水线交接和重试队列，都可以利用这些命令，在一组元素需要一起转移时保持原子性。

Time Series：按时间戳组织跨序列查询

彼此相关的时间序列往往拥有相同时间戳，却分开存储。例如金融 OHLCV 数据会分别保存开盘价、最高价、最低价、收盘价和成交量。

TS.MRANGE 按时间序列组织返回结果，需要时间戳对齐的应用还要在客户端重新整理。Redis 8.10 新增 TS.NRANGE 和 TS.NREVRANGE，对明确指定的一组序列查询，并按时间戳组织结果：

Plain 复制代码

TS.NRANGE 5 {ACMZ}:open {ACMZ}:high {ACMZ}:low
            {ACMZ}:close {ACMZ}:volume
            <fromTimestamp> <toTimestamp>

由于键是显式指定的，这类查询不要求标签。在 Redis Cluster 中，所有指定键必须位于同一个哈希槽。命令还支持为不同序列指定各自的聚合器，在同一次查询中采用不同聚合函数。

这让金融分析、监控面板和机器学习特征提取更容易直接消费按时间对齐的数据，减少客户端透视转换。

阻塞等待新增样本

实时面板常常通过反复轮询判断是否有新样本。新增的 TS.READ 提供可选阻塞读取：

Plain 复制代码

TS.READ key timestamp
        [BLOCK milliseconds min_count]
        [MAX_COUNT max_count]

应用可以等待样本达到最小数量，或在指定超时后返回，减少持续发出范围查询的需要。这适用于实时展示、监控、金融、告警和 IoT 等连续消费时间序列的场景。

排除时间范围内没有样本的序列

TS.MRANGE 和 TS.MREVRANGE 可能返回满足标签过滤、但在指定时间范围内没有样本的序列。8.10 增加 EXCLUDEEMPTY：

Plain 复制代码

TS.MRANGE - 500 WITHLABELS EXCLUDEEMPTY FILTER s=1

启用后，这些空结果会被省略，减少无效返回内容和客户端过滤工作。

增量备份与恢复：错开快照，协调完成备份

大型 Redis Cluster 的备份可能产生明显的资源压力。创建 RDB 快照需要 fork，同一节点上的多个分片如果同时执行，CPU 和内存用量会出现峰值，影响工作负载，甚至造成备份失败。

Redis 8.10 围绕新的 BACKUP 命令族提供增量备份与恢复。各分片不必同时创建快照，可以错开执行，同时形成协调一致的备份过程。

每份备份以某一时刻的 RDB 快照 BASE 开始。在备份保持打开期间，Redis 将后续写入记录到增量 INCR AOF 文件中。封存备份时，RDB、增量 AOF 和 Manifest 一起构成完整备份，表示备份窗口结束时的数据集状态。

封存不要求再次 fork。因此，即便各分片在不同时间生成了基础快照，也能够在结束时协调封存，降低同一节点多个分片同时制造资源峰值的压力。

恢复时，新增的 preload-file 启动选项可以加载已封存备份的 Manifest，也可以加载独立 RDB 文件。

Redis 8.10 已在 Redis Open Source 中正式可用，可以从Redis获取版本，在自己的数据结构、吞吐和备份负载中验证这些改进。