Cloud-native Redis server implemented in Elixir
Cloud-native strong consistent masterless high available Redis implemented in Elixir.
Redex is an attempt to implement a Redis alternative with cloud-native apps in mind.
When running your applications in the cloud, you can easily scale up your app by running
multiple instances of it. Now let’s assume your application uses Redis to cache some frequently
accessed resources or uses its pub/sub features to send events around. What happens when you
scale up your application? If you use Redis as a sidecar container to your app, by scaling up
your app, you will have standalone instances of Redis running, which is very difficult to manage.
Whenever you invalidate a cache entry, you probably want to invalidate it in all instances.
Whenever you publish an event, you most likely want that event being published in all instances.
You might also want your writes to be immediately available in all instances. What if you use atomic
increments/decrements? How can you perform atomic operations across the cluster?
The easiest solution is to run a single instance of Redis so that all instances of your app
communicate with that single Redis instance, but then you will lose the fast-access and low-latency
benefits of running Redis as a sidecar container, and also this single instance of Redis will become a
bottleneck and a single point of failure, preventing scalability and high-availability of your service.
You might also think of setting up a Redis Cluster,
but it has its drawbacks. It is difficult to setup, and it needs at least 3 master nodes
to work as expected, and 3 slaves for high-availability. Furthermore, it is mainly designed for
partitioning/sharding data sets that don’t fit in a single instance or for write-intensive use cases
where a single instance can not handle all the writes, but in most cases, we don’t need partitioning,
what we need is replication.
The official solution to have a replicated cluster of Redis nodes is Redis Sentinel,
but it also has its downsides. You need at least 3 Sentinel instances for a robust deployment,
you need Sentinel support in your clients, you need to do lots of tweaks and scripting
to get it to work in dynamic cluster environments like Kubernetes, and there is no guarantee
that acknowledged writes are retained during failures, since Redis uses asynchronous replication.
Redex came out of the need for a simple Redis solution that can be used just like a single local
Redis instance, while being able to form a replicated cluster once scaled up to multiple instances.
You can use Redex as a sidecar container for your apps/microservices, and easily scale up/down
your app without worrying about data inconsistencies between nodes. Redex is masterless,
clients don’t need to know anything about cluster topology, they can interact with the local
Redex instance just like a single Redis instance, and unlike Redis, write operations are
strong consistent across the cluster.
Of course not. Redex is a solution for use cases where you need a replicated Redis cluster in a
dynamic cluster environment like Kubernetes, without all the hassles of official Redis solutions.
It is well suited for read-intensive use cases within a small cluster where strong consistency is
a requirement, but strong consistency makes write operations gradually slower by adding nodes, hence
Redex is not suitable for write-intensive use cases, nor clusters with a large number of nodes.
Redex does not support all the features and commands that Redis provides, it is only suitable
for data sets that fit into RAM, and it does not support partitioning data over multiple nodes,
nor persisting data to disk.
Redex can be configured using the following env variables:
hostname -i is used to detect node’s IP address.By setting a proper quorum size, you can enforce consistency in netsplits.
In case of a network partition, the partition containing at least the quorum size number
of nodes will remain fully functional, and the other side will become read-only.
Once they are connected again, read-only part will update itself by copying data from the other side.
For benchmarks, we can use Redis official benchmark tool redis-benchmark.
First, make sure you have docker-compose installed,
then inside benchmark folder run the following command:
docker-compose up -d redex redis
This will start a single node of both Redex and Redis.
Now use these commands to run benchmarks for both Redis and Redex:
docker-compose run redis-benchmarkdocker-compose run redex-benchmark
Here is the results on my machine:
# redis-benchmarkSET: 60975.61 requests per secondGET: 61349.69 requests per second# redex-benchmarkSET: 33557.05 requests per secondGET: 41841.00 requests per second
Now lets scale redex to mutiple nodes and run benchmarks again:
REDEX_QUORUM=2 docker-compose up -d --scale redex=2 redexdocker-compose run redex-benchmarkREDEX_QUORUM=2 docker-compose up -d --scale redex=3 redexdocker-compose run redex-benchmarkREDEX_QUORUM=2 docker-compose up -d --scale redex=4 redexdocker-compose run redex-benchmark
Here is the results on my machine:
# redex-benchmark with 2 nodesSET: 1974.72 requests per secondGET: 40650.41 requests per second# redex-benchmark with 3 nodesSET: 1234.72 requests per secondGET: 40816.32 requests per second# redex-benchmark with 4 nodesSET: 996.81 requests per secondGET: 42016.80 requests per second
Of course results would be different if you run each node on a different machine.
For now only a small subset of the commands are supported:
Redex source code is released under Apache 2 License.
Made with 
by @farhadi, supported by Coosto, @coostodev