Home > Database > Redis > Detailed graphic explanation of three Redis deployment solutions

Detailed graphic explanation of three Redis deployment solutions

Release: 2019-11-29 16:42:01
forward
4723 people have browsed it

Detailed graphic explanation of three Redis deployment solutions

##standaloan (stand-alone mode)

standaloan is redis stand-alone mode, and all services are connected to one redis service, this mode is not suitable for production. If there is a downtime and memory explosion, it may cause cache failure of all services connected to redis and cause an avalanche. (Recommended:

redis video tutorial)

ssentinel (Sentinel Mode)

redis-Sentinel (Sentinel Mode) is the high availability officially recommended by Redis (HA) solution, when using Redis as a high-availability solution for Master-slave, if the master goes down, Redis itself (including many of its clients) does not implement automatic master-slave switching, and Redis-sentinel itself does not An independently running process, it can monitor multiple master-slave clusters and switch after it finds that the master is down.

Detailed graphic explanation of three Redis deployment solutions

sentinel Sentinel implements the following functions

(1) monitoring: monitoring whether redis is running normally

(2) notification: notifying the application of error messages

(3) failover: when a master dies, choose another slave to upgrade to the master , update the master-slave relationship.

(4) Configuration provider: The client obtains the redis address through sentinel and updates the address during failover

2, sentinels and slaves autodiscovery (redis2.8 and above)

Configuration Only the master address is configured in the file, and the slave address and sentinel address can be automatically discovered.

(1) sentinels - obtained by exchanging information between sentinels through redis pub/sub.

(2) slaves-ask the master to get them.

3, sdown, odown, failover

Fault detection is generally through the ping-pong mechanism. Sentinel introduces the sdown (subjective offline) and odown (objective offline) mechanisms. The purpose should be When the cluster scale is large, the detection is more objective

(1) sdwon——ping-pong fails within is-master-down-after-milliseconds (configurable). The slave of sdown cannot be upgraded to master.

(2) odown - Sentinels exceeding a certain number (configurable) consider sdown, and odown only targets the master.

(3) failover - most sentinels think odown.

redis-cluster (cluster mode)

redis cluster mode can also achieve high-availability deployment of redis. In Redis Sentinel cluster mode, with the volume of business and data As the performance increases, the performance reaches the single-node bottleneck of redis. Vertical expansion is limited by the machine. Horizontal expansion involves the impact on applications and the risk of data loss during data migration. In response to these pain points

Redis3.0 launched the cluster distributed cluster solution. When encountering single-node memory, concurrency, and traffic bottlenecks, the cluster solution is used to achieve load balancing. The cluster solution mainly solves the sharding problem, that is, the entire The data is divided into multiple subsets according to rules and stored at multiple different points. Each node is responsible for its own part of the entire data.

Redis Cluster adopts virtual slot partitioning in hash partitioning rules. Virtual slot partitioning cleverly uses hash space and uses a hash function with good dispersion to map all data to a set of integers within a fixed range. The integers are defined as slots. The range of Redis Cluster slots is 0 ~ 16383. Slots are the basic unit of data management and migration within a cluster.

The main purpose of using a wide range of slots is to facilitate data splitting and cluster expansion. Each node is responsible for a certain number of slots. Redis Cluster uses virtual slot partitioning. All keys are mapped to 0 ~ 16383 according to the hash function. The calculation formula is: slot = CRC16(key)&16383. Each real node is responsible for maintaining a part of the slots and the key value data mapped by the slots. The figure below shows a cluster composed of five nodes. Each node is responsible for an average of approximately 3276 slots, and the process of mapping to the corresponding slots of the corresponding nodes through calculation formulas.

redis-cluster architecture diagramDetailed graphic explanation of three Redis deployment solutions

Detailed graphic explanation of three Redis deployment solutions

For more redis knowledge, please pay attention to the

redis introductory tutorial column.

The above is the detailed content of Detailed graphic explanation of three Redis deployment solutions. For more information, please follow other related articles on the PHP Chinese website!

Related labels:
source:csdn.net
Statement of this Website
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn
Popular Tutorials
More>
Latest Downloads
More>
Web Effects
Website Source Code
Website Materials
Front End Template