If there is help, please point a concern, support me to continue to write, thank you ~

background

Regardless of the primary and secondary versions or cluster specifications of Redis, replica as the standby database does not provide external services. Only when HA occurs, the replica assumes read and write traffic after being promoted to master. In this architecture, all read and write requests are processed on the master, resulting in high consistency, but performance is limited by the number of masters. There are often users who have low data but have to upgrade to a larger cluster size because of high traffic or concurrency.

The Redis version of the cloud database provides read/write separation services with transparency, high availability, high performance, and high flexibility

architecture

The Redis cluster mode includes redis-proxy, Master, Replica and HA. In the read/write separation example, the replica role is added to bear the read traffic, and the replica role does not provide services as a hot backup. The architecture remains compatible with the existing cluster specifications. Redis-proxy forwards read/write requests to the master or a read-only replica according to the weight. HA monitors the health status of the DB node, initiates a primary-secondary switchover or replica when an exception occurs, and updates routes.

Generally speaking, there are two types of data synchronization schemes based on master and Read-only replica: star replication and chain replication.

Star copy

Star replica is a replica that synchronizes all read-only replicas directly with the master. Each Read-only replica is independent of each other. Any anomaly of one node does not affect the other nodes. Read -only The replica delay is small.

Redis is a single-process, single-thread model, in which data replication between primary and secondary replicas is also processed in the main thread. The more replicas read-only, the more serious the CPU consumption of data synchronization to the master is. The write performance of the cluster decreases as read-only replicas increase. In addition, the star configuration multiplicates the master’s egress bandwidth as read-only replicas increase. The higher CPU and network load on the Master will cancel out the lower latency of star replication. Therefore, the star replication architecture will cause serious scaling problems and the overall cluster performance will be limited by the Master.

Chain replication

Chain replication organizes all read-only replicas into a replica 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 replica chain.

Chain replication solves the problem of star replication expansion. Theoretically, it can increase the number of read-only replicas infinitely, and the performance of the entire cluster increases almost linearly as more nodes are added.

In the chain replication architecture, the longer the replication chain, the greater the synchronization delay between the replica and master at the end of the replication chain. Considering that read/write separation is mainly used in scenarios where consistency is not required, this disadvantage is generally acceptable. However, if a node in the replication chain is abnormal, the data of all nodes downstream will be greatly delayed. More seriously, this can lead to full synchronization, and full synchronization will be passed to the end of the replication chain, which will have an impact on the service. To solve this problem, Redis uses aliyun’s optimized binlog copy version to minimize the probability of full synchronization.

Redis read-write separation advantage

  • Transparent compatible

As common cluster specifications, redis-Proxy is used for request forwarding. There are certain restrictions on the use of multi-sharding. However, the read/write separation can be fully compatible with the read/write separation from the master/slave cluster or the read/write separation from the cluster to the multi-sharding cluster.

When the user establishes a connection with the Redis-proxy, the Redis-proxy identifies whether the request sent by the client connection is read or write, and then performs load balancing according to the weight, forwards the request to different BACK-END DB nodes, and forwards the write request to the master. Read operations are forwarded to read-only replica (master also provides reads by default and can be controlled by weight).

Users only need to purchase the read/write separation specification instances and use any client directly. Without any modification, services can enjoy the huge performance improvement brought by the read/write separation service and the access cost is almost zero.

  • High availability

The high availability module (HA) monitors the health status of all DB nodes to ensure the availability of the entire instance. When the master is down, the system automatically switches to the new master. If a Read -only replica is down, HA also senses that the replica is down, and a new Read -only replica takes the faulty node offline.

In addition to HA, redis-proxy also senses the replica status of each read-only replica in real time. During a Read -only replica anomaly, the Redis-proxy automatically reduces the weight of the node. If a read-only replica is found to have failed more than a certain number of times, the node is temporarily shielded until the anomaly disappears.

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

  • A high performance

For a service scenario with a large number of reads and a small number of writes, the cluster version is not the most suitable solution. Nowadays, read/write separation provides more options. The service can select the most suitable specifications based on the scenario to make full use of the resources of each read-only replica.

Read -only Replicas multiple specifications (if there is a larger demand, request feedback), providing a capacity of 600,000 QPS and 192 MB/s, breaking the resource limit of a single shard while fully accommodating all commands. Later, the specification limit will be removed, allowing users to freely add or subtract replica numbers at any time according to the service flow.

Redis asynchronous primary-secondary replication. Old data may be read from replicas. Read/write separation requires the service to tolerate data inconsistency to a certain extent.

If there is help, please point a concern, support me to continue to write, thank you ~