@kkfnui #4 有几种吧。1.用法咨询，基本不花时间也不花精力
2. 模型上线失败，原因可能有很多种，要一个一个去排查，每种都要花些时间
3. 失败率突增 /毛刺，SRE 会先查一些普遍的原因，之后会转到我们这边。 这种可能一两天也找不到原因...
4. 用户请求服务报错。 这里面原因也种类特别多，最头疼的是用户代码写的有问题，可能需要看模型的结构，或者用户的代码。 这种基本要连续半天的时间来排查，但是中间会被很多次 2/3 这种线上问题打断。
5. 用户打分对不齐。 这种就更花精力了，一个 case 查一周都是有可能的。 原因种类虽然不多，但是一般会依赖用户配合来排查。 但是我们的用户基本都是做算法的同学，很多做不到 /不愿意 辅助我们排查。
6. 我们依赖很多第三方的基础设施，这些基础设施偶尔会出问题。

@infinityv #1 😂老哥我不是来比惨，是想问这个要怎么调节

@moqimoqide #23 感谢，不过看了下和我的需要不太一样。 我窗口中元素个数其实并不会固定，在请求高峰期和低峰期会差非常多。

@git00ll #21 感谢解答

@edward1987 #19 好的，明白了。 那确实应该没有影响

@rimutuyuan #17 感谢老哥授人以渔，我之后读一读

@godleon #11 感谢回复，虽然和我问的没什么关系😅

@xhinliang #13 感谢，我也看看这个方案

@sunny352787 #12 好的，感谢，我去研究研究😁

@MoYi123 #9 @edward1987 感谢回复。 如果使用方案 2 的话，我这里用一个 list 是合理的吗？ 不太了解 redis 的线程安全问题。 我这里是假定了队列中的元素是会按照时间戳严格单调排列，也就是更新的元素一定在旧的元素的右边。 这个假定是可以保证的嘛？

@sunny352787 #3 感谢老哥提供的关键字，我去搜了下，看到了这个 https://segmentfault.com/a/1190000040570911 其中"计数器"这个方案和我想要的比较类似。 但是差别是，计数器只需要知道一个集合中元素的个数就可以了，我需要知道集合中元素之和。 这个好像要通过写 lua 脚本(?) 之类实现，听说会比较影响性能

@hidemyself #4 感谢回复，用 sorted set 的话的确可以一下子把过期的元素全部删掉，但是 sum 的维护还是要把删掉的元素列表拿出来逐个进行，是吧？

@sunny352787 #1 类似吧，在做一个智能算力的项目，会根据区间和的大小来动态分配算力。

@mrsatangel #104 是无量。carbon 是 rtx 名吗？ 不在了

@RheatiN #106 哈哈哈，我觉得还行，主要是暗色主题不好找

@Allan0423 #10 我也发现了，这个主题还比较新，前一阵还给他们反馈问题来着 。可惜我不太懂前端，不然直接提 PR 了哈哈哈😆

https://111qqz.com/ 最近刚换的，很喜欢这个暗色风格