Redis
Keeps rate limit counters in redis or another redis-compatible key-value store, shared by every instance of tilegroxy.
| Requires a redis datastore to supply the connection. |
Description
Each counter is a key that expires on its own once its period is over, so no cleanup is needed. Each counter is updated atomically on the server using the server’s clock, so concurrent requests from several instances never lose a count. In cluster mode the counters for one request can live on different servers, which costs a round trip to each of them in parallel.
Also accepts the policies and options shared by every store.
Example
-
YAML
-
JSON
datastores:
- name: redis
id: redis-0
mode: cluster
servers:
- host: redis-0.internal
port: 6379
- host: redis-1.internal
port: 6379
- host: redis-2.internal
port: 6379
ratelimit:
name: redis
datastore: redis-0
policies:
- id: standard
rules:
- segment:
- user
limit: 50
period: 1
{
"datastores": [
{
"name": "redis",
"id": "redis-0",
"mode": "cluster",
"servers": [
{
"host": "redis-0.internal",
"port": 6379
},
{
"host": "redis-1.internal",
"port": 6379
},
{
"host": "redis-2.internal",
"port": 6379
}
]
}
],
"ratelimit": {
"name": "redis",
"datastore": "redis-0",
"policies": [
{
"id": "standard",
"rules": [
{
"segment": [
"user"
],
"limit": 50,
"period": 1
}
]
}
]
}
}
Configuration
| Parameter | Description | Type | Required | Default |
|---|---|---|---|---|
|
The ID of a redis datastore to use |
string |
Yes |
None |
|
A prefix for every key. Changing it resets every counter |
string |
No |
ratelimit: |
Deployment Recommendations
The cluster mode of the datastore should be used for high availability. The ring mode doesn’t replicate, so losing one server resets every counter stored on it.
Configure redis with a maxmemory-policy of noeviction. An evicted key resets the limit for whoever it belonged to. If you use calendar periods of a day or longer, also turn on persistence (AOF) so a restart of redis doesn’t reset everyone’s quota. Replication is asynchronous, so a failover can lose the last few increments.
Use a separate redis cluster for rate limiting and caching so the memory pressure and policies of the two concerns don’t conflict.