# redis cluster vs. single instance ## comparing ### cluster data sharding across to multiple nodes, each node control part of hash slot * support higg availability: auto replica ready for failover * avoid single point failure compare to single instance * auto-node discovery: Has built-in support for automatic node discovery. Clients can connect to any node in the cluster, and the cluster will inform them about the current topology. * easy for horizontal scaling by increase hash slot * eventual consistency for latency between nodes * read-write separation: * Redis Cluster supports both read and write operations on any node. However, it allows you to configure certain nodes as read-only, and others as read-write. * This read-write separation can be useful in scenarios where you want to distribute the read workload across multiple nodes while still allowing writes to a subset of nodes. * It's important to note that Redis Cluster operates with eventual consistency, so even if you configure certain nodes as read-only, there might be a brief period during resharding when a node can serve both read and write requests. ### single node * strong consistency for only one instance #### weak * only vertical horizontal by upgrade hardware * single point failure * bottleneck when high data flux * customize read-write separation and shard if needed ## how cluster horizontal scaling by **distributing data across multiple nodes using hash slots** and providing **automatic sharding**. The process of horizontal scaling in Redis Cluster involves adding or removing nodes dynamically. ### Hash Slot Distribution 1. Redis Cluster divides the key space into 16384 hash slots. Each node in the cluster is responsible for a subset of these hash slots. 2. When you add a new node to the cluster, some hash slots are moved from existing nodes to the new node. The redistribution of hash slots is done automatically to balance the data across the nodes. ### resharding when scale up or down When a new node is added, or an existing node is removed, Redis Cluster automatically reshardes the hash slots among the available nodes. The cluster uses a process called "resharding" to move hash slots from one node to another, ensuring an even distribution of data. ### seamlessly scaling up New nodes can be added without interrupting the availability of the cluster. The addition of nodes is a seamless process, and clients can continue to interact with the cluster during this operation. ## how no-down time when cluster scaling up/down * ***moving data with more steps to decrease impact***: When you add a new node to the Redis Cluster, the cluster undergoes an incremental resharding process. **Instead of moving all hash slots at once, the cluster gradually moves a subset of hash slots to the new node.** This incremental approach allows the cluster to balance the load without a significant impact on performance. * ***auto discovery new nodes***: As new nodes are added, clients can continue to interact with the existing nodes, and the cluster will ensure that they are aware of the new nodes without manual reconfiguration * ***Parallel Slot Migration***:During the resharding process, multiple hash slots can be migrated in parallel to the new node. This parallelism helps in completing the resharding operation more efficiently. * ***Graceful Handover***:When removing a node from the Redis Cluster, the cluster initiates a **graceful handover of its hash slots**. Other nodes in the cluster take over the responsibility for the hash slots of the departing node.**This handover ensures that there is no data loss, and the cluster remains in a consistent state.** * ***Data Redundancy by replica***: Redis Cluster maintains data redundancy through replication. If a node is removed, its replicas (if configured) can take over, ensuring data availability during and after the removal process.