Redis 8.6 正式发布：Streams支持幂等生产，热键检测与性能大幅提升

Redis 8.6 来了。

看到这个版本号，感觉它的迭代速度确实很快。从8.0到8.6，并非简单的版本号叠加，而是一次全方位的进化。

性能狂飙：比 Redis 7.2 快 5 倍

官方发布的测试数据是硬核指标。在典型的缓存场景下（1:10 的 SET:GET 比例），Redis 8.6 的吞吐量相比 Redis 7.2 提升了超过 5 倍。

这意味着一台服务器现在可以轻松应对以前扛不住的流量压力。具体的命令优化包括：

• 有序集合命令延迟降低 35% —— 排行榜场景性能直接起飞。
• GET 命令短字符串延迟降低 15% —— 最基础的命令也变得更快了。
• 列表命令延迟降低 11% —— 消息队列操作更丝滑。
• 哈希命令延迟降低 7% —— 缓存对象存取更迅猛。

更值得关注的是内存占用优化。哈希表编码的内存占用减少了 16.7%，跳表编码的有序集合内存占用减少了 30.5%。这意味着以前需要 32GB 内存才能存储的数据量，现在可能只需要 22GB 左右，对云服务器成本控制来说是实打实的利好。

Streams 的“幂等生产”：消息重复问题终于解决了

这个更新可能最贴近实际生产痛点。用过 Redis Streams 的开发者都知道，在网络抖动时，生产者难以判断消息是否发送成功。重发怕重复，不重发又怕丢失，两难境地。

Redis 8.6 引入了幂等生产机制（Idempotent Production），实现了“至多一次”的生产语义。简单说，即使生产者因崩溃或网络故障重复发送同一条消息，Redis 也只会存储一次。

想象一个外卖订单消息流：厨房、库存、配送、财务等多个环节都在消费这条消息。如果消息被重复投递，可能导致库存错乱、财务对账出错。现在有了幂等机制，生产者可以放心重试，而消费者无需担心处理重复数据。

实现方式很简单：

# 使用自动幂等ID
XADD mystream IDMPAUTO * field value

# 或者手动指定生产者ID和消息ID
XADD mystream IDMP <producer-id> <msg-id> * field value

配合两个新的配置参数 stream-idmp-duration 和 stream-idmp-maxsize，可以控制 Redis 记住多少历史消息 ID 以及记住多久。这对金融交易、订单系统、日志收集等场景而言，几乎是刚需功能。

HOTKEYS 命令：运维神器上线

做过 Redis 集群运维的同学，一定被“热 Key”问题困扰过。某个 Key 被高频访问，导致单个节点 CPU 飙升，进而可能引起整个集群性能抖动。过去排查热 Key 往往靠经验和猜测，现在 HOTKEYS 命令来了。

如何使用？

# 开始收集热 Key 数据（监控 CPU 和网络指标）
HOTKEYS START METRICS CPU NET DURATION 60000

# 查看收集结果
HOTKEYS GET

Redis 会明确告诉你哪些 Key 在消耗大量 CPU，哪些 Key 占用了高带宽。该命令还支持采样模式，通过设置 SAMPLE 100 可以只监控大约 1% 的请求，对线上服务的性能影响微乎其微。找到热 Key 后，就可以有针对性地进行拆分大 Key、实施本地缓存或调整业务逻辑，不再需要盲目猜测。

新的内存淘汰策略：LRU 不够用？试试 LRM

Redis 传统的淘汰策略是 LRU（最近最少使用）。但在 AI 场景或时序数据场景中，数据有一个特点：刚写入的数据价值最高，但不一定会被频繁访问。

Redis 8.6 新增了两个淘汰策略：

• volatile-lrm —— 只淘汰设置了过期时间的 Key 中，最近最少被修改的。
• allkeys-lrm —— 在所有 Key 中，淘汰最近最少被修改的。

这里的 LRM 指 Least Recently Modified（最近最少修改）。它按照数据的“修改时间”而非“访问时间”来决定淘汰顺序，对于写入密集型的业务应用更为友好。

TLS 证书自动认证：告别密码管理噩梦

以前使用 mTLS（双向 TLS）连接 Redis 时，客户端在建立 TLS 连接后，通常还需要再发送一次 AUTH 命令来进行用户名密码认证。步骤略显繁琐。

现在，Redis 8.6 支持基于 TLS 证书 Common Name (CN) 的自动认证。管理员只需配置好 tls-auth-clients-user 参数，客户端只要持有正确的证书，一旦连接建立便自动完成身份认证。

证书即身份，这大大简化了密码或令牌的管理工作，对于大规模微服务架构而言，运维复杂度显著降低。

时间序列支持 NaN：数据缺失也能规范标记

在处理时序数据时，经常会遇到某个时间点的数据未能成功采集，但又需要为其占位的情况。过去通常存入 0 或某个特殊值，但这容易与真实的有效数据产生混淆。

Redis 8.6 的时间序列模块正式支持存入 NaN（Not a Number）值，用于明确标记缺失或无效的数据点。同时新增了两个聚合函数：

• COUNTNAN —— 用于统计 NaN 值的个数。
• COUNTALL —— 用于统计所有数据点的个数，包括 NaN 在内。

这使得数据完整性的标记更加标准和规范。

总结与展望

从 8.0 到 8.6，Redis 的进化路线非常清晰：追求极致的性能、增强系统的可靠性、并不断提升易用性。

这次的更新虽然没有所谓的“颠覆性”功能，但每一项改进都精准地切中了生产环境中的常见痛点。无论是高达 5 倍的性能提升、30% 的内存节省，还是消息去重、热键可视化检测，这些特性带来的都是实打实的运维红利和成本优化。

如果你还在使用 Redis 7.x，升级的理由已经非常充分。如果已经在使用 8.x 版本，那么 8.6 绝对值得在测试环境中进行验证。在 AI 应用、实时分析、高频交易等场景中，每一毫秒的延迟和每一兆内存都关乎成本和体验。

升级前，建议务必在测试环境中充分验证。官方提供了 Alpine 和 Debian 镜像、Snap、Brew、RPM、APT 等多种安装方式，方便不同环境的用户进行尝试。