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.
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.