Shulou(Shulou.com)06/01 Report--

Guide to Redis version of cloud database regardless of master / slave version or cluster specification. Replica does not provide external services as a slave database. Only when HA occurs and replica is upgraded to master will it bear read and write traffic. The read and write requests of this architecture are completed on master with high consistency, but the performance is limited by the number of master. There are often users with less data, but have to upgrade to larger cluster specifications because of high traffic or concurrency.

Background

Regardless of the master / slave version or cluster specification, replica does not provide external services as a slave database for cloud database Redis. Only when HA occurs and replica is upgraded to master will it bear read and write traffic. The read and write requests of this architecture are completed on master with high consistency, but the performance is limited by the number of master. There are often users with less data, but have to upgrade to larger cluster specifications because of high traffic or concurrency.

To meet the business scenario of reading more and writing less, and maximize user cost savings, Redis version of Cloud Database has introduced the specification of read-write separation, which provides users with transparent, highly available, high-performance and highly flexible read-write separation service.

Architecture

Redis cluster mode has several roles such as redis-proxy, master, replica, HA and so on. In read-write separation instances, a new read-only replica role is added to handle read traffic. Replica does not provide a service as a hot backup, and the architecture is compatible with the existing cluster specifications. Redis-proxy forwards read and write requests to master or a read-only replica by weight; HA is responsible for monitoring the health status of DB nodes, initiating master-slave switching or rerunning read-only replica in case of exception, and updating routes.

Generally speaking, according to the data synchronization mode 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 replica synchronized with master directly, each read-only replica is independent of each other, any node exception does not affect other nodes, and because the replication chain is short, the replication delay on read-only replica is relatively small.

Redis is a single-process single-threaded model, and the data replication between master and slave is also handled in the main thread. The more the number of read-only replica, the more serious the CPU consumption of data synchronization to master, and the write performance of the cluster will decrease with the increase of read-only replica. In addition, the star architecture will multiply the egress bandwidth of master as the read-only replica increases. Higher CPU and network load on Master will offset the advantage of low latency of star replication. Therefore, star replication architecture will bring serious scaling problems, and the performance of the entire cluster will be limited by master.

Chain replication

Chain replication organizes all the read-only replica into a replication chain, as shown in the following figure, where master only needs to synchronize data to the replica and the first read-only replica on the replication chain.

Chain replication solves the expansion problem of star replication. In theory, the number of read-only replica can be increased indefinitely, and the performance of the whole cluster can increase linearly with the increase of nodes.

In the chain replication architecture, the longer the replication chain, the greater the synchronization delay between read-only replica and master at the end of the replication chain. Considering that read-write separation is mainly used in scenarios that do not require high consistency, this disadvantage is generally acceptable. However, if a node in the replication chain is abnormal, it will result in a significant lag in the data of all nodes downstream. What is more serious is that this may lead to full synchronization, which will be passed all the way to the end of the replication chain, which will have an impact on the service. In order to solve this problem, Redis with read-write separation uses the optimized binlog copy version of Aliyun to minimize the probability of full synchronization.

Combined with the above discussion and comparison, Redis read-write separation chooses the chained replication architecture.

Redis read-write separation advantages are transparent and compatible

Read-write separation is the same as ordinary cluster specifications, both use redis-proxy for request forwarding, and there are certain restrictions on the use of multi-shard, but read-write separation from master-slave upgrade single-shard, or from cluster to multi-shard read-write separation cluster can be fully compatible.

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

Users only need to purchase instances with read-write separation specifications and use any client directly. The business can begin 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

The High availability Module (HA) monitors the health status of all DB nodes to protect the availability of the entire instance. Master automatically switches to the new master when it goes down. If a read-only replica goes down, the HA can sense it in time, and then build a new read-only replica and offline the downtime node.

In addition to HA, redis-proxy can also perceive the state of each read-only replica in real time. During a read-only replica exception, redis-proxy will automatically reduce the weight of this node. If it is found that a read-only replica fails more than a certain number of times, it will temporarily block the exception node until the exception disappears before returning to its normal weight.

Redis-proxy and HA work together to minimize business perception of back-end exceptions and improve service availability.

High performance

For business scenarios that read more and write less, it is often not the most appropriate solution to use the cluster version directly. Now read-write separation provides more options. Businesses can choose the most appropriate specification according to the scenario and make full use of the resources of each read-only replica.

At present, single shard sells 1 master + 1-3-5 read-only replica with multiple specifications (if there is a greater demand, you can submit a ticket for feedback), providing 600000 QPS and 192 MB/s service capacity, breaking the resource limit of a single machine while fully compatible with all commands. In the future, the specification limit will be removed, allowing users to freely increase or decrease the number of read-only replica at any time according to business traffic.

Follow up

Redis master-slave asynchronous replication may read old data from read-only replica. Using read-write separation requires the business to tolerate a certain degree of data inconsistency. Later, customers will be given more flexible configuration and greater freedom, such as the maximum delay that can be tolerated by configuration.

The original text is from: https://www.linuxprobe.com/redis-read-write-separation.html

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.