Redis, as an in-memory database with excellent performance, supports the 100-million-level social platform of Weibo and has become the standard of many Internet companies. Here will take Redis Cluster Cluster as the core, based on the latest Redis5 version, from the principle to the actual combat, play Redis Cluster

Common Redis cluster solutions

Before introducing the Redis Cluster solution, in order to facilitate comparison, we first briefly understand the common Redis Cluster solution in the industry:

1 Based on client fragments

Redis Sharding is a multi-Redis instance Cluster method commonly used in the industry before The emergence of Redis Cluster. The main idea is based on hash algorithm, according to the hash value of key of Redis data, the data is segmented and mapped to their respective nodes

The advantage is that the implementation is simple, but the disadvantage is that when the Redis cluster is adjusted, each client needs to be updated and adjusted

2 Fragment based on the proxy server

The client sends the request to the standalone deployment broker component, which parses the client’s data, forwards the request to the correct node, and finally returns the result to the client

Advantages of transparent access, easy cluster expansion, disadvantage of a layer of proxy forwarding, performance loss

3 Redis Sentinel

Redis Sentinel is a high availability solution officially provided from Redis version 2.6. Sentinel cluster is added to monitor the entire Redis cluster based on the master/slave replication cluster. When the Master node of Redis cluster fails, Sentinel performs failover and elects a new master. Meanwhile, Sentinel itself supports high availability cluster deployment

The advantage is that it supports cluster high availability and high performance read and write, while the disadvantage is that there is no data sharding, and each node needs to carry complete data sets. The load capacity is limited by a Redis server, so it only supports vertical expansion by increasing machine memory, but does not support horizontal expansion

Redis Cluster design

1 Overall design

Redis Cluster is a high availability Cluster solution officially launched in version 3.0. Compared with Redis Sentinel, Redis Cluster solution does not require additional deployment of Sentinel Cluster, but realizes Cluster monitoring through internal Cluster communication, and switches between master and slave in case of failure. At the same time, it supports internal data sharding based on hash and dynamic horizontal expansion

The overall structure is as follows:

A cluster has multiple primary nodes, and each primary node has multiple secondary nodes. Data between the primary and secondary nodes is consistent. At least three primary nodes are required, and each primary node requires at least one secondary node

  • High availability: When the master node is faulty, a primary/secondary switchover is automatically performed
  • High performance: The primary node provides read/write services, while the secondary node provides read-only services, improving system throughput
  • Scalability: Data in a cluster is stored in fragments. Data on primary nodes is different, and data on primary nodes is maintained separately. You can add nodes to the cluster for capacity expansion, or remove some nodes for capacity reduction

2 Data Fragments

The whole data set is distributed to multiple nodes according to certain rules, which is called data sharding. The sharding scheme adopted by Redis Cluster is hash sharding

The basic principle is as follows: The Redis Cluster defines an interval from 0 to 16383, called slots. All keys are mapped to integer slots from 0 to 16383 based on the hash function. Slot =CRC16 (key) &16383. Each node is responsible for maintaining a portion of slots and the key data mapped to the slots

A slot is the basic unit of Redis cluster management data. Cluster expansion and contraction refers to the movement of slots and data between nodes

The mapping between slots and nodes is as follows:

  • Each cluster node maintains a bit array of 16384 bits (2kB). Each bit corresponds to a slot with the same number. 0/1 indicates whether it owns a slot
  • Cluster nodes also maintain a slot-to-cluster node mapping, which consists of arrays of length 16384, array subscripts representing slot numbers, and node information

3 Cluster Capacity Expansion

The Redis Cluster can be dynamically expanded or scaled down without affecting external services of the Cluster. When a new Redis node is added to the existing Cluster, it needs to migrate slots and data for the new node to ensure that each node is responsible for a similar number of slots to evenly distribute data on all nodes

The entire data migration involves a number of operations. Redis provides cluster management tools, including Redis – Trib.rb, which is based on Ruby, and Redis – CLI, which is new to Redis5. This section uses Redis – CLI as an example

The source node migrates data from the specified slot to the target node. The basic process is as follows:

  • (1) Redis-CLI sets target nodes to specify slot state importing, so that target nodes are prepared to import slot data
  • (2) Redis – CLI sets the status of slot migrating on the source node to prepare for migrating data from the slot
  • (3) Redis – CLI batch migrates data in the specified slot on the source node to the target node
  • (4) After data migration, redis-CLI notifies all primary nodes of the cluster that the slot is allocated to the target node, and the primary node updates the slot-node mapping information

Typically, if the data requested by the client is not on the node, the node will reply with the MOVED redirection message, and the client will request the correct node based on that information. For slot data that is being migrated, the following design ensures that clients can still access it:

  • (1) The mapping between slots and nodes is updated only after the migration is complete. If the mapping information during the migration remains the same as before the migration
  • (2) If the client accesses the source node and the key is not migrated out, the key is processed normally
  • (3) If the client accesses the source node, the key accessed has been migrated out, and the source node returns the ASK redirection information
  • (4) The client extracts the target node information according to the ASK redirection anomaly, sends the ASKING command to the target node first to request operation, and then executes the key command

The two redirection controls, ASK and MOVED, differ as follows:

  • ASK redirection indicates that the cluster is migrating slot data, and the client cannot know when the migration is complete. Therefore, the redirection is only temporary, and the client does not update the cache mapped from slot to Redis node.
  • MOVED Redirection indicates that the slot corresponding to the key has been explicitly assigned to a new node, so the mapping cache of the slot to the Redis node needs to be updated

4 CAP trade-off

CAP includes Consistency, Availability, and Partition tolerance. If the system fails to achieve data Consistency within the time limit, it means that Partition has happened and it must choose between C and A

Redis Cluster chooses AP architecture. In order to ensure availability, Redis does not guarantee strong consistency. Data inconsistency and even lost write operations may occur under certain conditions

The first reason is that to balance performance and consistency, data synchronization between the master node and slave node is asynchronously replicated. When the client successfully writes data to the master node, the master returns success, and the master node asynchronously copies the data to the slave node

Another reason is that when the cluster sends network partitions, the cluster may be divided into two parts: majority and minority. If the masterA node is in minority, if the network partition has occurred for a short time, then the cluster will continue to function normally. If the partition is long enough for the majority to elect a new master to replace matsterA, the data written to masterA during the partition is lost

During a network partition, there is a maximum time limit for which clients can send write commands to matsterA. This time limit is called cluster-node-timeout and is an important configuration option for Redis clusters

conclusion

So far, the principle of Redis Cluster is introduced here, in fact, there are Cluster communication protocol, memory, data backup, master/slave replication and other features worth learning, is a model of distributed system design, have the opportunity to expand the introduction

Next “actual combat”, introduce Redis Cluster actual combat

reference

Weibo redis practice mp.weixin.qq.com/s/dBWIHwfmr 6 years…

Redis. IO /topics/clus… Redis. IO/switchable viewer/clus…