





















假设有恶意程序写一个简单的循环,持续访问不存在的 topic id ,那么每次 V2EX 接收到这样的请求,还需要从数据库里查了之后,才知道是无效的 topic id ,这个查询过程就会很浪费资源。
所以程序中有这样的一种机制,如果 topic id 明显大于某个值,那么就不用查任何数据库资源,直接返回 404 。
这个值应该是被定期更新并且加上一个足够大的安全值。
但是由于最近测试服里的一个 bug ,导致这个值自从测试服上线之后,就一直没有被正确更新。因此当 topic id 持续增长,终于来到旧值 + 安全值的边界时,所有新的 topic id 就都 404 跳转了。
这个问题的根源是测试服上更新全站统计数据进 Memcached Key 时的 bug ,这个 bug 现在已经修复(测试服在这个地方现在使用了单独的 Memcached Key )。
3 povsister 5 月 26 日我这类似用途是靠 id 算法,全局时间+safe margin 搞的。通过当前时间+id 编码规则就能很容易初步判定 id 是不是伪造的。后面被枚举刷太狠了就又在回源套了层布隆,也是时间校验,安全值范围内允许回源否则一律拦截。 最开始考虑过全局通过有状态存储维护这个上限,但组件太多依赖一个单点就很麻烦。 |
4 Pipecraft 5 月 26 日那现在已经公开秘密了,这个机制似乎不能防止恶意程序了。 |
5 ByteRan 5 月 26 日有点像千年虫的 BUG |
9 itechify 5 月 26 日哈哈哈哈哈,这也能宕机一天。历史遗留的 feature ,堆积的临时性代码,可以考虑做下减法了🤣 |
10 tty0 5 月 26 日可不可以将 ID 改为编码? |
11 JoeJoeJoe 5 月 26 日 via iPhone哈哈哈哈 这是有历史沉淀的站点才能出现的问题😂 |
12 Tink 5 月 26 日这个机制感觉可以考虑用别的算法替代掉 |
13 GeorgeV 5 月 26 日v 站的这个 feature 很有趣,时不时来一下也蛮好的 |
15 CEBBCAT 5 月 27 日> 假设有恶意程序写一个简单的循环,持续访问不存在的 topic id 听起来似乎是判定逻辑直接使用了缓存中存储的 topic count 作为 max id ?也许可以在新发帖时主动向 Cache 推送 max id ,记得使用 CAS 原子操作 BTW Livid 你最后一段似乎语序有些模糊,是这个 bug 让你措手不及吗?注意休息 |
17 tf2 5 月 27 日这个 idea 其实很好。不过可以做得细致一点 故意设置一些不存在的但是红线主题 id 谁访问,封谁的 IP |
18 diudiuu 5 月 27 日挺好的这个想法 |
19 yougg 5 月 27 日可以通过 ULID 或者 UUID v7 判断时间戳 |
20 ovtfkw 5 月 27 日缓存穿透吗,但是现在的主题 id 都是线性增加的,很容易被猜到把,那直接恶意大量访问已经存在的主题呢 |
21 8888888888 5 月 27 日开始还以为是在治理那些中转站或者疑似广告贴,后来发现新帖全 404 |
22 yelog 5 月 27 日这个场景感觉使用缓存比较好,max_topic_id 在新增帖子的更新一下缓存。查询帖子判断大于这个 max_topic_id 就 404 。 |
23 keyfunc 5 月 27 日可以对 ID 额外增加校验位,校验失败就不去查数据库了。 |
24 rrubick 5 月 27 日 via iPhone但是,有的帖子当时是有新增回复的,也就是有人是可以打开的,这又是为啥? |
26 dudu2017 5 月 27 日 |
28 CEBBCAT 5 月 27 日 via iPhone@ryd994 make sense ,想的是既然存了就维护好这个数据,不然以后如果复用没注意到竟态可能会造成别的问题,但如果存的时候写明白,应该也行 |
31 mywaiting 5 月 27 日从我过去的维护经验来说,最好把基础定义 API 和反垃圾 AntiSpam 的实现分离比较好 一来可以保证 AntiSpam 不会影响基础 API 运行,二来方便在 AntiSpam 执行各种试验 大概过程如下: 所有流量从 gateway 进入到 webapp 后会有系列分离/分流机制推送到 AntiSpam 离线检测,检测后会自动标识 IP/User/Fingerprint 等标识的风险值,然后反馈到 webapp gateway 自动拉黑/喂假数据 举个例子:正常访问的流量都会访问 /favicon.ico 这个请求进入 gateway 后会推送到 AntiSpam 离线检测后会适当降低当前访问 IP 的风险值 |
34 dode 5 月 29 日所有还是搞一个位运算服务吧,查询性能更好 |
35 dode 5 月 29 日redis ID 自增 读取和查询性能怎么样 |
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。