Shulou(Shulou.com)05/31 Report--

This article mainly introduces "several common ways of using Redis and its advantages and disadvantages". In daily operation, I believe many people have doubts about several common ways of using Redis and its advantages and disadvantages. Xiaobian consulted various materials and sorted out simple and easy operation methods. I hope to help you answer the doubts of "several common ways of using Redis and its advantages and disadvantages"! Next, please follow the small series to learn together!

I. Common ways of use

Several common uses of Redis include:

1. Redis single copy

Redis single replica, using a single Redis node deployment architecture, no standby node real-time synchronization of data, no data persistence and backup policies, suitable for pure cache business scenarios with low data reliability requirements.

Advantages:

Simple architecture and easy deployment;

High cost performance: No standby node is needed when the cache is used (single instance availability can be guaranteed by supervisor or crontab). Of course, in order to meet the high availability of the service, one standby node can also be sacrificed, but only one instance provides services to the outside world at the same time;

High performance.

Disadvantages:

No guarantee of data reliability;

After the cache is used and the process is restarted, data is lost. Even if there are standby nodes to solve the high availability problem, the cache warm-up problem cannot be solved, so it is not suitable for services with high data reliability requirements.

High performance is limited by the processing power of single-core CPU (Redis is a single-thread mechanism), CPU is the main bottleneck, so it is suitable for scenarios with simple operation commands, sorting and less calculation. You can also consider using Memcached instead.

2. Redis multiple copies (master-slave)

Redis multi-replica adopts a master-slave (replication) deployment structure. Compared with single replica, *** is characterized by real-time synchronization of data between master-slave instances and data persistence and backup policies. Master-slave instances are deployed on different physical servers. According to the basic environment configuration of the company, you can provide services to the outside world at the same time and implement the read-write separation policy.

Advantages:

High reliability: on the one hand, it adopts dual-host/standby architecture, which can automatically switch between active and standby when the main database fails, and upgrade the slave database to provide services to the main database to ensure smooth operation of services; on the other hand, it enables data persistence function and configures reasonable backup strategy, which can effectively solve the problems of data misoperation and abnormal data loss;

Read-write separation strategy: slave nodes can expand the read capacity of master nodes and effectively deal with large concurrent read operations.

Disadvantages:

Failure recovery is complicated. If there is no Redis HA system (development is required), when a master node fails, a slave node needs to be manually promoted to a master node, and at the same time, the business party needs to be notified to change the configuration, and other slave nodes need to copy the new master node. The whole process requires human intervention and is relatively cumbersome.

The ability to write the main library is limited by a single machine, and fragmentation can be considered.

The storage capacity of the main library is limited by the single machine, so Pika can be considered.

The disadvantages of native replication are also prominent in earlier versions, such as: after Redis replication is interrupted, Slave will initiate psync, and if synchronization is unsuccessful, full synchronization will be performed, and the main database may cause milliseconds or seconds of stagnation while performing full backup; due to COW mechanism, the main database memory overflow in *** case, the program will exit abnormally or crash; the main database node generates backup files, resulting in server disk IO and CPU(compression) resource consumption; Sending backup files several GB in size causes server egress bandwidth to explode and block requests. It is recommended to upgrade to version ***.

3. Redis Sentinel

Redis Sentinel is a community-based version of a native high availability solution whose deployment architecture consists of two main 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 nodes of Redis Sentinel must satisfy an odd number of 2n+1(n>=1).

Advantages:

Redis Sentinel cluster deployment is simple;

Can solve the problem of high availability switching in Redis master-slave mode;

It is very convenient to realize linear expansion of Redis data nodes, easily break through Redis's own single-thread bottleneck, and greatly meet Redis's large-capacity or high-performance business requirements;

A set of Sentinel can be implemented to monitor a group of Redis data nodes or multiple groups of data nodes.

Disadvantages:

Deployment is more complicated than Redis master-slave mode, and the principle is more complicated to understand.

Resource waste, slave node in Redis data node as backup node does not provide service;

Redis Sentinel is mainly used for high availability switching of the master node in Redis data nodes. There are two types of failure judgment for Redis data nodes: subjective offline operation and objective offline operation. For Redis slave nodes, subjective offline operation is performed on nodes without failover.

It cannot solve the problem of separation of reading and writing, and its implementation is relatively complex.

Recommendations:

If monitoring the same service, you can select a solution in which Sentinel clusters monitor multiple groups of Redis data nodes, and conversely, select a solution in which Sentinel monitors one group of Redis data nodes.

sentinel monitor

The recommendation in the configuration is set to half the number of Sentinel nodes plus 1. When Sentinel is deployed in multiple IDC, the number of Sentinel in a single IDC deployment is not recommended to exceed (Sentinel number-quorum).

Set parameters reasonably to prevent misswitching and control switching sensitivity control:

a. quorum

b. down-after-milliseconds 30000

c. failover-timeout 180000

d. maxclient

e. timeout

The deployment of each node server time should be synchronized as much as possible, otherwise the timing of the log will be chaotic.

Redis recommends using pipeline and multi-keys operations to reduce RTT times and improve request efficiency.

You can handle the configuration center (zookeeper) by yourself to facilitate the client to access the link to the instance.

4、Redis Cluster

Redis Cluster is a community version of Redis distributed cluster solution, mainly to solve the needs of Redis distribution, for example, when encountering single memory, concurrency and traffic bottlenecks, Redis Cluster can play a very good Load Balancer purpose.

Redis Cluster nodes are configured with at least 6 nodes (3 primary and 3 secondary), where the primary node provides read and write operations, and the secondary node acts as a standby node without providing requests and is only used as a failover.

Redis Cluster uses virtual slot partition, all keys are mapped to 0~16383 integer slots according to hash function, and each node is responsible for maintaining a part of slots and key data mapped by slots.

Advantages:

No central structure;

Data is stored and distributed in multiple nodes according to slots. Data sharing among nodes can dynamically adjust data distribution.

Scalability: linear expansion to more than 1000 nodes, nodes can be dynamically added or deleted;

High availability: When some nodes are unavailable, the cluster remains available. By adding Slave as standby data copy, automatic failover can be realized, state information is exchanged between nodes through Gossip protocol, and the role promotion from Slave to Master is completed by voting mechanism.

Reduce operation and maintenance costs and improve system scalability and availability.

Disadvantages:

Client implementation is complex, the driver requires the implementation of Smart Client, cache slots mapping information and update it in time, which increases the difficulty of development, and the immaturity of the client affects the stability of the service. At present, only JedisCluster is relatively mature, and the exception handling part is not perfect, such as the common "max redirect exception".

The node will block for some reason (blocking time is longer than clutser-node-timeout) and be judged offline. This failover is unnecessary.

Data is replicated asynchronously and strong consistency of data is not guaranteed.

When multiple businesses use the same cluster, hot and cold data cannot be distinguished according to statistics, and resource isolation is poor, which is easy to affect each other.

Slave acts as a "cold standby" in the cluster and cannot relieve the reading pressure. Of course, the utilization rate of Slave resources can be improved through reasonable design of SDK.

Key batch operation restrictions, such as using mset, mget currently only support keys with the same slot value to perform batch operations. For Keys mapped to different slot values, since Keys does not support cross-slot queries, it is unfriendly to execute operations such as mset, mget, sunion, etc.

Key transaction operation support is limited, only transactions with multiple keys on the same node are supported. When multiple keys are distributed on different nodes, the transaction function cannot be used.

As the smallest granularity of data partition, Key cannot map a large key object such as hash, list, etc. to different nodes.

Redis does not support multiple database spaces. Redis can support up to 16 databases in a stand-alone mode, and only one database space can be used in cluster mode, i.e. db0.

Copy structure only supports one level, slave node can only copy master node, nested tree copy structure is not supported.

Avoid generating hot-keys, which cause the main library node to become a short board of the system.

Avoid big-key generation, which leads to network card explosion and slow query.

Retry time should be greater than cluster-node-time time.

Redis Cluster does not recommend using pipeline and multi-keys operations to reduce the scenes generated by max redirect.

5. Redis self-research

Redis self-developed high availability solutions, mainly embodied in the configuration center, fault detection and failover processing mechanism, usually need to be customized according to the actual online environment of the enterprise business.

Advantages:

High reliability, high availability;

High autonomous controllability;

Appropriate to actual business needs, good scalability, good compatibility.

Disadvantages:

Complicated implementation and high development cost;

It is necessary to establish supporting peripheral facilities, such as monitoring, domain name service, database for storing metadata information, etc.

High maintenance costs.

At this point, the study of "several common ways of using Redis and their advantages and disadvantages" is over, hoping to solve everyone's doubts. Theory and practice can better match to help you learn, go and try it! If you want to continue learning more relevant knowledge, please continue to pay attention to the website, Xiaobian will continue to strive to bring more practical articles for everyone!

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.