redis实现訪问频次限制的几种方式 模式:Rate limiter
结合上一篇文章《redis在学生抢房应用中的实践小结》中提及的用redis实现DDOS设计时遇到的expire的坑。事实上,redis官网中对incr命令的介绍中已经有关于怎样用redis来做rate limit的探讨。
这里将实现的两种模式翻译一下,并适当加了一些批注说明。原文可见官网。
频次限制器模式是一种特殊的计数器,它常被用来限制某个操作能够被运行的频次。
这个模式的实质事实上是限制对一个公共API运行訪问请求的次数限制。我们使用incr
命令提供该模式的两种实现。这里我们假设须要解决的问题是:对每一个IP。限制对某API的调用次数最高位10次每秒。
模式:Rate limiter 1
对该模式一个相对简单和直接的实现,请见例如以下代码:
FUNCTION LIMIT_API_CALL(ip)
ts = CURRENT_UNIX_TIME()
keyname = ip+":"+ts
current = GET(keyname)
IF current != NULL AND current > 10 THEN
ERROR "too many requests per second"
ELSE
MULTI
INCR(keyname,1)
EXPIRE(keyname,10)
EXEC
PERFORM_API_CALL()
END
简单来说。我们对每一个IP的每一秒
都有一个计数器,但每一个计数器都有一个额外的设置:它们都将被设置一个10秒的过期时间。这能够使得当时间已经不是当前秒时(此时该计数器也无效了)。能够让redis自己主动移除它。
须要注意的是,这里我们使用multi
和exec
命令来确保对每一个API调用既运行了incr
也同一时候能够运行expire
命令。
multi命令用于标识一个命令集被包括在一个事务块中,exec保证该事务块命令集运行的原子性。
模式:Rate limiter 2
另外的一种实现是採用单一的计数器,可是为了避免race condition
(竞态条件),它也更复杂。我们来看几种不同的变体:
FUNCTION LIMIT_API_CALL(ip):
current = GET(ip)
IF current != NULL AND current > 10 THEN
ERROR "too many requests per second"
ELSE
value = INCR(ip)
IF value == 1 THEN
EXPIRE(value,1)
END
PERFORM_API_CALL()
END
该计数器在当前秒内第一次请求被运行时创建,但它仅仅能存活一秒。假设在当前秒内,发送超过10次请求。那么该计数器将超过10。
否则它将失效并从0開始又一次计数。
在上面的代码中,存在一个race condition。假设由于某个原因。上面的代码仅仅运行了incr
命令,却没有运行expire
命令,那么这个key将会被泄漏,直到我们再次遇到同样的ip(备注,假设这里没有辅助的删除该key的措施,那么该key将永只是期,也将每次都错误发生,详情可见本人之前一篇文章)。
这样的问题也不难处理,能够将incr
命令以及另外的expire
命令打包到一个lua脚本里。该脚本能够用eval
命令提交给redis运行(该方式仅仅在redis版本号大于等于2.6之后才干支持)。
local current
current = redis.call("incr",KEYS[1])
if tonumber(current) == 1 then
redis.call("expire",KEYS[1],1)
end
当然。也有还有一种方式来解决问题而不须要动用lua脚本。但须要用redis的list数据结构来替代计数器。
这样的实现方式将会更复杂。并使用更高级的特性。
但它有一个优点是记住调用当前API的每一个client的IP。这样的方式可能非常实用也可能没用,这取决于应用需求。
FUNCTION LIMIT_API_CALL(ip)
current = LLEN(ip)
IF current > 10 THEN
ERROR "too many requests per second"
ELSE
IF EXISTS(ip) == FALSE
MULTI
RPUSH(ip,ip)
EXPIRE(ip,1)
EXEC
ELSE
RPUSHX(ip,ip)
END
PERFORM_API_CALL()
END
rpushx
命令仅仅在key存在时才会将值增加list
仍然须要注意的是,这里也存在一个race condition(但这却不会产生太大的影响)。问题是:exists
可能返回false
,但在我们运行multi/exec
块内的创建list的代码之前,该list可能已被其它client创建。然而,在这个race condition发生时。将仅仅仅仅是丢失一个API调用,所以rate limiting仍然工作得非常好。
这里产生race condition不会有大问题的解决办法在于,else分支使用的rpushx,它不会导致if not than init的问题。而且expire命令将在创建list的时候以原子的形式捆绑运行。
不会产生key泄漏。导致永不失效的情况产生。
很多其它内容请訪问:http://vinoyang.com