后端性能Redis

Redis 8.10：全新紧凑哈希与开源特性

Redis 8.10 发布，紧凑哈希把内存占用最多降低 50%、加载吞吐翻倍，另外带来增量备份恢复、更完整的 JSONPath 查询，以及 Streams 与 Time Series 的若干新命令。

Redis BlogBosmat Tuvel7 分钟阅读

中文
中文日本語
复制
题图：Redis 的红底品牌图，正中间是白色的手写体 Redis 标志

Redis 8.10 已在 Redis Open Source 中发布，带来了一系列改进，让 Redis 更省内存、表达力更强，也更容易在大规模场景下运维。

亮点包括：紧凑哈希内存占用最多降低 50%、哈希加载吞吐量提升 2 倍，增量备份与恢复，JSONPath 语法扩展，更灵活的 Stream 消费方式，新的 Set 基数运算，多个 List 元素的原子移动，以及增强的 Time Series 能力。

Redis 8.10 为什么值得关注

Redis 8.10 聚焦三个方面：提升效率、扩展 Redis 数据结构的能力、简化生产环境的运维。

性能方面，紧凑哈希和 Stream 优化在降低内存占用的同时提升了吞吐量，让应用能从现有基础设施中榨出更多性能。RedisJSON、Streams、Lists、Sets 和 TimeSeries 上新增的一批命令与增强，也让常见操作表达力更强，减少应用层的复杂度，以及完成日常任务所需的往返次数。

对运维人员来说，增量备份与恢复的引入，使得创建协调一致的集群备份成为可能，同时对运行中负载的影响显著降低，从而提升大型 Redis 部署的可靠性。

下面逐一来看这些新增内容。

性能亮点

除了新功能，Redis 8.10 还包含多项性能优化，提升了哈希和 Stream 的吞吐量与内存效率。亮点汇总如下：

数据类型操作收益
Hash对宽表、新建哈希执行 HSET、HMSET吞吐量最多提升 104%
Hash共享字段名结构的键内存占用最多降低 50%
StreamsXREADGROUP吞吐量最多提升 28%（COUNT 100）
Streams深层 Stream内存占用最多降低 26%

除了这些性能提升，Redis 8.10 还在数据结构、RedisJSON、RedisTimeSeries、Streams 和数据管理方面引入了多项新能力。

Redis 8.10 新特性

紧凑 Hash

应用经常会创建大量字段相同的 hash，比如数百万个用户档案，每个都包含 name、email、country 和 last_login。传统做法下，每个 hash 都要单独存一份这些字段名。

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

Redis 8.10 还引入了 HIMPORT，专为高效批量写入字段相同的 hash 而设计。客户端只需准备一次字段集合：

HIMPORT PREPARE user-profile name email country last_login

之后写入 hash 时只发送值即可：

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 反复发送和解析字段名，HIMPORT 降低了网络开销和服务端处理开销，hash 写入吞吐量最高可提升至 2 倍。

现有 hash 命令的语义保持不变。运维人员也可以对符合条件的 hash 开启自动模板转换，应用无需改用 HIMPORT。

当大量 hash 共享一套稳定的字段集合时，hash 模板效果最好，因此特别适合用户档案、会话、特征存储、批量导入和 ETL 等场景。

JSON：表达能力更强的 JSONPath 查询

Redis JSON 使用 JSONPath 表达式来访问和操作 JSON 文档中的特定部分，无需取回整个文档。

Redis 8.10 大幅扩展了 JSONPath 语法，应用可以直接在 Redis 中完成更多过滤、计算、聚合和数据处理。

新增能力包括：

  • 算术和比较运算符

  • in、nin 以及过滤器取反

  • 对字符串、数组、对象和节点列表的操作

  • 字符串函数，如 match()、search() 和 concat()

  • 数组函数，如 first()、last()、append() 和 index()

  • 聚合操作，包括 min()、max()、avg()、sum() 和 stddev()

  • 函数，如 length()、count()、keys() 和 value()

例如：

JSON.GET key '$.price * 0.8'

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

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

新增的表达能力让应用可以把更多过滤和后处理逻辑放进 Redis，从而减少数据传输、简化应用代码。

Streams：控制 XREAD 结果的总大小

XREAD 和 XREADGROUP 已经支持 COUNT，但该限制对每个 Stream 单独生效。当从多个 Stream 读取，或 Stream 中包含大条目时，整体响应仍可能变得非常大。

Redis 8.10 新增两个选项：

  • MAXCOUNT：限制所有 Stream 返回的消息总数。

  • MAXSIZE：限制整体回复的字节大小。

例如：

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

该命令最多可从每个 Stream 读取 100 条消息，同时整体返回不超过 200 条消息。

这些控制手段帮助应用约束网络传输和内存消耗，避免出现意料之外的大回复。

Sets：不取回成员即可获得并集与差集的基数

应用经常用 Sets 表示用户分群、权限、商品类目或搜索过滤条件等集合。它们往往需要知道有多少元素符合某个运算，而不必把元素本身取回来。

Redis 已经为 Set 交集提供了 SINTERCARD。Redis 8.10 为并集和差集补上了对应的操作：

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

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

SUNIONCARD 返回并集的基数，SDIFFCARD 返回第一个 Set 与后续 Set 之间差集的基数。

这样就无需把可能很大的集合返回给客户端，也不必仅仅为了计数而创建临时 Set。SUNIONCARD 还可以使用 APPROX，基于 HyperLogLog 快速估算，标准误差为 0.81%。

Lists：原子地移动多个元素

Redis Lists 常用于队列、栈和处理流水线。LMOVE 和 BLMOVE 已经允许应用在 Lists 之间原子地移动单个元素，但许多工作流需要一次认领或转移多个元素。

Redis 8.10 引入：

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>]

新命令可以原子地把多个元素从一个 List 移动到另一个 List。

COUNT 最多移动请求数量的元素，而 EXACTLY 仅在请求的完整数量都可用时才移动整批元素。应用还可以在逐个（OBO）排序和 BULK 排序之间选择，后者会保留被移动元素的相对顺序。

这适用于批量任务认领、队列处理、流水线交接、重试队列，以及其他需要成组移动元素的工作流。

Time Series：按时间戳查询多个序列

相关联的 Time Series 通常分开存储，尽管它们共享时间戳。例如金融 OHLCV 数据可能为 open、high、low、close 和 volume 分别使用独立的序列。

TS.MRANGE 返回的结果按 Time Series 分组，这意味着需要时间戳对齐数据的应用往往得自行重新组织结果。

Redis 8.10 引入了 TS.NRANGE 和 TS.NREVRANGE，它们查询一组显式指定的 Time Series，并返回按时间戳分组的结果：

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

由于键是显式指定的，因此不需要标签。在 Redis Cluster 中，所有指定的键必须属于同一个哈希槽。

这两个命令还支持按序列设置聚合器，应用可以在同一次查询中对不同的 Time Series 应用不同的聚合函数。

这让时间戳对齐的数据更易于消费，适用于金融应用、分析流水线、监控仪表盘和机器学习特征提取，无需在客户端做透视转换。

Time Series：用阻塞读取等待新数据

展示实时 Time Series 数据的应用经常反复轮询 Redis，以判断是否有新样本到达。

Redis 8.10 引入了 TS.READ，这是一个可选阻塞的命令，让应用可以等待新样本：

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

应用无需持续发起范围查询，而是可以阻塞，直到有最少数量的样本可用，或者指定的超时时间到期。

TS.READ 适用于实时仪表盘、监控系统、金融应用、告警，以及持续消费新 Time Series 数据的 IoT 工作负载。

时间序列：排除空结果

TS.MRANGE 和 TS.MREVRANGE 可能返回符合过滤条件、但在所请求时间范围内不含任何样本的时间序列。

Redis 8.10 新增了 EXCLUDEEMPTY 标志：

TS.MRANGE - 500 WITHLABELS EXCLUDEEMPTY FILTER s=1

使用 EXCLUDEEMPTY 后，在所请求范围内没有样本的匹配时间序列会从响应中省略，从而减少不必要的结果数据和客户端过滤。

增量备份与恢复

备份大型 Redis Cluster 部署可能非常消耗资源。创建 RDB 快照需要 Redis 执行 fork，而同一节点上的多个分片同时 fork 时，CPU 和内存占用会飙升，导致工作负载变慢甚至备份失败。

Redis 8.10 引入了增量备份与恢复，围绕新的 BACKUP 命令族构建。

不再要求每个分片同时捕获快照，而是可以让各分片的快照错开进行，同时仍生成一份协调一致的备份。每次备份都从一个时间点一致的 RDB 快照（BASE）开始。随后，在备份保持打开期间，Redis 将后续写入记录到增量（INCR）AOF 文件中。

备份封存时，RDB 快照、增量 AOF 文件和清单共同构成一份完整备份，代表备份窗口结束时的数据集。封存不需要再次 fork，因此即使各分片的快照创建时间不同，也能一起完成收尾。

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

由此得到的备份流程扩展性更好，资源峰值更低，对于每个节点承载多个分片的大型部署尤其如此。

快速上手

Redis 8.10 已在 Redis Open Source 中正式发布。

下载 Redis 8.10，在你的应用中体验这些新能力。

有反馈或疑问？欢迎加入我们的 Discord 服务器参与讨论，或联系你的客户经理。

来源: Redis Blog← 返回首页