[nahname]

The master/replica setup is interesting because we did something similar at Shopify, but I don't believe this is conventional for redis cluster. Can you expand on that a bit? eg: Looks like master/replica are together on a host, wouldn't you want them spread out?

You are including proxies for clients and server? How do they compare to envoy? eg: Are you doing anything clever to handle failovers transparently for clients?

Is the metadata storage just using redis?

[doyoubi]

I have to admit the diagram is a bit misleading.

The core idea here is called chunk: https://github.com/doyoubi/undermoon/blob/master/docs/chunk....

Each proxy always runs in front of 2 Redis instances. Each chunk consists of 2 proxies and thus 4 Redis instances on 2 different physical servers. And each Redis has its master/replica on another half part under another proxy inside the chunk. So master and replica are always not in the same physical server. Chunk is the smallest building block of a cluster so the Redis instances number is always a multiple of 4.

We designed it in this way because we came up with an algorithm to balance the overall workload based on this chunk structure: https://github.com/doyoubi/undermoon/blob/master/docs/chunk_...

For the second question, the proxy here is just a way to add additional features on the top of Redis without changing its source code. I would say it's a server-side proxy while envoy focuses on the client-side features.

And yes, it can handle failover transparently for clients.

In Kubernetes, the metadata is stored inside a ConfigMap, which is based on etcd.