@ryd994 #7 感谢老哥的回复。 我这里说的用户是指其他业务部门的研发同事。1. 用法咨询我们一直有 wiki 的其实，但是 wiki 内容太多了，得看个一两天。目前的做法是还是要接单子，然后帮用户分析他的需要是什么，再帮他路由到对应的 wiki 条目。 2. 我们是推荐场景，线上有上千个服务，模型上线基本时半个小时-40 分钟一次。 尤其有很多对实时性敏感的场景(比如新闻推荐), 模型上线失败对业务效果影响非常大。
3. 失败率这个还算比较紧急，因为会影响我们整个部门的考核。
4. 这个我们也尝试过，比如训练任务经常出现的一个问题是 OOM ，有其他同事写了一个特别详细的“OOM 问题排查指引”。 但是发现由于用户基本都是算法研究同学，他们对这些系统 /工程 一些的问题基本看了 wiki 也不知道如何排查。对内存 /cpu 这些的理解和普通人差不太多。

5. 这个问题的痛点主要是，我们缺少一些"自证清白"的途径。 我们负责的部分基本属于整个调用链的最下游，所以需要排除上游的这些问题。 如果拒不配合到也好说，最担心的是遇到过用户一口咬定"模型训练代码，数据都没有修改过，突然服务就报错了"。 可能最后查了一周，发现用户的模型代码都变了，于是问用户，结果被回答"我以为这两种模型结构是等价的，不算修改"😅

6. 我们木有客服组，其他设施出了问题大部分是研发在和他们对接。

老板其实也知道单子多，也一直在想办法降低数量。 好在老板不太会给额外的压力，就是 OnCall 下来确实头痛得不行

@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/ 最近刚换的，很喜欢这个暗色风格