我在想redis的timeseries规则创建是如何工作的，我很困惑为什么redis忽略了聚合中的最后一项，并想知道这是否是预期的行为。
我在中创建了一个示例代码 redis-cli 举例说明：
127.0.0.1:6379> FLUSHALLOK127.0.0.1:6379> TS.CREATE sourceOK127.0.0.1:6379> TS.CREATE sumRuleOK127.0.0.1:6379> TS.CREATERULE source sumRule AGGREGATION sum 1OK127.0.0.1:6379> TS.ADD source * 1(integer) 1592638841406127.0.0.1:6379> TS.ADD source * 2(integer) 1592638843446127.0.0.1:6379> TS.ADD source * 3(integer) 1592638846536127.0.0.1:6379> TS.ADD source * 4(integer) 1592638849085127.0.0.1:6379> TS.GET sumRule1) (integer) 15926388465362) 3
我希望最后一项是4而不是3。这是预期的行为，因为它需要向后看才能进行聚合吗？或者它是否需要多个值来进行聚合？
1条答案
按热度按时间cuxqih211#
感谢您尝试redistimeseries。
我们来分析一下到底发生了什么，然后我来解释原因。创建规则时，需要指定2个参数：聚合类型和bucket size(这里需要注意的一点是，bucket大小的单位是毫秒，而不是秒）
一旦你有了一个规则，每一个被添加的样本都会被用来计算当前的聚合值，一旦bucket上下文结束，我们就会将值刷新到downsampled键。我们怎么知道bucket上下文结束了？如果您有一个5秒的bucket，我们将保持上下文打开，直到得到一个超出5秒范围的示例。
为什么你只看到前一个桶？原因有二：
这是一个优化，以避免打开下采样键和写入样本（重写样本是一个cpu密集型操作，因为我们压缩了数据结构以将数据保留在内存中）
api—我们不希望返回部分存储桶，以避免显示“飞行中”数据。
我希望这能回答你的问题。