Location>code7788 >text

Redis high availability deployment: 3 servers to build a sentinel cluster

Popularity：864 ℃/2025-02-27 11:27:44

1. Introduction to Redis cluster

Redis Cluster is a distributed deployment method provided by Redis, designed to provide high availability. If a master node fails, the cluster can automatically fail over and promote the replica to the master node to ensure the continuous availability of data. Redis clusters are very suitable for large-scale cache systems and large-data scenarios.

2. Several ways to build a cluster

  • Master-Slave Copy (Master-Slave): In this mode, the master node (Master) is responsible for data writing and reading, while the slave node (Slave) can only be used for data reading and backup, and cannot write data. If the master node fails, manual intervention is required to promote a slave node to a new master node. This mode does not have automatic failover and requires manual handling of the failure, so it is poor in availability. At least 2 servers are required to build one master and one slave or multiple servers. Automatic failover can be achieved with the help of high availability tools when resources are not allowed. For example: Keepalived + Redis master and slave realize dual active operation of master and backup.
  • Sentinel mode (Redis Sentinel): In sentinel mode, additional Sentinel service is required to monitor the master node in the Redis cluster, and it can automatically fail over when the master node fails. Through election, the slave node will be upgraded to the master node. It provides high availability and automatic recovery capabilities. Common clustering methods are:1 master 2 slave + 3 Sentinel processes, Sentinel processes can be deployed on the same 3 nodes to reduce server resources. It is more suitable for small and medium-sized applications that require high availability, and the data volume is not particularly large.
  • Redis Cluster: This mode supports data sharding storage and multi-node horizontal scaling, effectively improving memory utilization and write performance. The inserted data will be distributed to different nodes according to certain rules (hash slots). Each node is responsible for a subset of the data (through the range of the hash slots), which will automatically manage the distribution and migration of the data. It adopts a decentralized multi-master and multi-slave architecture, with the minimum configuration requirements of 3 master nodes (Master) and 3 slave nodes (Slave). Generally, one master and one slave can be configured on each server in 3 servers. Although this will affect certain performance, it can reduce the resources required by the server. If you need to achieve its maximum value, at least 6 server nodes are required. This cluster is ideal for larger and higher demanding data processing scenarios.

3. Select the cluster mode

Here, make appropriate choices based on the Redis requirements required by the affiliated business system. useRedis ClusterThe requirements for building a sharded cluster in mode are relatively high. Clients must support cluster mode and configure itRedis ClusterIt requires much more complex than the ordinary Redis master-slave mode and requires relatively high cost. Only when the application requires high performance, high throughput, and requires data distribution and scalability,Redis ClusterIt's a better choice. useRedis SentinelThe mode of building a cluster is relatively not particularly complicated. You only need to build the Redis master and slave mode and start the relevant ones.SentinelJust do it. If the data volume is not particularly large, using Redis clusters is only used to provide high availability and failover, you can consider usingRedis Sentinel. Used in this articleSentinel mode (Redis Sentinel)Build a Redis cluster.

Related introduction to Sentinel mode:

Redis Sentinel was first introduced inRedis 2.8.0In version. This versionDecember 2013release.Redis SentinelThe original design intention is to make up for itRedisInadequacy in high availability and automatic failover, especially for fault tolerance for master node downtime in master-slave replication architectures. passRedis SentinelAutomatic fault detection and automatic failover can be achieved to improveRedisusability and reliability. In this mode, the Sentinel is responsible for real-time monitoring of the health of the master node. If a master node fails, the sentry will automatically promote a slave node to a new master node based on the preset voting mechanism to ensure the continuity of the service and the availability of data. The sentinel itself is an independent process running outside the process of Redis itself. It ensures the stability of the Redis service by continuously monitoring the status of the Redis server, including the master and slave nodes, and regularly ping the master and slave nodes to confirm whether they are still available, to determine whether the monitored Redis instance is running normally.

4. Environmental preparation

4.1. Server information

According to the above construction methods and related suggestions, in the case of 3 server nodes, the first choice isRedis SentinelThe sentinel mode is built. The following is the server information:

server IP address Deploy the application
node1 192.168.42.131 Redis Master +Sentinel
node2 192.168.42.132 Redis Slave + Sentinel
node3 192.168.42.133 Redis Slave + Sentinel

4.2. Software version

  • operating system: CentOS 7.9
  • Redis version: 5.0

5. Configure Redis master-slave replication

5.1. Create a directory

Create the following directories in three servers:

# Select the Redis storage file directory and create the following directory
 mkdir -p /root/docker/redis/config /root/docker/redis/data /root/docker/redis/sentinel

 # config to store redis configuration file information such as:
 # data Save persisted Redis data
 # sentinel The configuration file information of the sentinel, such as:

Download the configuration fileGo to local and upload to serverconfigDirectory, download address:/redis/redis/blob/5.0.4/

5.2. Configure Redis configuration file

existnode1、node2andnode3Update Redis configuration file informationvim ~/docker/redis/config/, configure password and master-slave relationship.

Master node (node1):

# Run port
 port 6379
 # Allow all external IP access
 bind 0.0.0.0
 # Whether to run as a daemon, Docker run must be set to no.
 daemonize no
 # redis password
 requirepass "1234qwer"
 # Configure the master-slave connection password
 masterauth "1234qwer"
 # Turn on persistence
 appendonly yes

 #Fixed open IP address to the outside world
 slave-announce-ip 192.168.42.131
 #Fixed open ports to the outside
 slave-announce-port 6379

Slave node (node2):

port 6379
 bind 0.0.0.0
 daemonize no
 requirepass "1234qwer"
 masterauth "1234qwer"
 appendonly yes

 # Fixed open IP address to the outside world
 slave-announce-ip 192.168.42.132
 # Fixed open ports to the outside
 slave-announce-port 6379
 # Configure the IP and port of the master node
 REPLICAOF 192.168.42.131 6379

Slave node (node3)

port 6379
 bind 0.0.0.0
 daemonize no
 requirepass "1234qwer"
 masterauth "1234qwer"
 appendonly yes

 # Fixed open IP address to the outside world
 slave-announce-ip 192.168.42.133
 # Fixed open ports to the outside
 slave-announce-port 6379
 # Configure the IP and port of the master node
 REPLICAOF 192.168.42.131 6379

5.3. Start the Redis container

Master node (node1):

docker run -d -p 6379:6379 --restart=always --privileged=true --name redis-master -v ~/docker/redis/config/:/etc/redis/ -v ~/docker/redis/data:/data redis:5.0 redis-server /etc/redis/

Slave node (node2):

docker run -d -p 6379:6379 --restart=always --privileged=true --name redis-slave -v ~/docker/redis/config/:/etc/redis/ -v ~/docker/redis/data:/data redis:5.0 redis-server /etc/redis/

Slave node (node3):

docker run -d -p 6379:6379 --restart=always --privileged=true --name redis-slave -v ~/docker/redis/config/:/etc/redis/ -v ~/docker/redis/data:/data redis:5.0 redis-server /etc/redis/

5.4. Verify master-slave copy

Log inredisenter:info replicationCan viewRedisCluster configuration information. If the construction is successful, the node information will be displayed.

The master node (node1) displays the following information:

# First enter the redis container through docker
 docker exec -it redis-master bash
 # After successful entry, log in to redis
 redis-cli -p 6379
 # Log in successfully, perform password authentication, and then view cluster configuration information
 127.0.0.1:6379> auth 1234qwer
 OK
 127.0.0.1:6379> info replication
 # Replication
 role:master
 connected_slaves:2
 slave0:ip=192.168.42.132,port=6379,state=online,offset=280,lag=0
 slave1:ip=192.168.42.133,port=6379,state=online,offset=280,lag=0
 master_replid:a052149baf6e1dbb345f55ceb37476e95efca431
 master_replid2:0000000000000000000000000000000000000000
 master_repl_offset:280
 second_repl_offset:-1
 repl_backlog_active:1
 repl_backlog_size:1048576
 repl_backlog_first_byte_offset:1
 repl_backlog_histlen:280

The following information is displayed at the slave node (node2):

# First enter the redis container through docker
 docker exec -it redis-slave bash
 # After successful entry, log in to redis
 redis-cli -p 6379
 # Log in successfully, perform password authentication, and then view cluster configuration information
 127.0.0.1:6379> auth 1234qwer
 OK
 127.0.0.1:6379> info replication
 # Replication
 role:slave
 master_host:192.168.42.131
 master_port:6379
 master_link_status:up
 master_last_io_seconds_ago:10
 master_sync_in_progress:0
 slave_repl_offset:448
 slave_priority:100
 slave_read_only:1
 connected_slaves:0
 master_replid:a052149baf6e1dbb345f55ceb37476e95efca431
 master_replid2:0000000000000000000000000000000000000000
 master_repl_offset:448
 second_repl_offset:-1
 repl_backlog_active:1
 repl_backlog_size:1048576
 repl_backlog_first_byte_offset:15
 repl_backlog_histlen:434

The following information is displayed at the slave node (node3):

# First enter the redis container through docker
 docker exec -it redis-slave bash
 # After successful entry, log in to redis
 redis-cli -p 6379
 # Log in successfully, perform password authentication, and then view cluster configuration information
 127.0.0.1:6379> auth 1234qwer
 OK
 127.0.0.1:6379> info replication
 # Replication
 role:slave
 master_host:192.168.42.131
 master_port:6379
 master_link_status:up
 master_last_io_seconds_ago:3
 master_sync_in_progress:0
 slave_repl_offset:532
 slave_priority:100
 slave_read_only:1
 connected_slaves:0
 master_replid:a052149baf6e1dbb345f55ceb37476e95efca431
 master_replid2:0000000000000000000000000000000000000000
 master_repl_offset:532
 second_repl_offset:-1
 repl_backlog_active:1
 repl_backlog_size:1048576
 repl_backlog_first_byte_offset:1
 repl_backlog_histlen:532

Output the above information, indicating that the Redis master and slave configuration has been connected successfully. Next, verify the access data.

5.5. Verify access to data

An error will be reported when storing data on two slave nodes.

127.0.0.1:6379> set verify-key "Test Verify is Success"
(error) READONLY You can't write against a read only replica.

Because the slave node can only read data but not write data, it is necessary to write data at the master node. The master node can read and write data. Log in to the master node to store data:

127.0.0.1:6379> set verify-key "Test Verify is Success"
OK
127.0.0.1:6379> get verify-key
"Test Verify is Success"

Then read the data in two slave nodes respectively to see if it can be read successfully.

# Login 192.168.42.132 Node redis information
 127.0.0.1:6379> get verify-key
 "Test Verify is Success"

 # Login 192.168.42.133 Node redis information
 127.0.0.1:6379> get verify-key
 "Test Verify is Success"

Successfully obtained means that the master-slave copying is successful.

6. Configure Redis Sentinel

6.1. Main node (node1) configuration start

Enter:/root/docker/redis/sentinelDirectory, downloadFile and upload this directory, configure sentinel connection. File download address:/redis/redis/blob/5.0.4/

After the download is successful, modify the configuration file. Execute the commandvim /root/docker/redis/sentinel/

# Port number of sentry node
 port 26379
 bind 0.0.0.0
 logfile "/var/log/"
 # Turn off protected mode and allow external access. The Docker environment must be set to no
 protected-mode no
 # Disable Redis to run as a daemon
 daemonize no
 # Sentinel Work Directory
 dir /tmp
 sentinel monitor mymaster 192.168.42.131 6379 2
 # Analysis:
 # - mymaster: The name identification of the master node
 # - 49.235.180.130: IP address of the master node
 # - 6379: Port number of the master node
 # - 2: The number of sentry votes required to determine the master node failure (at least 2 sentries believe that the master node failure will fail over)
 #redis node password
 sentinel auth-pass mymaster 1234qwer
 # Analysis:
 # - mymaster: the corresponding master node name
 # - 1234qwer: Access password for Redis node
 # Subjective offline time, unit milliseconds
 sentinel down-after-milliseconds mymaster 10000
 # Analysis: If the main node cannot be connected within 10 seconds, the main node is considered to be subjectively offline

 # Synchronize configuration
 sentinel parallel-syncs mymaster 1
 # sentinel parallel-syncs: parallel synchronization configuration, mymaster: alias for master nodes, 1: number of slave nodes for parallel synchronization.
 #Effects and effects:
 #1. Controls the data synchronization behavior during failover. When the value is 1: the slave nodes are synchronized one by one. When the value is greater than 1: multiple slave nodes are synchronized in parallel.
 #Sample Scenario:
 # When parallel-syncs = 1: The main node fails, slave1 is selected as the new master node slave2 starts synchronizing with slave1, slave3 waits for slave2 synchronization to complete before synchronizing again. The process is slow but the pressure on the master node is low
 # When parallel-syncs = 2: The master node fails, slave1 is selected as the new master node, slave2 and slave3 are synchronized with slave1 at the same time, the process is faster, but the master node is under great pressure

 # Failover timeout
 sentinel failover-timeout mymaster 600000
 # Analysis: The timeout of failover is 600 seconds (10 minutes)

 sentinel deny-scripts-reconfig yes
 # Analysis: It is prohibited to modify sentinel configuration through scripts to improve security

 # The IP address announced to the public
 sentinel announcement-ip "192.168.42.131"
 # The port number announced to the public
 sentinel announcement-port 26379
 # Analysis:
 # - Used to declare the actual accessible address of the sentinel node in a Docker or NAT network environment
 # - Make sure other nodes can be properly connected to the sentinel node

Start Sentinel:

docker run -d -p 26379:26379 --restart=always --privileged=true --name redis-sentinel  -v /root/docker/redis/sentinel/:/etc/redis/ redis:5.0 redis-sentinel /etc/redis/

6.2. Start the node (node2) configuration

Download and modify the configuration file. Execute the commandvim /root/docker/redis/sentinel/

# The configuration file is the same as the sentinel configuration file started by the master node. You only need to change the sentinel address that is monitored externally.

 # The IP address announced to the public
 sentinel announcement-ip "192.168.42.132"
 # The port number announced to the public
 sentinel announcement-port 26379

Start Sentinel:

docker run -d -p 26379:26379 --restart=always --privileged=true --name redis-sentinel  -v /root/docker/redis/sentinel/:/etc/redis/ redis:5.0 redis-sentinel /etc/redis/

6.3. Start the node (node3) configuration

Download and modify the configuration file. Execute the commandvim /root/docker/redis/sentinel/

# The configuration file is the same as the sentinel configuration file started by the master node. You only need to change the sentinel address that is monitored externally.

 # The IP address announced to the public
 sentinel announcement-ip "192.168.42.133"
 # The port number announced to the public
 sentinel announcement-port 26379

Start Sentinel:

docker run -d -p 26379:26379 --restart=always --privileged=true --name redis-sentinel  -v /root/docker/redis/sentinel/:/etc/redis/ redis:5.0 redis-sentinel /etc/redis/

6.4. Verify Sentinel Cluster

First select a server to log in to Sentinel. You can execute the following commands on the master node or slave node to enter the Sentinel container:

docker exec -it redis-sentinel bash

Connect to Sentinel Client:

redis-cli -p 26379

View Sentinel Information:

# info sentinel
 127.0.0.1:26379> info sentinel
 # Sentinel
 sentinel_masters:1
 sentinel_tilt:0
 sentinel_running_scripts:0
 sentinel_scripts_queue_length:0
 sentinel_simulate_failure_flags:0
 master0:name=mymaster,status=ok,address=192.168.42.131:6379,slaves=2,sentinels=3

 #The above information is successfully configured

Check the sentinel information. If you find that the integration has been successful, you can verify the sentinel mode next. In Sentinel mode, when the master server goes down, the sentry will automatically vote for a master server from the node server, and this master server can also perform read and write operations.

Turn off the master node first:

docker stop redis-master

Check Sentinel information again:

127.0.0.1:26379> info sentinel
 # Sentinel
 sentinel_masters:1
 sentinel_tilt:0
 sentinel_running_scripts:0
 sentinel_scripts_queue_length:0
 sentinel_simulate_failure_flags:0
 master0:name=mymaster,status=ok,address=192.168.42.132:6379,slaves=2,sentinels=3

 # According to the information on the last line, it can be seen that the IP of the master node has changed.  From 192.168.42.131 -> 192.168.42.132

7. SpringBoot connects to Redis sentinel mode

7.1. Introduce dependencies

existAdd dependencies to:

<dependency>
    <groupId></groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
<dependency>
    <groupId></groupId>
    <artifactId>jedis</artifactId>
</dependency>

7.2. Configuration

spring:
    redis:
     #password
       password: 1234qwer
       timeout: 5000
       sentinel:
        # Corresponding to the configuration file information of the previous sentinel
         master: mymaster
        # The IP ports of the three sentinels
         nodes: 192.168.42.131:26379,192.168.42.132:26379,192.168.42.133:26379

7.3. Write test code

Create RedisConfig to use Jedis client connection

@Configuration
 public class RedisConfig extends CachingConfigurerSupport {
     @Value("${}")
     private int timeout;
     @Value("${}")
     private String password;
     // Add sentinel configuration
     @Value("${}")
     private String masterName;
     @Value("${}")
     private String sentinelNodes;
  
      @Bean
      public JedisSentinelPool jedisSentinelPool() {
         // parse sentinel nodes
         Set<String> sentinels = new HashSet<>((((",")));
         // Create a sentinel connection pool
         JedisSentinelPool sentinelPool = new JedisSentinelPool(masterName, sentinels, createPoolConfig(), timeout, password,0);
          ("Using Sentinel mode, master node name: {} JedisSentinelPool injection was successful!!", masterName);
          return sentinelPool;
      }
  
       private JedisPoolConfig createPoolConfig() {
         JedisPoolConfig jedisPoolConfig = new JedisPoolConfig();
         (50);
         (5);
         (10000);
         (true);
         return jedisPoolConfig;
     }
 }

Create a JedisTemplate operation Redis class

@Component
 @ConditionalOnClass()
 public class JedisTemplate {
  
     @Autowired(required = false)
     private JedisSentinelPool jedisSentinelPool;
  
    /**
      * Save data
      * @param key
      * @param value
      * @param seconds If it is less than or equal to 0, it is not limited to the duration
      */
     public final void setStringData(String key, String value, int seconds) {
         Jedis jedis = null;
         try {
             jedis = ();
             boolean flag = (key);
             if (flag) {
                 (key);
             }
             (key, value);
             if (seconds > 0) {
                 (key, seconds);
             }
         } catch (Exception e) {
             ();
         } finally {
             if (jedis != null) {
                 ();
             }
         }
     }

     /**
      * Get the string in redis based on key
      * @param key
      * @return
      */
     public String getStringData(String key) {
         String str = null;
         Jedis jedis = null;
         try {
             jedis = ();
             str = (key);
         } catch (Exception e) {
             ();
         } finally {
             if (jedis != null) {
                 ();
             }
         }
         return str;
     }
  
    /**
      * Delete a key
      * @param key
      */
     public void deleteKey(String key) {
         Jedis jedis = null;
         try {
             jedis = ();
             (key);
         } catch (Exception e) {
             ();
         } finally {
             if (jedis != null) {
                 ();
             }
         }
     }
 }

Create a RedisTestController to test the web controller

@RestController
 public class RedisTestController {
     @Autowired
     private JedisTemplate jedisTemplate;
  
     @GetMapping("/redis/test/{key}")
     public Response getRedisSentinelTest(@PathVariable("key") String key){
         String randomNumeric = (12);
         (key,"hahaha" + randomNumeric, 180);
         String stringData = (key);
         (stringData);
         return (stringData);
     }
 }

7.4. Start the project

2025-02-22 17:40:14.223 INFO -[:198]- Trying to find master from available Sentinels...
 2025-02-22 17:40:14.328 INFO -[:254]- Redis master running at 192.168.42.131:6379, starting Sentinel listeners...
 2025-02-22 17:40:14.345 INFO -[:188]- Created JedisPool to master at 192.168.42.131:6379
 2025-02-22 17:40:14.345 INFO -[:42]- Use Sentinel mode, master node name: mymaster JedisSentinelPool injection was successful!  !
 2025-02-22 17:40:48.609 INFO -[:173]- Starting ProtocolHandler ["http-nio-9090"]
 2025-02-22 17:40:48.630 INFO -[:220]- Tomcat started on port(s): 9090 (http) with context path ''
 2025-02-22 17:40:48.642 INFO -[:61]- Started App in 2.892 seconds (JVM running for 3.562)
 2025-02-22 17:41:05.914 INFO -[:173]- Initializing Spring DispatcherServlet 'dispatcherServlet'
 2025-02-22 17:41:05.915 INFO -[:525]- Initializing Servlet 'dispatcherServlet'
 2025-02-22 17:41:05.929 INFO -[:547]- Completed initialization in 14 ms

The calling interface is tested using the PostMan calling interface:http://localhost:9090/redis/test/1234, test whether the sentinel was created successfully.

8. Summary

At this point, the Redis sentry cluster is built. Redis Sentinel provides us with powerful monitoring and automatic repair functions, which enables Redis services to recover quickly and automatically and reduce manual intervention when faced with various failures. Looking back at the entire construction process, the construction is not particularly complicated, and there are only three main steps, including: 1. Configure Redis master-slave replication. 2. Set Redis sentinel node. 3. Verify high availability. Finally, I hope this article can help you understand the construction process of Redis Sentinel Mode and provide you with reference. If you encounter problems during the construction process, please discuss or consult Redis official documents to further optimize the configuration.

<Previous Next>