This paper mainly analyzes several common ways of using Redis and its advantages and disadvantages.
First, common use
Several common ways of using Redis include:
- Redis single copy;
- Redis multiple copies (master slave);
- Redis Sentinel;
- Redis Cluster.
- Redis itself.
Two, the advantages and disadvantages of various ways of use
1. Redis single copy
Redis single copy: a single Redis node is deployed. No standby node synchronizes data in real time. Data persistence and backup policies are not provided.
Advantages:
- Simple architecture and convenient deployment;
- Cost-effective: No standby node is required when the cache is used (supervisor or Crontab can be used to ensure the availability of a single instance). Of course, a standby node can be sacrificed to meet the high availability of services. However, only one instance provides services at a time.
- High performance.
Disadvantages:
- The reliability of data is not guaranteed;
- After the cache is used and the process is restarted, data is lost. Even if a standby node is deployed to solve the high availability problem, the cache warm-up problem still cannot be solved. Therefore, it is not applicable to services that require high data reliability.
- High performance is limited by the processing capacity of a single-core CPU (Redis is a single-thread mechanism), and the CPU is the main bottleneck. Therefore, it is suitable for scenarios with simple operation commands and less sorting and calculation. Consider Memcached instead.
2. Redis multiple copies (master/slave)
Redis multi-copy uses a master/slave deployment structure. Compared with single-copy, the most important feature of Redis is real-time data synchronization between master and slave instances, and data persistence and backup policies. The primary and secondary instances are deployed on different physical servers. Based on the enterprise environment, the primary and secondary instances can provide services externally and implement read/write separation policies.
Advantages:
- High reliability: On the one hand, the dual-machine active/standby architecture is adopted to automatically switch the active/standby database when the primary database fails. The secondary database is promoted to provide services for the primary database to ensure the smooth operation of services. On the other hand, enabling the data persistence function and configuring a proper backup policy can effectively solve the problems of data misoperations and abnormal data loss.
- Read/write separation policy: The secondary node can expand the read capability of the primary library node, effectively coping with a large number of concurrent read operations.
Disadvantages:
- Failure recovery is complicated. If there is no RedisHA system (which needs to be developed), when the master library node fails, a slave node needs to be promoted to the master node manually, and the business side needs to be notified of the configuration change, and other slave library nodes need to copy the new master library node. The whole process needs human intervention and is tedious.
- The write capacity of the master library is limited by the single machine, so sharding can be considered.
- The storage capacity of the master library is limited by single machine, so Pika can be considered.
- The disadvantages of native replication are also prominent in earlier versions. For example, after the Redis replication is interrupted, the Slave initiates psync. If the synchronization fails, the Slave performs full synchronization. Because of COW mechanism, in extreme cases, the main library memory overflow, program abnormal exit or downtime; Backup files generated by the primary library node consume server DISK I/O and CPU (compression) resources. The number of GB backup files to be sent increases the egress bandwidth of the server, blocking requests. You are advised to upgrade to the latest version.
3. Redis Sentinel
Redis Sentinel is a native high availability solution launched in the community edition. Its deployment architecture mainly consists of two 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 should be an odd number of 2n+1 (n>=1).
Advantages:
- Redis Sentinel cluster deployment is simple;
- Can solve the high availability switchover problem in Redis master/slave mode;
- It is very convenient to realize the linear expansion of Redis data nodes, easily break through the single thread bottleneck of Redis itself, and can greatly meet the business needs of large capacity or high performance of Redis;
- A Sentinel can be implemented to monitor a set of Redis data nodes or multiple sets of data nodes.
Disadvantages:
- The deployment is more complex than the master-slave mode of Redis, and the principle is more complicated to understand.
- Resource waste, Redis data node slave node as a backup node does not provide services;
- Redis Sentinel mainly refers to the high availability switchover of the master node in Redis data node. Failure judgment of Redis data node can be divided into subjective offline and objective offline. Subjective offline operation is performed on the slave node of Redis without failover.
- Can not solve the problem of read and write separation, the implementation is relatively complex.
Advice:
- If the same service is monitored, a Sentinel cluster can be selected to monitor multiple groups of Redis data nodes, or a Sentinel monitoring scheme can be selected to monitor a group of Redis data nodes.
- Sentinel monitor
< IP >
It is recommended that the
in the quorum> configuration be set to half of the sentinel node plus 1. When sentinel is deployed in multiple IDCs, The number of sentinels deployed in a single IDC is not recommended to exceed quorum.
- Set parameters reasonably to prevent miscutting and control switching sensitivity control:
a. quorum
b. down-after-milliseconds 30000
c. failover-timeout 180000
d. maxclient
e. timeout
- The server time on each node must be synchronized as much as possible; otherwise, the log timing will be confused.
- Redis recommends pipeline and multi-keys to reduce RTT times and improve request efficiency.
- Self-provisioning configuration center (ZooKeeper) facilitates client access to instances.
4, Redis Cluster
Redis Cluster is a community version of Redis distributed Cluster solution, mainly to solve the needs of Redis distributed, for example, when the single memory, concurrency and flow bottleneck, Redis Cluster can play a good load balancing purpose.
Redis Cluster A Cluster node must contain at least six nodes (three active and three slave nodes). The primary node provides read and write operations, and the secondary node serves as the standby node. The primary node does not provide requests, but only serves as failover.
Redis Cluster uses virtual slot partitioning. All keys are mapped to integer slots ranging from 0 to 16,383 based on hash functions. Each node is responsible for maintaining some slots and the mapped key data printed by slots.
Advantages:
- No central architecture;
- Data is distributed to multiple nodes based on slot storage, and data is shared among nodes to dynamically adjust data distribution.
- Scalability: linear expansion to more than 1000 nodes, nodes can be added or deleted dynamically;
- High availability: The cluster is still available when some nodes are unavailable. By adding the Slave as the standby data copy, an automatic failover can be implemented. Status information is exchanged between nodes through the Gossip protocol and the role is promoted from Slave to Master through the voting mechanism.
- Reduces o&M costs and improves system scalability and availability.
Disadvantages:
- The Client implementation is complex, and the driver requires Smart Client. The slots mapping information is cached and updated in time, which makes development difficult. Immature clients affect service stability. At present, only JedisCluster is relatively mature, but the exception handling part, such as the common “Max Redirect Exception”, is not perfect.
- A node is considered to be offline due to clutser-node-timeout for some reason. This failover is unnecessary.
- Asynchronous data replication does not ensure strong data consistency.
- When multiple services use the same cluster, hot and cold data cannot be separated based on statistics, resulting in poor resource isolation and mutual influence.
- Slaves act as “cold standby” in the cluster, which cannot relieve the read pressure. Of course, the utilization of Slave resources can be improved through the rational design of SDK.
- For example, if you use Mset and MGET, only keys with the same slot value can be used in batch operations. For Keys mapped to different slot values, mset, mget, and sunion operations are not friendly because Keys do not support cross-slot queries.
- The support for Key transaction operation is limited and only supports transaction operation of multiple keys on the same node. When multiple keys are distributed on different nodes, the transaction function cannot be used.
- As the smallest granularity of data partitioning, Key cannot map a large key-value object such as hash or list to different nodes.
- Multiple database Spaces are not supported. A single REDis server can support up to 16 databases. In cluster mode, only one database space can be used, that is, DB 0.
- The replication structure supports only one layer. The secondary node can replicate only the primary node. The nested tree replication structure is not supported.
- Avoid hot-keys that cause the primary library node to become a weak spot in the system.
- Avoid big-key generation, which may cause network adapter overload or slow query.
- The retry time must be longer than the cluster-node-time time.
- Pipeline and multi-keys are not recommended for Redis Cluster to reduce Max redirect scenarios.
5. Developed by Redis
The high availability solution developed by Redis is mainly reflected in the configuration center, fault detection, and failover processing mechanism. It usually needs to be customized according to the actual online environment of enterprise services.
Advantages:
- High reliability and availability;
- High autonomy and control;
- Appropriate business actual demand, good shrinkage, good compatibility.
Disadvantages:
- Complex implementation and high development cost;
- Need to establish supporting peripheral facilities, such as monitoring, domain name service, storage metadata information database, etc.
- High maintenance costs.
Original: http://database.51cto.com/art/201808/581665.htm
