Master slave replication architecture
1.
Redis master-slave replication architecture is only used to solve the problem of redundant backup of data, and can not guarantee the high availability of the system.
In the master-slave replication architecture, the master node Matser provides services externally, while the Slave node Slave does not. The Slave node is only used to synchronize the data of the Master node. Whenever the data of the Master node changes, the Slave node immediately synchronizes the data.
The master-slave replication architecture is not commonly used because it does not have an automatic failover mechanism. If the Master node fails, the Slave node cannot replace the Master node as the new Master node.
Why synchronize Master data?
The data stored on the Master node is very important. If the Master node encounters an irresistible event (such as a natural disaster, power failure, or hardware aging), the data on the Master node will be lost. In order to prevent the loss of data in the cache, Redis also provides a data persistence scheme, but this persistence scheme will only store data locally, if the node fails, the data will still be lost. Therefore, Redis provides a master-slave replication architecture that allows Slave nodes to synchronize data from Master nodes.
Can’t a node provide services to the outside world?
When we say that Slave nodes do not provide services to the outside world, the actual situation is that since Redis 2.6, Slave nodes are read-only by default. They can only read, but not write. It is possible to modify the mode of the Slave node in the redis.conf file of the Slave node so that the Slave node can also perform write operations, but this is not recommended.
2. The architecture diagram
3. The defect
The master-slave replication architecture does not solve the problem of automatic failover.
4. The structures,
Native construction and Docker construction can be used, the specific construction method of baidu.
Sentinel mechanism Architecture
1.
Sentinel is a high availability solution for Redis.
Sentinel system consisting of one or more Sentinel instances can monitor any multiple Master and Slave architectures, including multiple Master nodes and all Slave nodes under these Master nodes. When the monitored Master node goes offline, a Slave node under the offline Master node is automatically upgraded to the new Master node.
In the sentinel mechanism architecture, only the Master node provides external services, and the Slave node is only responsible for synchronizing the data of the Master node.
Simply put, the sentry mechanism is a master-slave replication architecture with automatic failover.
2. The architecture diagram
The Sentinel cluster continuously detects the heartbeat of each node.
The so-called heartbeat means that the sentry cluster sends a packet to each node regularly. After receiving the packet, the node returns a packet to the sentry cluster within a specified time. If the sentry cluster receives the packet within a specified time, the node is judged to be healthy.
If at some point, the sentinel cluster finds that the Master node is not healthy, then the sentinel determines that the Master node is probably down. At this point, Slave1 and Slave2 stop synchronizing data. The sentinel cluster selects a new Master node from multiple Slave nodes through the election mechanism. The other Slave nodes start synchronizing data from the new Master node. If the original Master node is restored at some point, the sentinels will use the original Master node as a Slave node of the new Master node. Through this mechanism, the loop is repeated to ensure that the system is highly available.
3. The defect
Although the sentinel mechanism architecture solves the problem of failover, it cannot solve the problem of single-node pressure and single-node physical upper limit.
All data in Redis is in memory, and all clients access the Master node that provides services externally, so the requirements on the Master node are very high. The single-node stress problem occurs when a large number of requests arrive at the Master node at the same time and the Master deals with a large number of concurrent requests. Because Redis will enable persistence, if it is AOF persistence, AOF files will get bigger and bigger over time, and there will be a single node physical limit problem.
The Redis cluster is the only solution to the single-node stress and physical upper limit problems.
4. The structures,
When setting up sentinels, it is recommended to set up at least two or three sentinels to form a cluster. If there is only one sentinel, it may mistakenly judge that the Master node is down due to the network delay interruption, and a new Master node will be selected to replace the original Master node. However, the original Master node may not fail at this time, and the cluster may have the problem of “split brain” (two leaders).
The sentinel needs to be built based on the master-slave replication architecture, and the specific configuration method is baidu’s own.
Spring Boot integrates the sentry mechanism
The previous Spring Boot integration scheme of Redis is Redis single node connection. If you want to build a master-slave replication architecture, you can also use the integration scheme mentioned above. Because in a single-node connection and master-slave replication architecture, the Master node does not change.
In sentry, the Master is constantly changing. Therefore, there is no need to specify a specific node in the configuration, because it is not clear who is the Master node and who is the Slave node after the Master node changes. We don’t know, but Sentry does, so all we need to do is configure Sentry, and the integrated API in Spring Data Redis remains the same.
In application.yml, the configuration is as follows:
Spring:
redis:
sentinel:
The name of the master/slave schema that the sentinel cluster listens to, configured in sentinel.conf
master: postilhub
# All sentries are separated by commas
nodes: 192.168202.206.: 26379192168 202.207:26379
Copy the code
Since sentinel is a mechanism provided by Redis, remote access is not enabled on sentinel node by default. If we want to access sentinel, we need to make corresponding configuration in sentinel.conf to enable remote connection.