alex.dzyoba.com
Redis experience | There is no magic here - Alex Dzyoba
Disclaimer – all of these problems arose from our use case and not because Redis is somewhat flawed. Like any piece of software it requires understanding and research before deployed in any decent production environment. We have a data collecting pipeline with the following requirements: Given our requirements we **started to use Redis cluster from the start**. We chose it over single master/replica because we couldn’t fit our 800M+ keys on a single instance and because Redis cluster provides high availability kinda out of the box (you still need to create the cluster with ``` redis-trib.rb ``` or ``` redis-cli --cluster create ``` ). Also, such beefy nodes are very hard to manage – loading of the dataset would take about an hour, the snapshot would take a long time So, I’ve setup Redis cluster and this time I did it without cross replication because I’ve used Google Cloud instances and because cross replication is very tedious to configure and painful to maintain.
Related Pain Points2件
Redis Cluster management is complex and error-prone
7Managing Redis Cluster at scale involves complex resharding, partition rebalancing, and data coordination. Online migrations and scaling require careful orchestration and are prone to errors, with automation still requiring multiple manual steps and risk of downtime or data inconsistencies.
Large databases on single Redis shard cause slow failover and recovery
7Running large datasets (>25GB or 25K ops/sec per shard) on a single Redis instance means failover, backup, and recovery all take significantly longer. If the instance fails, the entire dataset blast radius and recovery time are unacceptable for production systems.