When the memory capacity of a Redis becomes larger and larger, we need to expand the Redis. The first solution that comes to mind is to choose a cloud host with more memory to deploy Redis. But this approach has two drawbacks:

  • The memory capacity of a cloud host cannot be expanded indefinitely
  • Large memory on a single machine causes large persistent RDB files and slow fault recovery.
  • The Redis fork child process takes longer to persist the RDB and blocks the main thread, resulting in slower Redis responses.

Hence, the sliced Cluster Redis Cluster.

After data segmentation, we need to solve two problems:

  • After the data is sliced, how is the data distributed among multiple instances?
  • How does the client determine which data it wants to access?

Redis Cluster uses Hash Slot to handle mapping between data and instances. A slice cluster has 16,384 Hash slots, similar to the concept of data partitions. The mapping is divided into two steps:

  • Key-value pair Key Computes a 16-bit value according to CRC16 algorithm.
  • If the module is 16384, the hash slot corresponding to the module is found.

When deploying a Redis Cluster, you can run the Cluster create command to create a Cluster. In this case, Redis instances are automatically allocated evenly to hash slots for Cluster instances. So there are N instances and 16384 slots allocated.

You can also use the Cluster meet to manually establish connections between instances. Cluster addslots Specifies the number of Hash slots for the instance. Note that 16384 hash slots must be allocated manually; otherwise, the Redis cluster cannot work properly.

How does the client locate which instance of the data?

After the client establishes a connection with the cluster instance, the instance sends hash slot allocation information to the client, which is cached locally by the client. If hash Slot information is changed, for example:

  • Cluster instances have been added or deleted, and Redis Hash slot has been reassigned
  • Redis needs to redistribute hash slots for load balancing

Redis Cluster provides a redirection mechanism to resolve inconsistencies between client Hash slot information and instance nodes. If the request is sent to an instance, the instance does not have a hash slot for the key-value pair. The instance returns a MOVED command to the client with the correct address. The client requests again and gets the results, updating the local cache.

In addition, if hash slot is being migrated between nodes, the returned address may be a new address or an old address. At this time, the Redis instance will return the ASK command. After receiving the address returned by ASK, the client will try to send the ASKING command to the corresponding node to obtain data. Unlike the MOVED command, the ASK command does not update the client cache hash slot allocation information.