The Redis protocol support allows APISIX to proxy Redis commands, and provide various features according to the content of the commands, including:
- Redis protocol codec
- Fault injection according to the commands and key
This feature requires APISIX to be run on APISIX-Base.
It also requires the data sent from clients are well-formed and sane. Therefore, it should only be used in deployments where both the downstream and upstream are trusted.
#Granularity of the request
Like other protocols based on the xRPC framework, the Redis implementation here also has the concept of
Each Redis command is considered a request. However, the message subscribed from the server won't be considered a request.
For example, when a Redis client subscribes to channel
foo and receives the message
bar, then it unsubscribes the
foo channel, there are two requests:
subscribe foo and
|faults||array[object]||False||Fault injections which can be applied based on the commands and keys|
Fields under an entry of
|commands||array[string]||True||["get", "mget"]||Commands fault is restricted to|
|key||string||False||"blahblah"||Key fault is restricted to|
|delay||number||True||0.1||Duration of the delay in seconds|
Assumed the APISIX is proxying TCP on port
9101, and the Redis is listening on port
Let's create a Stream Route:
curl http://127.0.0.1:9080/apisix/admin/stream_routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
"commands": ["get", "ping"],
Once you have configured the stream route, as shown above, you can make a request to it:
redis-cli -p 9101
You can notice that there is a 5 seconds delay for the ping command.