Redis High Availability technical solution Summary

I. Common usage

Several common usage methods of redis include:

• Redis single copy;

• Redis multi-copy (Master/Slave );

• Redis sentinel (Sentinel );

• Redis cluster;

• Self-developed redis.

Ii. Advantages and disadvantages of various usage methods

1. redis single copy

Apsaradb for redis uses a single redis node deployment architecture. It does not have slave nodes to synchronize data in real time and does not provide data persistence and backup policies. This architecture is suitable for pure cache business scenarios with low data reliability requirements.

Advantages:

• Simple architecture and convenient deployment;

• Cost-effective: No standby node is required for Cache Usage (Single Instance availability can be ensured by a supervisor or crontab). Of course, to ensure high service availability, you can sacrifice a slave node, however, at the same time, only one instance provides external services;

• High performance.

Disadvantages:

• Data reliability is not guaranteed;

• When cache is used and the process is restarted, data is lost. Even if there are slave nodes to solve high availability, the cache push problem still cannot be solved, so it is not applicable to businesses with high data reliability requirements;

• High performance is limited by the processing capacity of single-core CPUs (redis is a single-thread mechanism), and the CPU is the main bottleneck, so it is suitable for scenarios with simple operation commands and few sorting and computing. You can also consider using memcached instead.

2. redis multi-copy (Master/Slave)

Redis has multiple replicas and adopts a master-slave (replication) deployment structure. Compared with a single copy, redis features real-time data synchronization between master and slave instances and provides data persistence and backup policies. The Master/Slave instances are deployed on different physical servers. Based on the company's Basic Environment configuration, the Master/Slave instances can simultaneously provide external services and read/write splitting policies.

Advantages:

• High reliability: on the one hand, the dual-host Master/Slave architecture can automatically switch between the master and slave databases when the master database fails. The slave database can be upgraded to provide services for the master database to ensure smooth service operation. On the other hand, enabling data persistence and configuring reasonable backup policies can effectively solve data misoperations and abnormal data loss problems;

• Read/write splitting policy: slave nodes can expand the read capability of the master database node to effectively cope with large concurrent read operations.

Disadvantages:

• Fault recovery is complex. If there is no redisha System (development required), when the master database node fails, you must manually promote a slave node to the master node, and notify the business party to change the configuration, other slave database nodes need to be copied to the new master database node. human intervention is required throughout the process, which is cumbersome;

• The write capability of the master database is limited by a single machine. You can consider sharding;

• The storage capacity of the master database is limited by a single machine. You can consider pika;

• The disadvantages of native replication are also prominent in earlier versions. For example, after redis replication is interrupted, slave will initiate psync. If synchronization fails, full synchronization will be performed, when full backup is performed on the master database, the system may slow down in milliseconds or seconds. In addition, due to the cow mechanism, the master database memory overflows in extreme cases and the program exits abnormally or goes down; when a backup file is generated on the master database node, the server disk Io and CPU (compression) resources are consumed. When a backup file of several GB is sent, the server egress bandwidth increases rapidly and requests are blocked. We recommend that you upgrade it to the latest version.

3. redis sentinel (Sentinel)

Redis Sentinel is a native high-availability solution launched by the Community version. Its deployment architecture mainly includes two parts: redis sentinel cluster and redis data cluster.

Redis sentinel cluster is a distributed cluster composed of several sentinel nodes, which can realize fault discovery, automatic failover, configuration center and client notification. The number of redis sentinel nodes must be an odd number of 2n + 1 (n> = 1.

Advantages:

• Simple deployment of redis sentinel clusters;

• It can solve the high-availability switching problem in redis master-slave mode;

• It is easy to achieve linear expansion of redis data nodes and easily break through redis's own single-thread bottleneck, which can greatly meet redis's large-capacity or high-performance business needs;

• A set of sentinel nodes can be used to monitor a group of redis data nodes or multiple groups of data nodes.

Disadvantages:

• The deployment is more complex than the redis master-slave mode, and the principle understanding is more complicated;

• Resources are wasted. The slave node in the redis data node does not provide services as a backup node;

• Redis Sentinel is mainly used for high-availability switching of the master node in redis data nodes. The failure Determination of redis data nodes can be divided into subjective offline and objective offline, the slave node of redis performs subjective deprecation on the node without performing failover.

• Read/write splitting cannot be solved, and the implementation is relatively complicated.

Suggestion:

• If you monitor the same service, you can select a sentinel cluster to monitor multiple groups of redis data nodes. Otherwise, you can select a sentinel cluster to monitor a group of redis data nodes.

• In sentinel Monitor <master-Name> <ip> <port> <quorum> Configuration, we recommend that you set half of the sentinel node to 1, when Sentinel is deployed in multiple IDCs, the number of sentinel deployed in a single IDC cannot exceed (Sentinel quantity-quorum ).

• Properly set parameters to prevent miscutting and control switch sensitivity control:

  A. Quorum

  B. Down-after-milliseconds 30000

  C. Failover-Timeout 180000

  D. maxclient

  E. Timeout

• The time of each deployed node server should be synchronized whenever possible, otherwise the log timing will be chaotic.

• Redis recommends using pipeline and multi-keys to reduce the number of RTTs and improve request efficiency.

• The configuration Center (zookeeper) is self-configured to facilitate client access to the instance link.

4. redis Cluster

Redis cluster is a Community version of The redis distributed cluster solution, mainly to solve the redis distributed needs, for example, when a single machine memory, concurrency and traffic bottlenecks, redis cluster can play a good role in load balancing.

A redis cluster node can have at least six nodes (three master nodes and three slave nodes). The master node provides read and write operations, and the slave node acts as the slave node. It does not provide requests and is only used for failover.

Redis cluster uses virtual slot partitions, and all keys are mapped to 0 ~ Based on the hash function ~ In the 16383 integer slots, each node maintains key-value data of some slots and ing of the slots.

Advantages:

• Non-central architecture;

• Data is stored in multiple nodes according to the slot, and data is shared among nodes. The data distribution can be dynamically adjusted;

• Scalability: It can be linearly expanded to more than 1000 nodes, and nodes can be dynamically added or deleted;

• High Availability: the cluster is still available when some nodes are unavailable. By adding slave as a standby data copy, the fault can be automatically failover, the status information is exchanged between nodes through the gossip protocol, and the role of slave to master can be upgraded using the voting mechanism;

• Reduces O & M costs and improves system scalability and availability.

Disadvantages:

• The client implementation is complex, and the driver must implement Smart Client, cache slots mapping information and update it in a timely manner, which increases the development difficulty. The immature client affects the business stability. Currently, only jediscluster is relatively mature and exception handling is not complete, for example, the common "Max redirect exception ".

• The node will be blocked for some reason (the blocking time is later than clutser-node-timeout) and is determined to be offline. This failover is unnecessary.

• Asynchronous replication does not guarantee strong data consistency.

• When multiple businesses use the same cluster, the cold and hot data cannot be distinguished based on statistics, and the resource isolation is poor, which is prone to mutual impact.

• Slave acts as a "Cold Standby" in the cluster, which does not relieve the read pressure. Of course, you can improve the utilization of slave resources through proper SDK design.

• Key batch operation restrictions. For example, using mset or mget currently only supports keys with the same slot value for batch operation. Keys mapped to different slot values do not support cross-slot queries. Therefore, operations such as mset, mget, and sunion are not supported.

• Key transaction operations are limited. Only transaction operations with multiple keys on the same node are supported. Transaction functions cannot be used when multiple keys are distributed on different nodes.

• As the minimum granularity of Data partitions, a key value object such as hash and list cannot be mapped to different nodes.

• Multi-database space is not supported. redis in a single machine can support up to 16 databases. In cluster mode, only one database space can be used, that is, db 0.

• The replication structure only supports one layer, and slave nodes can only replicate the master node. The nested tree replication structure is not supported.

• Avoid generating hot-key, and lead the master database node to become a short board of the system.

• Avoid generating big-key, leading to network card burst and slow query.

• The retry time must be later than the cluster-node-time.

• Redis cluster does not recommend using pipeline and multi-keys operations to reduce the use cases of Max redirect.

5. self-developed redis

Redis's self-developed high-availability solutions are mainly reflected in the configuration center, fault detection, and Failover processing mechanisms. They usually need to be customized based on the actual online environment of the enterprise's business.

Advantages:

• High reliability and availability;

• High autonomous controllability;

• Suitable for actual business needs, good scalability and good compatibility.

Disadvantages:

• Complicated implementation and high development cost;

• It is necessary to establish supporting peripheral facilities, such as monitoring, domain name services, and databases that store metadata information;

• High maintenance costs.

Redis High Availability technical solution Summary