redis incr命令

命令格式:INCR key

存储在key中的数字值加1。如果key不存在,key的值先被设置为0,然后再执行加1操作。如果key包含一个错误类型的值或者不能表示为整数的字符串,返回错误。 本操作的值有效范围限制64位有符号整数表示的范围。

注意: 这是一个字符串操作,因为Redis没有专门的整数类型。存储在key中的字符串被转换为10进制有符号整数,在此基础上加1。

Redis 存储整数在它们的整数表示里, 所以对实际存储整数的字符串值,并没有负担来存储字符串表示整数。


整数应答Integer reply: key存储的value自增之后值


redis>  SET mykey “10”


redis>  INCR mykey

(integer) 11

redis>  GET mykey


*模式: 计数器

计数器模式是最明显的使用Redis原子自增能做的事情。办法是简单的发送INCR 命令给Redis每操作一次的时候。例如,在一个web应用中我们可能想知道用户每天浏览了多少页面。

To do so the web application may simply increment a key every time the user performs a page view, creating the key name concatenating the User ID and a string representing the current date.

This simple pattern can be extended in many ways:

  • It is possible to use INCR and EXPIRE together at every page view to have a counter counting only the latest N page views separated by less than the specified amount of seconds.
  • A client may use GETSET in order to atomically get the current counter value and reset it to zero.
  • Using other atomic increment/decrement commands like DECR or INCRBY it is possible to handle values that may get bigger or smaller depending on the operations performed by the user. Imagine for instance the score of different users in an online game.

*Pattern: 频率限制器Rate limiter

The rate limiter pattern is a special counter that is used to limit the rate at which an operation can be performed. The classical materialization of this pattern involves limiting the number of requests that can be performed against a public API.

We provide two implementations of this pattern using INCR, where we assume that the problem to solve is limiting the number of API calls to a maximum of ten requests per second per IP address.

*Pattern: 频率限制器 1

The more simple and direct implementation of this pattern is the following:

keyname = ip+":"+ts
current = GET(keyname)
IF current != NULL AND current > 10 THEN
    ERROR "too many requests per second"

Basically we have a counter for every IP, for every different second. But this counters are always incremented setting an expire of 10 seconds so that they’ll be removed by Redis automatically when the current second is a different one.

Note the used of MULTI and EXEC in order to make sure that we’ll both increment and set the expire at every API call.

*Pattern: 频率限制器 2

An alternative implementation uses a single counter, but is a bit more complex to get it right without race conditions. We’ll examine different variants.

current = GET(ip)
IF current != NULL AND current > 10 THEN
    ERROR "too many requests per second"
    value = INCR(ip)
    IF value == 1 THEN

The counter is created in a way that it only will survive one second, starting from the first request performed in the current second. If there are more than 10 requests in the same second the counter will reach a value greater than 10, otherwise it will expire and start again from 0.

In the above code there is a race condition. If for some reason the client performs the INCR command but does not perform the EXPIRE the key will be leaked until we’ll see the same IP address again.

This can be fixed easily turning the INCR with optional EXPIRE into a Lua script that is send using the EVAL command (only available since Redis version 2.6).

local current
current ="incr",KEYS[1])
if tonumber(current) == 1 then"expire",KEYS[1],1)

There is a different way to fix this issue without using scripting, but using Redis lists instead of counters. The implementation is more complex and uses more advanced features but has the advantage of remembering the IP addresses of the clients currently performing an API call, that may be useful or not depending on the application.

current = LLEN(ip)
IF current > 10 THEN
    ERROR "too many requests per second"
    IF EXISTS(ip) == FALSE

The RPUSHX command only pushes the element if the key already exists.

Note that we have a race here, but it is not a problem: EXISTS may return false but the key may be created by another client before we create it inside the MULTI / EXEC block. However this race will just miss an API call under rare conditions, so the rate limiting will still work correctly.