接口防刷
接原文:https://www.fengpt.cn/archives/%E5%8D%9A%E5%AE%A2%E8%AF%84%E8%AE%BA%E6%8E%A5%E5%8F%A3%E8%A2%AB%E6%81%B6%E6%84%8F%E5%88%B7%E8%AF%84%E8%AE%BA%E9%97%AE%E9%A2%98%E8%AE%B0%E5%BD%95 写了这篇接口防刷记录后,面试中后续也和某司的大佬讨论了一下这个问题,给我带来了许多新的思路。
限流以及限制关键字缺点
因为站小人少,所以我们加了一些简单的策略。如上文所示在nginx中编写一些固定的拦截规则,在动态性的就是通过网关写成一些可配置型的规则。如IP或者是固定的昵称、评论内容等规则。这样有一些缺陷,如有些用户不能访问,在如专业的黑客有个很大的IP池我们是拦截不了的,这样就会给我们的使用带给了很大的困扰。
防刷优化
后续讨论了如何优化这个流程,参考过淘宝双十一抢购的经验,首先想到的是,当某个ip一段时间内访问过量,则弹出个验证码,当用户一段时间内访问过量则弹出个验证码弹框。这样做的缺点是会打击一些用户的积极性,让一些真正想评论我们的用户不评论了。再次讨论了一个比较好的想法就是在用户量比较大的情况下引入大数据组件保存用户历史轨迹,根据历史轨迹来判断一个评论request是否是有效的,所以现在的流程是这样的。
后续一些思路
现在只是单纯的参考用户的历史轨迹去做一些规则判断,如果我们的一个用户被盗号,或者有一些历史常用的用户和一些新来陌生的用户他们可能同时访问,我们的规则还是会打消他们评论的积极性,所以可以根据历史数据以及最近的数据相加得到一个活性池类似的东西,根据每个用户活性池的强度来给用户弹出弹框。
评论区