background
Whether Redis is a master or a slave, Replica does not provide services as a backup database. Only in HA cases does Replica assume read-write traffic when it is upgraded to master. In this architecture, read and write requests are done on the master, which is consistent, but performance is limited by the number of masters. 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 scenario of reading more and writing less and to maximize user cost savings, Redis version of cloud database has launched read-write separation specification, which provides users with transparent, highly available, high-performance and flexible read-write separation service
architecture
There are several roles in Redis cluster model, such as Redis-proxy, Master, Replica and HA. In the example of read-write separation, Read-only Replica is added to assume the read traffic, while Replica as the hot standby does not provide services. In terms of architecture, the compatibility with the existing cluster specifications is maintained. Redis-proxy forwards read and write requests to master or a read-only replica according to the weight; HA is responsible for monitoring the health status of DB nodes, initiating master-slave switching or re-replica of read-only replica in case of abnormalities, and updating routes.
Generally speaking, according to the data synchronization methods of master and read-only replica, there are two types of structures: star replication and chain replication.
Star copy
In star replication, all read-only replicas are synchronized with the master. Each read-only replica is independent of each other. Abnormality of any one node does not affect other nodes. Replica delay on read-only replica is relatively small.
Redis is a single-process single-thread model, and data replication between master and slave is also processed in the main thread. The more Read-only Replica is, the more CPU consumption of master will be caused by data synchronization, and the writing performance of cluster will decrease with the increase of Read-only Replica. In addition, the star structure will make the export bandwidth of master increase exponentially with the increase of read-only replica. The higher CPU and network load on the Master can offset the lower star replication latency, so the star replication architecture can cause serious scaling problems and the overall cluster performance can be limited by the Master.
Chain replication
As shown in the figure below, the master only needs to synchronize data to the first read-only replica in the replica chain.
Chain replication solves the expansion problem of star replication. Theoretically, the number of read-only replicas can be infinitely increased. As the number of nodes increases, the performance of the whole cluster can also increase linearly.
In the framework of chain replication, the longer the replication chain is, the greater the synchronization delay between read-only replica and master at the end of the replication chain will be. Considering that read-write separation is mainly used in scenarios with low requirements for consistency, this drawback is generally acceptable. However, if one node in the replication chain is abnormal, the data of all downstream nodes will lag significantly. More seriously, this could lead to full synchronization, which would be passed all the way to the end of the replication chain, which would have an impact on the service. To solve this problem, read-write separated Redis all use AliCloud optimized copies of the binlog to minimize the probability of full synchronization.
More about the Redis technology stack learning, you can pay attention to the road of migrant workers technology public number, in the Redis column to view the relevant technical articles, interview questions and answers, very detailed, continuing to update.
Redis read-write separation advantage
Transparent compatible
The read-write separation is the same as the common cluster specification, and Redis-proxy is used for request forwarding. Multi-sharding makes the use limited to some extent, but the read-write separation from single-sharding upgrading from master to slave, or read-write separation from cluster upgrading to multi-sharding cluster can achieve full compatibility.
The user sets up a connection with the Redis-proxy, and the Redis-proxy will identify whether the request sent by the client connection is read or written, and then load balance according to the weight. The request will be forwarded to different DB nodes on the back end, and the write request will be forwarded to the master. Reads are forwarded to Read-only Replica (the master also provides reads by default and can be controlled by weight).
Users just need to purchase an instance of the read-write separation specification and use it directly from any client. Businesses can start to enjoy the huge performance improvements brought by the read-write separation service without making any changes, and the access cost is almost zero.
High availability
The high availability module (HA) monitors the health status of all DB nodes and ensures the availability of the entire instance. When the master goes down, it automatically switches to the new master. If one read-only replica is down, HA can also sense it in time and reconstruct a new read-only replica.
Besides HA, Redis-Proxy can also perceive the status of each read-only replica in real time. During the period of a read-only replica anomaly, Redis-Proxy will automatically reduce the weight of this node. If it finds that a read-only replica has failed continuously for more than a certain number of times, it will temporarily shield the abnormal node and restore its normal weight until the anomaly disappears.
Redis-Proxy and HA work together to minimize the business’s awareness of back-end exceptions and improve service availability. Refer to: Redis Low Cost High Availability Solution
A high performance
For business scenarios that read more and write less, directly using the cluster version is often not the most appropriate solution. Now read-write separation provides more options, so businesses can choose the most suitable specifications according to the scenario and make full use of each read-only replica resource.
Currently, single shard sells various specifications of 1 master + 1/3/5 read-only replica (if there is a greater demand, orders can be sent for feedback), providing 600,000 QPS and 192 MB/s service capacity, which breaks through the resource limit of single machine under the condition of fully compatible with all orders. Later, the specification restriction will be removed so that users can freely increase or decrease the number of read-only replicas according to the service flow at any time.
With Redis master and slave asynchronous replication, old data may be read from read-only replica. The use of read-write separation requires the business to tolerate a certain degree of data inconsistency, which will give customers more flexible configuration and greater freedom, such as configurable maximum delay time that can be tolerated.
Author: a small source of love: juejin. Cn/post / 6955355686108659726
