上班只摸鱼2021-11-01如果我既想做到严格针对用户 ID 的防刷，又不想使用 Redis，该如何实现呢？ 可以使用 用户ID作为key, hash 到同一台nginx服务器进行防刷策略作者回复: 思路是正确的，如果是在nginx的前一层（vip或者还是nginx）做，就是您说的这样，如果是在我们文章中提到的nginx服务做hash，那就可以在后端web服务做防刷，这只是种防刷补充。
共 2 条评论4
qinsi2021-10-15没太明白防刷Token的作用：如果生成Token的信息客户端都知道的话，那么客户端自己就可以生成最后一步的Token，直接调用最后一步的接口；如果生成Token的信息需要从前驱的接口中获取，那么势必就无法跳过对前驱接口的调用，那么也就不需要Token来限制必须要调用前驱接口了。作者回复: 生存token的方式是后端自己定义，对客户端不可见的，如果您发现token被破解，还可以通过在前置步骤中，往redis存入一些关键信息，然后提单时去校验的方式来防止跳步。其实安全对抗一直都是动态变化的。
共 4 条评论
Bold2022-01-26黄牛也能绕过前端页面，通过接口直接获取Token，感觉只是增加几个接口调用，还是会比正常用户快共 1 条评论1- 上班只摸鱼2021-11-01如果我既想做到严格针对用户 ID 的防刷，又不想使用 Redis，该如何实现呢？ 可以使用用户ID作为key 进行hash, 同一个用户ID路由到同一台Nginx服务器进行防刷策略1
一个卖火柴的老男人2021-10-15嗯，很喜欢1
速水御舟2023-06-11 来自河北st 的生成只是简单地将用户 ID+ 步骤编号 那么每次的步骤编号是不是应该加1，应该是记录在某个地方的吧，您里边只是写死了1和2
寒溪2023-04-27 来自上海st 英文全称是什么？共 1 条评论
demo1235672023-03-02 来自重庆挂了代理咋识别呢
Muscleape2022-01-05“但也正因为基于单机，如果黑产将请求频率控制在 1*Nginx 机器数以内，按请求理想散落的情况下，那么就不会被我们抓到” 上面这个没有理解呢，麻烦详细解释一下，谢谢。共 2 条评论