10 hours ago
- Redis Cluster development started in March 2011, but took nearly 4 years to reach its first Release Candidate (3.0.0-rc1) due to early missteps and shifting priorities.
- The project was initially rushed because scaling was seen as critical, but Redis itself was too immature, leading to repeated pauses to focus on more fundamental features like persistence, replication, and latency.
- The author lacked distributed programming knowledge at the start, resulting in a flawed initial design that was later redesigned after studying the basics.
- Redis Cluster provides data sharding with online resharding and failover, but offers only eventual consistency and limited availability during partitions—it is neither a CP nor an AP system.
- To mitigate divergence, the minority partition becomes unavailable, replication and client replies are sent together, and the least diverging slave is chosen for failover.
- The design sacrifices theoretical guarantees for practical benefits: low overhead, full Redis API support, and no limits on data structure sizes.
- The release candidate is a minimum viable product meant to gain adoption, with future improvements planned: multi-datacenter support, better write safety, automatic node balancing, and a caching mode.
- The author emphasizes that it's time to ship the current version and iterate based on user feedback, rather than delaying further for perfect features.