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

Redis TS.CREATERULE 怎样对齐聚合时间桶

来源:17golang原创

时间:2026-10-29 15:49:53 378浏览 收藏

我第一次把 RedisTimeSeries 的原始采样压成日报时,最容易误判的不是 AVG,而是“这一天到底从几点开始”。TS.CREATERULE 默认按 Unix epoch 对齐,桶宽只是重复周期;如果业务日从别的时间点开始,就要把那个边界换算成 Unix 毫秒交给 alignTimestamp。

一句话结论:使用 TS.CREATERULE source dest AGGREGATION aggregator bucketDuration alignTimestamp,其中 bucketDuration 和 alignTimestamp 都是毫秒;alignTimestamp 指定一个桶的起点,后续桶按固定宽度重复。Redis 官方地址:https://redis.io/docs/latest/commands/ts.createrule/

本文只解决持续压缩规则的时间桶对齐。TS.RANGE 查询时的 ALIGN 是另一个读取参数,不会修改已经创建的规则。

先把两个 ALIGN 问题分开

写入链路里,TS.CREATERULE 把源序列的新样本聚合到目标序列;alignTimestamp 决定目标桶的固定参考点。读取链路里,TS.RANGE ... ALIGN 只在本次查询中重新定义聚合桶的参考时间。一个负责长期生成压缩序列,一个负责临时查看结果,不能互相替代。

目标键必须在创建规则前存在,规则创建后才写入源序列的样本才会参与压缩;已经存在的历史样本不会因为补建规则而自动回填。

alignTimestamp 怎样对齐到业务时间

alignTimestamp 是 Unix 时间戳毫秒,不是“每天几点”的字符串。桶起点可以理解为:

桶起点 = alignTimestamp + n × bucketDuration

例如 24 小时桶的宽度是 86400000。官方示例用 epoch 后 6 小时的 21600000 作为参考点,就得到从 06:00 开始的日桶。若业务边界是东八区本地午夜,应先把该边界换算为 Unix 毫秒;不能直接把“8”或“00:00”塞进参数。对于每天重复的边界,关键是它相对于一天的毫秒余数。

Redis TS.CREATERULE 中源序列、桶宽、alignTimestamp 与时间桶起点的关系说明图
图1:时间桶对齐说明图,查看桶宽与毫秒参考点的静态关系;这是原创结构图,不是运行截图。

用一个日报规则落地

下面示例把温度源序列按 24 小时做平均。示例把 57600000 作为一个重复的毫秒参考余数,表达东八区本地午夜对应的 UTC 边界;生产代码应由统一的时间函数计算边界,不要手写容易误读的常量。

# 先创建源序列和目标序列;目标键必须先存在
redis-cli 

这里的花括号是集群 hash tag,让源键和目标键落在同一 hash slot;单机 Redis 不需要它,但保留这种命名方式便于以后迁移。若不需要按时区偏移,只想按 Unix epoch 对齐,可以省略最后一个参数,默认参考点就是 0。

空桶、最新部分桶和查询核对

规则不会为了“补齐日历”凭空生成空桶:一个桶内没有源样本,就没有对应的压缩样本。另一个常见误会是当天还没结束时,最新桶可能仍是部分桶;它通常在新样本打开下一个桶后才完全闭合。若报表需要看到当前部分桶,读取目标序列时可以使用 LATEST。

# 读取已经闭合的日桶;- 和 + 表示最早到最新时间戳
redis-cli TS.RANGE sensor:{room-a}:daily - +

# 需要把最新的部分桶也带出来时,显式使用 LATEST
redis-cli TS.RANGE sensor:{room-a}:daily - + LATEST
Redis 压缩规则中已闭合桶、空桶、最新部分桶与 TS.RANGE LATEST 的关系说明图
图2:压缩与查询边界说明图,查看空桶和最新部分桶的关系;这是原创结构图,不是运行截图。

如果只是临时把一次查询按某个参考点重聚合,可以在源序列上使用 TS.RANGE key from to ALIGN align AGGREGATION avg bucketDuration。这个 ALIGN 只改变本次读取的桶边界,不会改写由 TS.CREATERULE 生成的目标序列。

我的排查清单

遇到日报跨天、结果为空或最后一桶缺失时,我会按这个顺序看:一是确认目标序列确实先创建;二是确认时间戳是毫秒而不是秒;三是把业务边界换算成 Unix 毫秒再填 alignTimestamp;四是确认规则创建后源序列确实收到新样本;五是区分空桶和最新部分桶;六是集群下检查源、目标键是否使用相同 hash tag。

适合长期报表、设备指标和固定周期监控的场景,优先创建明确对齐的目标序列;只想临时换一个统计窗口,则用 TS.RANGE 的查询端 ALIGN,不要重复创建压缩规则。

常见问题

alignTimestamp 能直接填本地小时数吗?不能。它是 Unix 毫秒;本地时间要先转换为绝对时间戳,再考虑每天重复边界的余数。

创建规则后为什么旧数据没有日报?规则只聚合创建后写入源序列的新样本,历史数据需要单独的回填方案。

为什么目标序列没有每一个自然日?空桶默认不产生压缩样本;最新桶也可能尚未闭合,读取当前部分结果时加 LATEST。

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