# Redis 3.0.0 Release Candidate Adds Cluster Support

DevFeed: [Redis 3.0.0 Release Candidate Adds Cluster Support](<https://devfeed.tech/articles/redis-cluster-no-longer-vaporware-20670.md>)

Original publisher: [Read original article](<http://antirez.com/news/79>)

Published: 2014-10-09T14:35:23Z

Content type: release

Language: en

Sources: [Antirez](<https://devfeed.tech/sources/antirez.md>)

Topics: [Redis](<https://devfeed.tech/topics/redis.md>), [Scalability](<https://devfeed.tech/topics/scalability.md>), [Algorithms, Complexity](<https://devfeed.tech/topics/algorithms-complexity.md>)

Tags: [algorithms](<https://devfeed.tech/tags/algorithms.md>), [redis](<https://devfeed.tech/tags/redis.md>), [release](<https://devfeed.tech/tags/release.md>), [replication](<https://devfeed.tech/tags/replication.md>), [scalability](<https://devfeed.tech/tags/scalability.md>)

## AI overview

The article announces the first release candidate of Redis 3.0.0, which adds Cluster support. It explains that development took about four years because the project was repeatedly paused while other Redis features received priority, and that the cluster design was redesigned after further study of distributed programming.

## Source excerpt

The first commit I can find in my git history about Redis Cluster is dated March 29 2011, but it is a "copy and commit" merge: the history of the cluster branch was destroyed since it was a total mess of work-in-progress commits, just to shape the initial idea of API and interactions with the rest of the system. Basically it is a roughly 4 years old project. This is about two thirds the whole history of the Redis project. Yet, it is only today, that I'm releasing a Release Candidate, the first one, of Redis 3.0.0, which is the first version with Cluster support. An erratic run -- To understand why it took so long is straightforward: I started the cluster project with a lot of rush, in a moment where it looked like Redis was going to be totally useless without an automatic way to scale. It was not the right moment to start the Cluster project, simply because Redis itself was too immature, so we didn't yet have a solid "single instance" story to tell. While I did the error of starting a project with the wrong timing, at least I didn't fell in the trap of ignoring the requests arriving from the community, so the project was stopped and stopped an infinite number of times in order to provide more bandwidth to other fundamental features. Persistence, replication, latency, introspection, received a lot more care than cluster, simply because they were more important for the user base. Another limit of the project was that, when I started it, I had no clue whatsoever about distributed programming. I did a first design that was horrible, and managed to capture well only what were the "products" requirement: low latency, linear scalability and small overhead for small clusters. However all the details were wrong, and it was far more complex than it had to be, the algorithms used were unsafe, and so forth. While I was doing small progresses I started to study the basics of distributed programming, redesigned Redis Cluster, and applied the same ideas to the new version of Sentin