Redis 8.6 正式发布：性能狂飙、Streams 增强与运维体验进化

Redis 8.6 正式发布！新版本不仅在性能压榨和资源利用率上取得了突破，还带来了一系列让日常「开发 + 运维」更加丝滑的功能更新。

从 Streams 的数据安全护盾，到更精细的「内存淘汰」策略；从可视化的 Hotkey 追踪，到更简便的 TLS 认证，外加更灵活的「时间序列」处理——Redis 8.6 是一次全方位的进化。

Redis 8.6 新特性深度解析

1. Streams：至多一次生产保证

Redis 8.6 引入了幂等生产机制，为 Streams 带来了「至多一次」的生产语义。这意味着，即使多次尝试向 Stream 添加同一条消息，其最终效果也等同于「只添加一次」。

为什么需要这个保证？

想象一个外卖订单系统：每条订单消息会被多个消费者组处理——厨房（备餐）、库存系统（补货）、配送公司（物流）、财务（记账）等。如果同一条订单被重复写入 Stream，就可能导致重复扣款、库存错误甚至业务混乱。

在 Redis 8.6 之前，若生产者调用XADD 后、尚未收到 Redis 回复时发生了连接中断，就会陷入两难境地：无法确定消息是否已经成功写入。这种情况通常出现在两种场景中：

1. 连接在XADD执行后、回复返回之前断开；
2. 生产者在调用XADD后崩溃，未能收到响应，也无法标记消息为「已投递」。

为了避免消息丢失，生产者往往选择重试。但在缺乏幂等机制时，这种重试会导致「消息重复」。而有了 Redis 8.6 的幂等支持，即便在网络闪断或进程崩溃后重发，也能确保消息「至多只被添加一次」。

为什么 Entry ID 不能作为幂等 ID？

在命令 XADD key .. <id|*> field value ... 中，每条消息都有一个 Entry ID（格式如timestamp-seq，或由 Redis 自动生成）。Entry ID 必须严格单调递增。

在单生产者场景下，生成单调 ID 并不困难；但在多生产者环境中，协调生成全局单调 ID 几乎不可行。因此，多数应用只能使用自动生成 ID（即 *）。

• 问题在于：自动生成的 Entry ID 只在XADD的响应中返回。如果生产者没收到响应，就无法知道该 ID 是什么，自然也无法用相同 ID 重发。于是，每次重试都会生成新 ID，Redis 也就无法识别这是重复消息。
• 简单来说，我们需要一种机制，让（多个）生产者能以幂等方式向 Stream 写入消息：即使多次调用XADD发送相同内容，Redis 也能识别并去重。这一保证必须在网络中断、重连乃至生产者崩溃恢复等极端情况下依然有效。

引入幂等 ID

实现「至多一次」语义，需要 Redis 与生产者协同工作。从 Redis 8.6 开始，生产者可为每条消息关联一个唯一的幂等 ID：

XADD key … [<IDMP pid iid> | <IDMPAUTO pid>] … <*|id> field value [field value …]

目前支持两种指定方式：

1. IDMP pid iid：生产者需提供一个唯一的生产者 ID（pid） 和一个唯一的消息 ID（iid）。iid可以是本地计数器（每个生产者独立维护）、业务中的唯一标识（如交易 ID），或 UUID。
2. IDMPAUTO pid：生产者仅需提供pid，Redis 会基于消息内容自动生成iid。

核心原则是：重复消息必须使用相同的(pid, iid)组合。因此，应用需确保：

• pid在每个生产者实例中唯一，且在重启后保持不变；
• iid在同一pid下对每条消息唯一，并在重发时保持一致。

当执行XADD时，Redis 会检查(pid, iid)是否已在近期记录中存在。若存在，则判定为重复消息，拒绝写入 Stream，并返回此前分配的 Entry ID。

幂等配置与内存管理

为了检测重复消息，Redis 需为每个pid缓存最近使用的iid。但缓存过多会占用内存，甚至拖慢XADD性能。因此，合理配置去重窗口至关重要。

为此，Redis 8.6 新增了XCFGSET命令，用于调整 Stream 的幂等参数：

XCFGSET key [IDMP-DURATION duration] [IDMP-MAXSIZE maxsize]

每次调用XCFGSET更新参数时，Redis 会清空该 Key 当前的幂等映射表（即丢弃所有已追踪的pid和iid）。每个 Stream 关联两个关键参数：

• maxsize：Redis 为每个pid保留的最近iid的最大数量；
• duration：每个iid的保留时长（单位：秒）。（注意：即使未超时，Redis 也不会保留超过maxsize个iid。）

如何设置 Duration？

• duration 本质上是一种运维承诺：在此时间窗口内，Redis 不会主动丢弃已记录的iid（除非达到maxsize上限）。建议根据生产者从崩溃到恢复并开始重发消息所需的「最大预估时间」来设定。
• 例如：若生产者最多需 1000 秒完成恢复并重试，则duration应设为 1000。设得过高会浪费内存。

如何设置 Maxsize？

通常，生产者在收到XADD响应后，会将消息标记为「已投递」或从本地事务日志中清除。崩溃恢复时，只会重发未确认的消息——这正是幂等机制发挥作用的场景。

maxsize的设定取决于从收到XADD响应到本地完成标记的时间差（称为mark-delay）。

推荐公式：maxsize = mark-delay（毫秒） × 单生产者发送速率（msg/ms） + 冗余量。

• 例如：生产者速率为 1000 msg/sec（即 1 msg/ms），标记延迟为 80ms，则maxsize建议设为 1 × 80 + 冗余 ≈ 100。

此外，Redis 8.6 还引入了两个全局默认配置：

• stream-idmp-duration：全局默认的幂等保留时长（秒）；
• stream-idmp-maxsize：全局默认的幂等缓存上限。

2. 新驱逐策略：LRM（最近最少修改）

Redis 的驱逐策略决定了内存达到上限时如何释放空间。除了经典的allkeys-lru（适用于纯缓存场景）和volatile-lru（保留无过期时间的 Key），Redis 8.6 新增了两种基于「最近最少修改」（Least-Recently Modified, LRM）的策略：volatile-lrm和allkeys-lrm。

与传统的 LRU（Least Recently Used）相比，两者的核心区别在于「活跃度」的更新逻辑：

• LRU：无论是读操作还是写操作，都会刷新 Key 的活跃时间戳；
• LRM：只有写操作才会刷新 Key 的活跃度，读操作则完全不影响。

何时使用 LRM 策略？

当某些 Key 被高频读取，但其数据内容早已不再更新时，LRU 会因持续的读取行为而将其长期保留在内存中。而 LRM 则能识别出这些「只读不写」的 Key，并优先将其驱逐。

典型适用场景包括：

• 场景 1：静态缓存响应 某些缓存由上游服务一次性写入后便不再更新，但用户仍会反复读取（例如历史公告、旧版配置）。使用 LRM 可让这些「冻结」数据在内存紧张时被自动清理。
• 场景 2：定期聚合数据 如每日统计指标，每天凌晨生成一次新值，旧数据不再修改。即便旧数据仍被查询，LRM 也能确保它们在后续聚合周期中被合理淘汰。
• 场景 3：分层缓存架构 假设你同时维护两类缓存：一类是短 TTL（如 1 小时）的热点数据，另一类是长 TTL（如 7 天）但写入后永不修改的语义缓存。若使用 LRU，后者可能因高频读取而长期驻留内存；而 LRM 则能无视读取频率，优先释放那些「久未修改」的长生命周期 Key，从而为真正活跃的数据腾出空间。

3. 探测与报告 Hotkeys

热点 Key（Hot Keys）是指那些因数据结构复杂或访问模式特殊，导致「资源消耗不成比例」的 Key——无论是 CPU 还是网络带宽。

单个 Redis 节点过载，往往并非源于整体请求量过大，而是少数几个热点 Key 吞噬了绝大部分系统资源。虽然 Redis 8.4 引入了 Atomic Slot Migration 来均衡 Slot 负载，但如果一个 Slot 内部由某个热点 Key 主导，迁移整个 Slot 只是把问题从一个节点「搬运」到另一个节点，并未真正解决瓶颈。因此，我们需要「Key 级别」的精细观测能力。

为此，Redis 8.6 引入了全新的热点 Key 探测机制，可对指定 Hash Slot 范围内的 Key 进行资源消耗统计与排名。命令格式如下：

HOTKEYS START<METRICS count[CPU][NET]>[COUNT k][DURATION duration][SAMPLE ratio][SLOTS count slot…]

该命令启动资源采样收集。Redis 会为每个启用的指标维护一个 Top-k 的热点 Key 列表：

• CPU：追踪消耗 CPU 时间最多的 Key；
• NET：追踪网络带宽占用最高的 Key。

你可以通过SLOTS参数限定监控范围（例如只关注特定 Slot），也可以随时使用HOTKEYS GET获取当前的热点报告。

性能与准确性的权衡

HOTKEYS的采样过程本身会带来一定开销。为了降低影响，可以通过SAMPLE参数控制采样率——例如设为 100，表示每 100 个命令采样 1 次。该机制基于概率化的「Top-k 数据结构」，虽然可能存在微小偏差，但对日常诊断、故障排查和容量规划来说，其精度已经完全足够。

4. 基于 TLS 证书的自动客户端认证

此前，即便启用了 mTLS（双向 TLS 认证），客户端在完成 TLS 握手后，仍需通过AUTH命令进行应用层的身份验证。

• Redis 8.6 引入了新的tls-auth-clients-user配置项 。启用该功能后（例如设为CN），Redis 会自动从客户端证书中提取通用名称（Common Name, CN），并将其直接映射为对应的 ACL 用户名。
• 如果该 ACL 用户被配置为nopass（无需密码），那么客户端在 TLS 握手成功后即被视为已通过认证。这就意味着「证书本身即身份凭证」，彻底省去了 ACL 密码的管理、分发与轮换等运维负担，大幅简化了安全架构。

5. Time Series：支持 NaN 值

Redis 的 Time Series 数据结构广泛应用于金融场景（如股价、汇率等）。在 8.6 之前，Time Series 要求所有样本必须是有效的浮点数，明确禁止插入 NaN（Not a Number）。

为了满足实际业务中对「缺失数据」标记的需求，Redis 8.6 现在允许在 Time Series 中「显式插入 NaN 值」，用于表示「不可用」或「暂无数据」的状态，便于后续回填或分析。

具体支持如下：

• TS.ADD和TS.MADD命令现已接受NaN作为输入值；
• 所有现有聚合器（如COUNT、MIN、MAX、SUM）会自动忽略 NaN 值，确保统计结果不受干扰；
• 新增两个专用聚合器：
  • countNaN：统计指定时间范围内 NaN 值的数量；
  • countAll：统计所有样本数量，包括有效数值和 NaN。

立即体验 Redis 8.6

你可以立即下载 Redis 8.6，在现有工作流中体验这些新命令与机制带来的效率提升与运维简化。