登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  数据库 >  Redis

Redis TS.DELETERULE 为什么不会删除目标时间序列

来源:17golang原创

时间:2026-10-30 14:08:58 354浏览 收藏

如果执行 TS.DELETERULE sourceKey destKey 后,目标时间序列仍然能被查询到,这通常不是命令失效,而是把“删除压缩规则”和“删除时间序列 key”混成了两个动作。TS.DELETERULE 只移除源序列上的 compaction rule,不会删除 destKey,也不会清空目标序列已经保存的历史样本。

官方文档:https://redis.io/docs/latest/commands/ts.deleterule/

要点速览
  • sourceKey 是源时间序列,destKey 是被聚合写入的目标时间序列,参数方向不能写反。
  • 规则删除成功返回 OK;目标 key 仍存在,只能说明数据对象还在,不能据此判断规则仍在。
  • 要清理目标序列,需要另外使用时间序列删除命令;在集群中还要让两个 key 落在同一 hash slot。

TS.DELETERULE 删除的到底是什么

TS.CREATERULE 建立的是一条压缩规则:源序列接收新样本后,按聚合函数和桶宽把结果写入目标序列。这个关系包含三个不同对象:源时间序列、规则元数据和目标时间序列。TS.DELETERULE 删除的是中间的规则元数据,不是两端的 key。

Redis 时间序列压缩规则与目标时间序列职责分离结构图
图1:源序列、规则元数据和目标序列的职责分离说明图,历史样本仍在并不代表规则仍在。

因此,删除后出现下面的结果是正常的:目标序列可以继续被 TS.RANGE 查询,过去已经生成的聚合点不会自动消失,源序列也不会被删除。只要没有新的规则,后续写入源序列就不应再通过这条规则生成新的目标样本。

用正确的 key 方向移除规则

最常见的错误是把目标序列当成第一个参数。判断方向时不要看变量名,要回到创建规则时的命令:创建时的第一个 key 就是删除时的 sourceKey,第二个 key 就是 destKey。

# 先删除 source:temperature 到 agg:temperature 的压缩规则
redis-cli TS.DELETERULE source:temperature agg:temperature

# 删除规则后,目标序列仍可作为一个独立 key 查询历史聚合点
redis-cli TS.RANGE agg:temperature - +
动作影响对象目标序列是否自动消失
TS.DELETERULE source dest源序列上的压缩规则不会
TS.RANGE dest - +读取目标序列样本不会
删除目标时间序列的命令目标 key 与其中的数据按删除动作处理

如果命令返回“规则不存在”,通常有三种可能:规则之前已经被删除、两个参数顺序写反,或者当前连接的 Redis 实例并不是创建规则的那一组数据。不要因为目标 key 还存在就重复执行同一条命令。

用 TS.INFO 判断规则是否真的移除

不要用目标序列是否存在作为判断条件。更可靠的做法是分别查看两个 key 的元数据:源序列的 rules 列表表示它当前挂着哪些压缩规则;目标序列的 sourceKey 表示它是否作为某条压缩规则的目标。

# 查看源序列是否仍列出目标压缩规则
redis-cli TS.INFO source:temperature

# 查看目标序列的来源关系;目标 key 仍存在不等于规则仍存在
redis-cli TS.INFO agg:temperature

排查时重点看这几个字段:源序列的 rules 中是否还有 agg:temperature;目标序列的 sourceKey 是否仍指向源序列;规则条目中的桶宽和聚合函数是否与创建时一致。删除成功后,规则关系消失,但目标序列的历史样本和自身配置仍然可以保留。

Redis TS.INFO sourceKey 与 rules 诊断字段关系图
图2:TS.INFO 诊断字段和时间序列生命周期的静态关系图,不是命令运行截图。

Redis Cluster 还要检查 hash slot

TS.CREATERULE 和 TS.DELETERULE 都同时涉及源 key 与目标 key。Redis 官方文档提示,在集群环境中应使用 hash tag 让两者落入同一个 hash slot,否则规则操作或后续压缩可能出现跨 slot 问题。

# 用相同的 hash tag,让两个时间序列进入同一 slot
redis-cli TS.CREATE ts:{device-7}:raw LABELS device 7
redis-cli TS.CREATE ts:{device-7}:hour LABELS device 7

# 创建和删除时必须保持 source、dest 的方向一致
redis-cli TS.CREATERULE ts:{device-7}:raw ts:{device-7}:hour AGGREGATION avg 3600000
redis-cli TS.DELETERULE ts:{device-7}:raw ts:{device-7}:hour

这里的大括号不是装饰,而是 Redis Cluster 的 hash tag 语法。生产环境如果使用不同的 key 前缀,仍要保留同一段 tag;如果只是在单机 Redis 或代理已经完成路由的环境中使用,也要以实际部署方式确认多 key 命令的路由边界。

保留数据还是清理数据,要分开做决定

如果目标序列中的历史聚合结果还要用于报表、回溯或对账,只执行 TS.DELETERULE,让数据停止继续更新即可。如果目标序列只是临时产物,确认没有读取方后,再单独删除目标 key。这样可以把“停止生成新数据”和“清理旧数据”分成两个可回滚、可审计的动作。

常见问题

为什么 TS.DELETERULE 返回 OK,但目标时间序列还在?

因为命令成功删除的是压缩规则。目标时间序列是独立的数据对象,历史样本不会随规则删除而自动清空。

删除规则后,目标序列还会继续产生新样本吗?

这条规则不应再生成新样本;但其他规则、业务代码直接写入目标 key,或之前已经排队的外部写入,仍可能改变目标序列,需要结合 TS.INFO 和写入路径排查。

参数顺序写反会怎样?

Redis 会按“源序列、目标序列”解释参数。若对应关系不存在,通常返回规则不存在或参数错误;不要通过删除目标 key 来替代修正参数。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>