KeyDB: A Multithreaded Redis Fork
What we are doing instead: just started a Redis Proxy project (designed by Fabio and me, coded by Fabio Nicotra, so we started yesterday). We will start abstracting a Redis Cluster this way so that you can talk with to it like it was a single instance, but this is not enough. We also are planning for:<p>1. Tooling to make it simpler to start a Redis Cluster in a single host if all you want is to leverage all the cores.<p>2. Smartness in the AOF rewriting so that instances on the same host will do a better use of the disk.<p>3. A caching mode for Redis Cluster. This is useful for deployments where most accesses are idempotent and you have for instance a cluster of 10 physical hosts running, for instance, 32 Redis instances each. When an host is no longer reachable we don&#x27;t want failover in that case, but just reassignment of hash slots to the other masters. Think at consistent hashing but on the server side.<p>Two years ago I had this private branch that I wrote in a few days that threaded Redis, with N event loops on N threads. After realizing that it worked and scaled, I considered how many bugs such Redis would have, how harder it would be to add features, and how incompatible is to have a single huge instance with Redis persistence method. In that moment and after consulting with other engineers I decided that for a few years our strategy will be Redis Cluster. Maybe I&#x27;ll change idea in the future? Maybe, but first let&#x27;s explore what can be done with a shared-nothing architecture that keeps the promise of continuing to deliver software that hardly crashes ever.<p>EDIT: Obviously the proxy itself is multithreaded :-D<p>EDIT2: Btw jdsully already sent a PR to the original Redis project, so I guess a smart developer exposed to the Redis core is great anyway!