About Redis high availability scheme, see more is Keepalived, ZooKeeper scheme. Keepalived is in master/slave mode, meaning there’s always one to waste. The zooKeeper workload cost is high.

This paper mainly introduces the design of redis high availability scheme using official Sentinel.

Reading table:

  1. Redis Sentinel
  2. Three ways to failover message reception
  3. Overall flow chart
  4. conclusion

Redis Sentinel

Sentinel introduces

Sentinel is the official Redis high availability solution for clusters. Sentinel can be used in real projects to automate redis failover and reduce manual intervention. In addition, Sentinel also provides the notification of monitoring messages to the client, so that the client can determine the status of the server according to the message type and perform corresponding adaptation operations.

Here is a list of Sentinel’s main features:

  • Monitoring: Sentinel Continuously checks the status of the master and slave nodes in the cluster to determine whether they are alive.
  • Notification: Sentinel can notify system administrators or other program scripts via the API if a redis instance is found dead.
  • Automatic failover: If a master fails, Sentinel immediately starts failover and promotes a slave to master. Other slaves are reconfigured to point to the new master.
  • Configuration Provider: Sentinel notifications are valid and reliable for clients. The client will connect to Sentinel to request the address of the current master. In case of a failure, Sentinel will provide a new address to the client.

Sentinel configuration

Sentinel is essentially just a Redis server running in a special mode with different configurations to differentiate the services provided. Sentinel. Conf configuration:

// [monitor name] [IP] [port] [how many sentinels agree before failover] sentinel monitor myMaster 127.0.0.1 6379 2 ] sentinel down-after-milliseconds mymaster 60000 // [fail-over timeout] sentinel fail-over mymaster 180000 //[How many secondary servers can synchronize the new primary server simultaneously when failover is performed] sentinel parallel- Syncs myMaster 1Copy the code

Sentinel needs to use redis2.8 or above and is enabled as follows:

redis-sentinel sentinel.conf
Copy the code

After launch Sentinel will:

  • Send the info command to the monitored master every 10 seconds and get the master’s current information based on the response.
  • PING all Redis servers, including sentinel, once a second to determine whether the servers are online.
  • A message containing the current Sentinel master information is sent to all monitored master and slave servers at a frequency of 2 seconds.

In addition, it is recommended that sentinel should have at least 3 instances, and 2 instances can be agreed before sentinel can be transferred. 5 instances, configure 3 instances agree to the analogy.

Three ways to failover message reception

Once the Redis server sends a failure, Sentinel votes for a new master using raft algorithm. The failover process can fetch/subscribe to receive event messages via Sentinel’s API.

Search the Java friend public account, reply “backend interview”, send you a Java interview questions treasure book. PDF

The script to receive

  • During failover, a notification script can be specified to inform the system administrator of the status of the current cluster.
  • The script is allowed to run for a maximum of 60 seconds. If it times out, the script will be killed.
sentinel notification-script mymaster /var/redis/notify.sh 
Copy the code
  • After the failover period, configure the notification client script.
sentinel client-reconfig-script mymaster /var/redis/notifyReconfig.sh 
Copy the code

The client receives the packet directly

Sentinel’s failover message notifications use the Redis publication subscription. That is, all event information generated during failover is published through channels. For example, if we add a slave server, sentinel will post the messages added with slave to the “+slave” channel. The client only needs to subscribe to the “+slave” channel to receive the corresponding messages.

The message format is as follows: [Instance type] [Event Server name] [Server IP] [Server port] @[Master name] [IP] [Port]

<instance-type> <name> <ip> <port> @ <master-name> <master-ip> <master-port>
Copy the code

Example notification message format:

* // Subscription type, * that is, subscribe to all event messages. -sdown // Message type slave 127.0.0.1:6379 127.0.0.1 6379 @myMaster 127.0.0.1 6381Copy the code

Subscription message example:

using (RedisSentinel rs = new RedisSentinel(CurrentNode.Host, CurrentNode.Port))
            {
                var redisPubSub = new RedisPubSub(node.Host, node.Port);
                redisPubSub.OnMessage += OnMessage;
                redisPubSub.OnSuccess += (msg) =>{};
                redisPubSub.OnUnSubscribe += (obj) =>{};
                redisPubSub.OnError = (exception) =>{ };
                redisPubSub.PSubscribe("*");
            }
Copy the code

Indirect reception of services

This approach expands on the second option, which is that the application does not subscribe directly to Sentinel. A separate service does this, and the application side provides an API for the service to call back notifications. The benefits of this are:

  • Reduces the possibility of application listening failures.
  • The application side changes from active to passive, reducing coupling.
  • Improved performance, polling change callback.
  • Standalone services have higher scalability.

Such as:

1: To replace sentinel in the future, we only need to move the service without changing the application end.

2: An additional layer of daemon thread can be added to the service to proactively pull the REDis state, so as to ensure that even if sentinel does not take effect, the redis state can be detected in time and notified to the application end. This is extreme, of course, because Sentinel is also equipped with multiple nodes, and the probability of simultaneous failure is very low.

Example:

The application side provides a callback API to flush Redis connections in memory using this API logic.

http://127.0.0.1/redis/notify.api
Copy the code

When the independent service monitors the condition, it calls the API to notify the application:

The httprequest. Post (" http://127.0.0/redis/notify.api ");Copy the code

The overall design

The third is recommended, and the overall flow chart is as follows:

conclusion

The various Sentinel notification message types are documented, and the Redis client used in the project is on Github

Github.com/mushroomsir…

This article shares the landlord in the project to do Redis high availability experience, hope to help you. Zookeeper is recommended when human and material resources are sufficient. With only three or five guns, the next best thing is to meet the requirements with minimal cost and retain scalability.

Believe that there is no best architecture, only a more appropriate architecture.

  • Redis. IO/switchable viewer/sent…

Welcome to pay attention to the public number [code farming blossom] learn to grow together I will always share Java dry goods, will also share free learning materials courses and interview treasure book reply: [computer] [design mode] [interview] have surprise oh