Recently a lot of friends to consult me about the advantages and disadvantages of solution of high availability and how to choose appropriate solutions online use, just recently in pleasant to borrow, everbright bank do in-house training also talked about in detail, I’ll arrange sent to here, for your reference, such as is not satisfactory place, welcome criticism and corrections, also welcome to recommend better technology solutions. No more nonsense, come to see the plan ~
sum
Redis is commonly used in the following ways:
A copy of the Redis list
Redis Multiple copies (master slave)
Redis Sentinel
Redis Cluster
Redis itself
Advantages and disadvantages of the various uses of Redis:
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.
1. Simple architecture and convenient deployment
2. High cost performance. When the cache is used, no standby node is required (the availability of a single instance can be guaranteed by Supervisor or Crontab). Of course, a standby node can be sacrificed to meet the high availability of services, but only one instance provides services at a time.
3. High performance
1. Data reliability is not guaranteed
2. When 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.
3. High performance is limited by the processing capacity 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 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.
1. High reliability. On the one hand, the dual-machine master/standby architecture is adopted to automatically switch the master/standby in case of failure of the master library, and upgrade the slave library to provide services for the master library 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 problem of data misoperations and abnormal data loss.
2. Read/write separation strategy. The secondary node can expand the read capacity of the primary library node and effectively cope with large concurrent read operations.
1, fault recovery and complex, if not RedisHA system (development), when the main library node failure, will need to manually from a node promotion is given priority to, also need to inform the business change configuration, and the need to let other nodes from the library to copy the new main library, the whole process need human intervention, more complicated.
2. The write capacity of the master library is limited by the single machine, so sharding can be considered
3. The storage capacity of the master library is limited by single machine, so Pika can be considered
4. Disadvantages of native replication are also prominent in earlier versions. For example, after the Redis replication is interrupted, the Slave will initiate psync. 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. Sending GB backup files 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. The Redis Sentinel deployment architecture consists of two main parts: Redis Sentinel cluster and Redis data cluster, among which Redis Sentinel cluster is a distributed cluster composed of several Sentinel nodes. You 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).
1. Redis Sentinel cluster deployment is simple
2. It can solve the problem of high availability switchover in Redis master/slave mode
3, 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.
4. A Sentinel can be implemented to monitor a group of Redis data nodes or multiple groups of data nodes
1. The deployment is more complicated than the master-slave mode of Redis, and the understanding of the principle is more complicated
2. Waste of resources. The slave node of Redis data node does not provide services as a backup node
3. 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.
4, can not solve the problem of read and write separation, relatively complex to achieve
1. If the same business is monitored, a Sentinel cluster monitoring scheme for multiple groups of Redis data nodes can be selected; otherwise, a Sentinel monitoring scheme for a group of Redis data nodes can be selected
2, Sentinel monitor <master-name> < IP > <port> <quorum> It is recommended that the <quorum> 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.
3. Set parameters reasonably to prevent miscutting and control switching sensitivity control
quorum
down-after-milliseconds 30000
failover-timeout 180000
maxclient
timeout
4. The server time of each node deployed should be synchronized as far as possible; otherwise, the timing of logs will be chaotic
5. Redis suggests using pipeline and multi-keys to reduce RTT times and improve request efficiency
6, own configuration center (ZooKeeper), convenient client access to the instance link
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.
We recommend a Java architecture networking group: 650385180, which will share some videos recorded by senior architects: Spring, MyBatis, Netty source code analysis, high concurrency, high performance, distributed, microservice architecture principles, JVM performance optimization has become an architect’s essential knowledge system. You can also receive free learning resources. The general outline of the beginning of the article is obtained in the group, I believe that for the code friends who have worked and encountered technical bottlenecks, there must be content you need in this group.
1. No central architecture
2. Data is distributed on multiple nodes according to slot storage, and data is shared among nodes to dynamically adjust data distribution.
3, scalability, linear expansion to more than 1000 nodes, nodes can be added or deleted dynamically.
4. High availability: The cluster is still available when some nodes are unavailable. By adding a Slave as a standby data copy, an automatic failover can be implemented, status information is exchanged between nodes through the gossip protocol, and roles are promoted from Slave to Master through the voting mechanism.
5. Reduce operation and maintenance costs and improve system scalability and availability.
1. The Client implementation is complex, and the driver requires Smart Client. The information of slots mapping is cached and updated in time, which increases the difficulty of development. At present, only JedisCluster is relatively mature, but the exception handling part, such as the common “Max Redirect Exception”, is not perfect.
2. A node is considered to be offline due to clutser-node-timeout for some reason. This failover is unnecessary.
3. Asynchronous data replication does not ensure strong data consistency.
4. When multiple services use the same cluster, cold and hot data cannot be differentiated according to statistics, resulting in poor resource isolation and mutual influence.
5. The Slave acts as “cold standby” in the cluster, which cannot relieve the read pressure. Of course, the utilization of Slave resources can be improved through the reasonable design of SDK.
6. Restriction on batch operation of keys. For example, using Mset and MGET, only keys with the same slot value can be batch operated. For keys mapped to different slot values, mset, mget, and sunion operations are not friendly because keys do not support cross-slot queries.
7. The transaction operation of key is limited, only the transaction operation of multiple keys on the same node is supported. When multiple keys are distributed on different nodes, the transaction function cannot be used.
8. Key is the minimum granularity of data partitioning, so it is not possible to map a large key-value object such as hash, list, etc to different nodes.
9. Multiple database space is not supported. Redis can support 16 databases in a single machine, and only one database space can be used in cluster mode, that is, DB 0.
10. The replication structure supports only one layer. The secondary node can only copy the master node, and the nested tree replication structure is not supported.
11, avoid the generation of hot-key, leading to the main library node to become the weak board of the system.
12. Avoid big-key generation, which may lead to network card overload and slow query.
13. Retry time should be longer than cluster-node-time
14. Redis Cluster is not recommended to use pipeline and multi-keys to reduce the scenarios generated by Max redirect.
5, Redis research – recommendation recommendation
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.
1. High reliability and availability
2, high autonomy and control
3, appropriate business actual demand, good shrinkage, good compatibility
1. Complex implementation and high development cost
2, need to establish supporting peripheral facilities, such as monitoring, domain name service, storage metadata information database, etc.
3, high maintenance costs