帆帆 发表于 2026-5-26 23:19:04

20260526 - 关于已经修复的 404 bug 的具体原因

假设有恶意程序写一个简单的循环，持续访问不存在的 topic id ，那么每次 chlt 接收到这样的请求，还需要从数据库里查了之后，才知道是无效的 topic id ，这个查询过程就会很浪费资源。

所以程序中有这样的一种机制，如果 topic id 明显大于某个值，那么就不用查任何数据库资源，直接返回 404 。

这个值应该是被定期更新并且加上一个足够大的安全值。

但是由于最近测试服里的一个 bug ，导致这个值自从测试服上线之后，就一直没有被正确更新。因此当 topic id 持续增长，终于来到旧值 + 安全值的边界时，所有新的 topic id 就都 404 跳转了。

这个问题的根源是测试服上更新全站统计数据进 Memcached Key 时的 bug ，这个 bug 现在已经修复（测试服在这个地方现在使用了单独的 Memcached Key ）。

Aven 发表于 2026-5-26 23:19:07

没想到竟然是一个这样简单的问题..

酒神 发表于 2026-5-26 23:56:04

我这类似用途是靠 id 算法，全局时间+safe margin 搞的。通过当前时间+id 编码规则就能很容易初步判定 id 是不是伪造的。后面被枚举刷太狠了就又在回源套了层布隆，也是时间校验，安全值范围内允许回源否则一律拦截。

最开始考虑过全局通过有状态存储维护这个上限，但组件太多依赖一个单点就很麻烦。

小鹿酱 发表于 2026-5-27 00:20:05

哈哈哈哈哈，这也能宕机一天。历史遗留的 feature ，堆积的临时性代码，可以考虑做下减法了🤣

吴先生 发表于 2026-5-27 00:39:38

可不可以将 ID 改为编码?
先校验自定义编码是否有效, 有效再去查询数据库.

shp123 发表于 2026-5-27 00:50:06

有点像千年虫的 BUG

1923622620 发表于 2026-5-27 01:01:04

哈哈哈哈 这是有历史沉淀的站点才能出现的问题😂

gp500198 发表于 2026-5-27 01:11:03

这个机制感觉可以考虑用别的算法替代掉

Vall 发表于 2026-5-27 01:13:04

现在应该有更好的方法了吧

苏格拉 发表于 2026-5-27 01:26:34

尘站的这个 feature 很有趣，时不时来一下也蛮好的
页: [1]
查看完整版本: 20260526 - 关于已经修复的 404 bug 的具体原因