看你的寻找是什么逻辑.

有一个办法是, 先放进缓存里, 过一小段时间再去处理

缓存的 key 就是 time, 弄一个 set 结构, time -> [(ip1, value1), (ip2, value2)]

紧接着, 再搞一个定时任务, 捞出当前时间 - 5 分钟 (这得看 time 的粒度)所有记录, 分别计算 time 对应的 maxValue

最后, 用的时候直接取最后算的结果就行. 这里主要要考虑所需数据的时效和接收消息的延迟问题, 比如当前是 0 分钟, 你在第一分钟需要第 0 分钟的最大值, 但是第二分钟又来了一条第 0 分钟的数据怎么办?

@Jooooooooo 感谢大佬回复，完全理解了我问题的痛点，我目前的思路和你说的基本一致， 目前我有存一份全量数据在 MongoDB 中，想着从这份数据中定时查询当前时间- n 分钟中的 max value ip, 因为数据量比较大，查询速度有待测试，可能放在 Redis 里查比较好。
最大值是为了推到监控中，所以时效性还是要求比较高的，这个 n 分钟具体数值目前也不太能确定。

在这之前我有考虑过将所有数据接收后都传到一个专门的处理程序里，对相同（ ip ，time ）的 value 进行取最大值的操作，这个程序对同一（ ip ，time ）的处理设置一个超时时间，超过两分钟就认为没有其他数据了，直接将最大值推送至监控。
如果这样做的话感觉写起来比较困难，需要对记录进行轮询（不知道有没有更好的处理手段），处理数据的时间有可能会很长反而更影响时效性

@chi1st 如果你是为了加工数据做后续监控的话, 分钟级别的粒度应该够了. 因为监控是为了告警后续再人工解决的话, 基本上时间瓶颈不会在监控这一两分钟上, 一般都是人响应慢或者处理太慢导致问题解决时间长.

可以考虑在第 1 分 15 秒的时候去处理第 0 到第 1 分钟的数据(留有数据入库的延迟). 加工完成之后就获得了第 0 分钟的数据(加工时间应该不会超过 10s), 那么正常情况下在第 1 分 30 秒的时候就具有第 0 分钟的数据, 可以从此时去做监控相关的内容(比如捞出前 5 分钟加工好的数据, 看波动之类的指标是否有异常). 有异常则发出告警. 监控的延迟可以认为是 2 分钟以内发现问题.