Redis

    The Redis project offers a thorough reference on partitioning as it relates to Redis. See “Partitioning: how to split data among multiple Redis instances”.

    Features of Envoy Redis:

    • codec.

    • Hash-based partitioning.

    • Ketama distribution.

    • Active and passive healthchecking.

    • Hash tagging.

    • Prefix routing.

    • Separate downstream client and upstream server authentication.

    • Request mirroring for all requests or write requests only.

    • Control read requests routing. This only works with Redis Cluster.

    Planned future enhancements:

    • Additional timing stats.

    • Request collapsing for fragmented commands.

    • Replication.

    • Built-in retry.

    • Tracing.

    For filter configuration details, see the Redis proxy filter .

    The corresponding cluster definition should be configured with ring hash load balancing.

    If is desired, the cluster should be configured with a custom health check which configured as a .

    If passive healthchecking is desired, also configure outlier detection.

    For the purposes of passive healthchecking, connect timeouts, command timeouts, and connection close map to 5xx. All other responses from Redis are counted as a success.

    Envoy currently offers experimental support for .

    When using Envoy as a sidecar proxy for a Redis Cluster, the service can use a non-cluster Redis client implemented in any language to connect to the proxy as if it’s a single node Redis instance. The Envoy proxy will keep track of the cluster topology and send commands to the correct Redis node in the cluster according to the spec. Advance features such as reading from replicas can also be added to the Envoy proxy instead of updating redis clients in each language.

    Envoy proxy tracks the topology of the cluster by sending periodic commands to a random node in the cluster, and maintains the following information:

    • List of known nodes.

    • The primaries for each shard.

    • Nodes entering or leaving the cluster.

    For topology configuration details, see the Redis Cluster v3 API reference.

    Every Redis cluster has its own extra statistics tree rooted at cluster.<name>.redis_cluster. with the following statistics:

    Per-cluster command statistics can be enabled via the setting .:

    At the protocol level, pipelines are supported. MULTI (transaction block) is not. Use pipelining wherever possible for the best performance.

    At the command level, Envoy only supports commands that can be reliably hashed to a server. AUTH and PING are the only exceptions. AUTH is processed locally by Envoy if a downstream password has been configured, and no other commands will be processed until authentication is successful when a password has been configured. Envoy will transparently issue AUTH commands upon connecting to upstream servers, if upstream authentication passwords are configured for the cluster. Envoy responds to PING immediately with PONG. Arguments to PING are not allowed. All other supported commands must contain a key. Supported commands are functionally identical to the original Redis command except possibly in failure scenarios.

    For details on each command’s usage see the official Redis command reference.

    If Redis throws an error, we pass that error along as the response to the command. Envoy treats a response from Redis with the error datatype as a normal response and passes it through to the caller.

    Envoy can also generate its own errors in response to the client.

    In the case of MGET, each individual key that cannot be fetched will generate an error response. For example, if we fetch five keys and two of the keys’ backends time out, we would get an error response for each in place of the value.