使用 Redis 解决接口被刷问题

标签: redis 接口 问题 | 发表时间:2011-07-19 12:53 | 作者:ChinarenWei Jason
出处:http://chinaren.wei.blog.163.com
问题背景
Web 上,凡是有价值的接口页面、接口,在利益的驱动下,总有被犯罪分子刷的可能;

对方少数几个 IP 还好说,直接封 IP 了事,要是人家有肉鸡,有几千几万的 PC 资源,源源不断,封 IP 即便是自动检测自动封 IP 仍然是显的乏力,被欺负心里很不爽。

解决办法
其实很简单,在处理每个请求前,先检测下这个 IP 是否是恶意攻击的 IP,如果是直接返回个不知所云的页面给对方就好了。

要判断是否是恶意攻击的 IP,我们需要记录每个 IP 每一次请求的时间,如果在 xx 秒内,访问量超过 yy 值,则判定为恶意攻击的 IP。
这里要几个问题:
  • 由于每个接口请求,都要记录下 IP 和 请求时间,这个记录动作必须非常快,不能卡住,否则会影响整个服务。
  • 这些记录的 Log 数据量非常大,但真正对我们有效的也就是最近 xx 秒内的数据,所以要有个机制自动删除无用的记录以节省空间。
  • 判断是否是恶意攻击的 IP 这个逻辑要求有比较高的效率。

采用 Redis 来解决问题
  • 对于每个请求,IP + timestamp 为 Key,在 Redis 里面建立一个计数器;相同 IP 相同时间每访问一次,该计数器加 1
  • 给 Key 设置个有效期,如 5 分钟,5 分钟后,Redis 自动删除过期数据释放空间。
  • 如我们设定,5秒内超过20次,即判定为恶意 IP。对于每个请求,通过 IP + timestamp 取最近的 5 秒所对应 Key 的计数器的值,然后累加,看是否看过限额即可;如果超过限额,则将以该 IP 为 Key,存入 Redis 中,超时设置为 5 分钟,这样就形成了最近被封的 IP 列表。每次请求,都判断当前 IP 是否在这个列表,如果在这个列表,直接封掉。
  • 效率问题,Redis 保证,这个不用担心。

相关 [redis 接口 问题] 推荐:

使用 Redis 解决接口被刷问题

- Jason - 偶有所得,记录在此
Web 上,凡是有价值的接口页面、接口,在利益的驱动下,总有被犯罪分子刷的可能;. 对方少数几个 IP 还好说,直接封 IP 了事,要是人家有肉鸡,有几千几万的 PC 资源,源源不断,封 IP 即便是自动检测自动封 IP 仍然是显的乏力,被欺负心里很不爽. 其实很简单,在处理每个请求前,先检测下这个 IP 是否是恶意攻击的 IP,如果是直接返回个不知所云的页面给对方就好了.

redis 性能问题查找

- - 开源软件 - ITeye博客
          使用redis作为数据库时,系统出现少量超时,通过日志信息发现,超时发生在bgsave时. bgsave命令会fork一个子进程,子进程会将redis数据库信息dump到rdb文件中. 因此不能确定使用bgsave命令时,是fork一个子进程引起超时,还是dump文件时与主进程的sync同步同时写磁盘引起的超时.

redis超时问题分析

- - 搜索技术博客-淘宝
Redis在分布式应用中占据着越来越重要的地位,短短的几万行代码,实现了一个高性能的数据存储服务. 最近dump中心的cm8集群出现过几次redis超时的情况,但是查看redis机器的相关内存都没有发现内存不够,或者内存发生交换的情况,查看redis源码之后,发现在某些情况下redis会出现超时的状况,相关细节如下.

Redis数据“丢失”问题

- - 今天
Redis大部分应用场景是纯缓存服务,请求后端有Primary Storage的组件,如MySQL,HBase;请求Redis的键未命中,会从primary Storage中获取数据返回,同时更新Redis缓存. 如果少量数据丢失,相当于请求”缓冲未命中“; 一般对业务的影响是无感知的. 但现在Redis用作存储的业务场景变多,数据丢失对业务是致命的影响.

Redis集群“倾斜”问题

- - 今天
对分布式存储系统的架构和运维管理,如何保证每个Node的数据存储容量和请求量尽量均衡,是非常重要的. 本文介绍Redis大集群运维过程中,常见导致数据和请求量“倾斜”的场景,及规避措施. Redis数据容量或请求量严重”倾斜”的影响. 以下从运维的角度解释,Redis数十节点的集群,出现数据容量和请求量倾斜情况下,存在的一些痛点:.

Redis响应延迟问题排查

- - searchdatabase
  本文将有助于你找出Redis 响应延迟的问题所在.   文中出现的延迟(latency)均指从客户端发出一条命令到客户端接受到该命令的反馈所用的最长响应时间. Reids通常处理(命令的)时间非常的慢,大概在次微妙范围内,但也有更长的情况出现.   如果你正在经历响应延迟问题,你或许能够根据应用程序的具体情况算出它的延迟响应时间,或者你的延迟问题非常明显,宏观看来,一目了然.

Redis时延问题分析及应对

- - 博客 - 伯乐在线
Redis的事件循环在一个线程中处理,作为一个单线程程序,重要的是要保证事件处理的时延短,这样,事件循环中的后续任务才不会阻塞;. 当redis的数据量达到一定级别后(比如20G),阻塞操作对性能的影响尤为严重;. 下面我们总结下在redis中有哪些耗时的场景及应对方法;. keys、sort等命令.

  导致Redis超时(Timeouts)常见问题

- - 移动开发 - ITeye博客
因实际应用中出现经常 Redis 超时问题,StackExchange.Redis 在 Github 上 Timeouts 一文从多个方面进行分析,并提供相应的解决方案, 为方便日后再次出现该问题时快速查阅,特写下本文作为技术笔记,同时给英文不太好的程序员(媛)提供参考,帮助大家更好的学习redis http://www.maiziedu.com/course/337/.

linux下redis执行bgsave时,报overcommit_memory错误问题

- - 博学无忧
一台机器如果内存用完,在进行bgsave时,可能会报错. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.

Redis性能问题排查-slowlog和排队延时

- - 今天
1 Redis slowlog不完全可靠. 希望对大家排查Redis性能问题时有所帮助. [Redis Slowlog]是排查性能问题关键监控指标. 它是记录Redis queries运行时间超时特定阀值的系统. 这类慢查询命令被保存到Redis服务器的一个定长队列,最多保存slowlog-max-len(默认128)个慢查询命令.