Redis read-write separation architecture technical analysis

background

Redis Regardless of the master-slave version or the cluster specification, the replica does not provide external services as a standby database. Only when HA occurs, the replica is upgraded to master before it undertakes read and write traffic. architecture read and write requests are all completed on the master, and the consistency is high, but the performance is limited by the number of . There are often users who have less data, but have to upgrade to a larger cluster size because of high traffic or concurrency.

In order to meet the business scenarios with more reads and less writes, and to maximize user cost savings, the cloud database Redis version launched a read-write separation specification to provide users with transparent, highly available, high-performance, and highly flexible read-write separation services

Architecture

Redis cluster mode has several roles such as redis-proxy, master, replica, and HA. In the read-write separation instance, a new role of read-only replica is added to bear read traffic. The replica does not provide services as a hot standby, and the architecture maintains compatibility with the existing cluster specifications. The redis-proxy forwards the read and write requests to the master or a read-only replica according to the weight; HA is responsible for monitoring the health status of the DB node, and initiates a master-slave switch or rebuilds the read-only replica when abnormal, and updates the route.

Generally speaking, according to the data synchronization method of master and read-only replica, it can be divided into two architectures: star replication and chain replication.

Star replication

Star replication is to keep all read-only replicas directly synchronized with the master. Each read-only replica is independent of each other. Any abnormality of any node does not affect other nodes. At the same time, because the replication chain is relatively short, read-only replicas The replication delay is relatively small.

Redis is a single-process single-threaded model. The data replication between master and slave is also processed in the main thread. The more the number of read-only replicas, the more serious the CPU consumption of data synchronization on the master, and the write performance of the cluster will vary. Decrease as read-only replica increases. In addition, the star architecture will double the export bandwidth of the master as the read-only replica increases. The higher CPU and network load on the Master will offset the advantages of the lower latency of the star replication. Therefore, the star replication architecture will bring more serious expansion problems, and the performance of the entire cluster will be limited by the master.

Chain copy

Chain replication organizes all read-only replicas into a replication chain. As shown in the figure below, the master only needs to synchronize data to the replica and the first read-only replica in the replication chain.

Chain replication solves the expansion problem of star replication. In theory, the number of read-only replicas can be increased indefinitely. With the increase of nodes, the performance of the entire cluster can basically increase linearly.

Under the chain replication architecture, the longer the replication chain, the greater the synchronization delay between the read-only replica and the master at the end of the replication chain. Considering that read-write separation is mainly used in scenarios where consistency is not high, this The disadvantages are generally acceptable. However, if a node in the replication chain is abnormal, the data of all downstream nodes will lag significantly. What's more serious is that this may bring full synchronization, and full synchronization will be passed to the end of the replication chain, which will have a certain impact on the service. In order to solve this problem, Redis with read-write separation uses the binlog replication version optimized by Alibaba Cloud to minimize the probability of full synchronization.

For more information about the Redis technology stack, you can follow the questions and answers in 160eff2120a72b Redis column 160eff2120a72e. They are very detailed and continue to be updated.

Redis read-write separation advantages

Transparent and compatible

The read-write separation is the same as the normal cluster specifications. Redis-proxy is used for request forwarding. There are certain restrictions on the use of multi-shard commands, but the read-write separation from the master-slave upgrade to single-shard, or the read-write upgrade from the cluster to multi-shards Separate clusters can be fully compatible.

The user establishes a connection with redis-proxy, redis-proxy will identify whether the request sent by the client connection is read or write, and then load balance according to the weight, forward the request to different DB nodes in the backend, and forward the write request to the master , The read operation is forwarded to read-only replica (master also provides read by default, which can be controlled by weight).

Users only need to purchase an instance of the read-write separation specification, and directly use any client to use it directly. The business can start to enjoy the huge performance improvement brought by the read-write separation service without any modification, and the access cost is almost zero.

High availability

high-availability module (HA) monitors the health status of all DB nodes and protects the availability of the entire instance. When the master is down, it will automatically switch to the new master. If a read-only replica goes down, HA can also detect it in time, and then rebuild a new read-only replica to offline the down node.

In addition to HA, redis-proxy can also perceive the status of each read-only replica in real time. During a read-only replica abnormal period, redis-proxy will automatically reduce the weight of this node. If a read-only replica is found to fail more than a certain number of times, the abnormal node will be temporarily shielded, and it will not be restored until the abnormality disappears. Normal weight.

Redis-proxy and HA work together to minimize the business's perception of back-end abnormalities and improve service availability. You can refer to: Redis low-cost high-availability solution

high performance

For business scenarios with more reads and less writes, directly using the cluster version is often not the most suitable solution. now provides more options for read-write separation. The business can choose the most suitable specifications according to the scenario and make full use of each read-only Replica's resources.

At present, a single shard sells 1 master + 1/3/5 read-only replica in multiple specifications (if there is a larger demand, you can submit a work order feedback), providing 600,000 QPS and 192 MB/s service capacity, which is fully compatible Break through the resource limit of a single machine with all commands. In the future, specification restrictions will be removed, allowing users to freely increase or decrease the number of read-only replicas at any time based on business traffic.

Redis master-slave asynchronous replication. Old data may be read from read-only replica. Using read-write separation requires that the business can tolerate a certain degree of data inconsistency. The follow-up will give customers more flexible configuration and greater freedom, such as configuration The maximum delay time that can be tolerated.

Author: Little Love
Source: juejin.cn/post/6955355686108659726