table of Contents
The following summarizes the comprehensive knowledge notes and interview questions about Redis, which is convenient for your own review and hopes to be helpful to everyone.
| Serial number | content | link address |
|---|---|---|
| 1 | Redis basic knowledge, stand-alone version installation, data type introduction (old version) | https://blog.csdn.net/weixin_43246215/article/details/107474283 |
| 2 | Redis common commands, configuration file introduction, data persistence method, cluster construction (old version) | https://blog.csdn.net/weixin_43246215/article/details/107947562 |
| 3 | Detailed explanation of five common data types and three special data types of Redis | https://blog.csdn.net/weixin_43246215/article/details/108041739 |
| 4 | Redis basic transaction operations and using Redis to achieve optimistic locking | https://blog.csdn.net/weixin_43246215/article/details/108045931 |
| 5 | Use JedisAPI to operate Redis and Jedis to implement Redis transactions | https://blog.csdn.net/weixin_43246215/article/details/108067542 |
| 6 | Redis configuration file detailed (Chinese) | https://blog.csdn.net/weixin_43246215/article/details/108068245 |
| 7 | Two ways of Redis data persistence and Redis to achieve subscription publishing | https://blog.csdn.net/weixin_43246215/article/details/108068797 |
| 8 | Redis's pseudo cluster construction and principle of master-slave replication | https://blog.csdn.net/weixin_43246215/article/details/108069472 |
| 9 | Introduction to the use of Sentinel mode and related configuration in Redis | https://blog.csdn.net/weixin_43246215/article/details/108088179 |
| 10 | Cache penetration, cache breakdown, and cache avalanche in Redis (theoretical knowledge) | https://blog.csdn.net/weixin_43246215/article/details/108089026 |
| 11 | Spring integrates Redis to implement query caching and synchronous caching | pending upgrade |
| 12 | SpringBoot integrates Redis and custom Redis Template | https://blog.csdn.net/weixin_43246215/article/details/108476328 |
| 13 | Redis common interview questions | https://blog.csdn.net/weixin_43246215/article/details/108090095 |
| 14 | … | pending upgrade |
Overview
The method of master-slave switching technology is: when the master server goes down, a slave server (Slave) needs to be manually switched to the master server (Master), which requires manual intervention, time-consuming and laborious, and will cause the service to be unavailable for a period of time .
Manual adjustment is not a recommended way, more often we have limited consideration of the Sentinel mode. Redis has officially provided the Sentinel architecture since 2.8 to solve this problem.
The sentinel mode is equivalent to the automatic version of seeking to usurp the throne. It can monitor whether the host is faulty in the background. If it fails, it will automatically switch from the library to the main library according to the number of votes.
Single sentinel mode
The sentinel mode is a special mode. First, Redis provides the sentinel command. The sentinel is an independent process . As a process, it will run independently. The principle is that the sentinel sends a command and waits until the Redis server responds to monitor the number of operations. A Redis instance.
The two functions of the sentinel:
- By sending commands, the Redis server returns to monitor its running status, including the master server and the slave server.
- When the sentinel detects that the master is down, it will automatically switch the slave to the master through the voting mechanism, and then notify other slave servers through the publish and subscribe mode, modify the configuration file, and let them switch the host.
Multi-sentinel mode
There may be some problems when a single sentinel process monitors the Redis server (for example, the sentinel hangs up), for this we can use multiple sentinels to monitor. Monitoring will also be carried out between each sentinel, thus forming a multi-sentinel mode. Since a sentinel requires one process, a sentinel cluster needs at least three sentinels to ensure robustness, so it is necessary to configure multiple sentinels, starting with 6 processes.
In multi-sentinel mode, what happens if the host goes down?
Assuming that the main server is down, Sentinel 1 detects this result first, but the system will not immediately perform the re-election and filover process, because only Sentinel 1 subjectively believes that the main server is unavailable, and this phenomenon becomes subjective offline . When the following sentinels also detect that the main server is not connected, and the number reaches a certain value (two sentinels out of the 3 sentinels detect that the host cannot be used, then it is considered that the host is down), then there will be A vote for the master election is performed on the slaves. The result of the voting is initiated by any sentinel, and then a failover (failover) operation is performed. After the election of the new master is successful, the slave will be switched to the master, and then it will be published and subscribed. Mode (all services are monitored by sentinels), allowing each sentinel to switch the host from the server that it monitors, and this process becomes an objective offline .
Test single sentinel
The cluster is still the pseudo-cluster used before (one master and two slaves, single machine with multiple servers)
1. Configure the sentinel configuration file sentinel.conf
There is a redis.sentinelfile in the bin directory of Redis . This file is used to start the sentinel's startup file. Next, we need a sentinel's configuration file. We need to create it ourselves.
Use it in the bin directory vim sentinel.confto create a file and write the following command:
# sentinel monitor 被监控的名称 host port 1
sentinel monitor myredis 192.168.15.133 6379 1
The number 1 behind it means that if the host is down, Slave will vote to see who becomes the new host, and the one with the most votes will become the host. This 1 is equivalent to a host logo.
Note : The above configuration is the most critical configuration to open the sentry. The spelling cannot be wrong. If you write it wrong or miss it, it will fail to start the sentry.
2. Start the sentry
After configuring the files of the first step, first we still use a pseudo-cluster with one master and two slaves, port 79 is the host, port 80 and port 81 are 79 slaves, and all three servers are started and connected to Redis. Fourth One is used to start the command test.
Execute the command in the fourth window: ./redis.sentinel sentinel.conf
after executing the start sentinel, there is related port 26379 as shown in the figure above, and output which is the master node, the number of slaves under the master node, and continuously monitor the host and slave after starting the sentry If the host or slave is down or there is a problem, the corresponding information will be output and the corresponding operation will be performed.
3. Assuming that the host 6379 is down (disconnected), what operations will the sentry do?
If the master node Master disconnects, the sentry will randomly select a server from the machine through the voting mechanism at this time.
- Host 6379 hangs:
- The sentinel log will output the following information:
When the host hangs up, the sentry will detect that the host is disconnected, and then it will check again. If it is still disconnected, then it will start the election among the slaves and elect a new host. Then perform a failover fileover. In the above test, the slave 6381 is elected as the master, and other servers are set as the slaves of the new master. The disconnected master is also set as the slave of the new master. From the last three lines The code can know that if the host is connected at this time, it will also be set as the slave of the new host, which is the sentinel mode.
Pros and cons of sentinel mode
advantage
- Sentinel cluster, based on the master-slave replication model, has all the advantages of master-slave configuration.
- The master and slave can be switched, the failure can be transferred, and the availability of the system will be better.
- The sentinel mode is an upgraded version of the master-slave mode, which is more robust from receiving to automatic.
Disadvantage
- Redis is not easy to expand online. Once the cluster capacity reaches the upper limit, online expansion will be very troublesome.
- The configuration of sentinel mode is troublesome, and there are many options.
All configurations in the sentinel mode configuration file
# Example sentinel.conf
# 哨兵sentinel实例运行的端口 默认是26379，如果有哨兵集群，我们还需要配置每个哨兵端口
port 26379
#哨兵sentinel的工作目录
dir /tmp
The following is the key point of the sentinel configuration
#哨兵 sentine1 监控的redis主节点的 ip port
# master-name ，可以自己命名的主节点名字 只能由字母A-Z、数字0-9、这三个字符" . - _ "组成。
# quorum配置多少个sentine1哨兵统- -认为master主节点失联那么这时客观上认为主节点失联了
# sentine1 monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 2
#当在Redis实例中开启了requirepass foobared 授权密码这样所有连接kedis实例的客户端都要提供密码
#设置哨兵sentinel连接主从的密码注意必须为主从设置- - 样的验证密码
# sentine1 auth-pass <master-name> <password>
sentine1 auth-pass mymaster MySUPER--secret-0123passwOrd
#指定多少毫秒之后主节点没有应答哨兵sentine1 此时哨兵主观上认为主节点下线默认30秒
# sentinel down-after-mi 11i seconds <master-name> <mi 11iseconds>
sentine1 down-after-mi 11iseconds mymaster 30000
#这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行同步，这个数字越小，完成fai lover所需的时间就越长，但是如果这个数字越大，就意味着越多的slave因为replication而 不可用。可以通过将这个值设为1来保证每次只有一个slave处于不能处理命令请求的状态。
# sentine1 paralle1-syncs <master-name> <numslaves>
sentine1 paralle1-syncs mymaster 1
#故障转移的超时时间failover-timeout 可以用在以下这些方面:
#1.同一个sentine1对同一 个master两次fai lover之间的间隔时间。
#2.当一个slave从一 个错误的master那里同步数据开始计算时间。直到s1ave被纠正为向正确的master那里同步数据时。
#3.当想要取消一个正在进行的failover所需要的时间。
#4.当进行failover时，配置所有s1aves指向新的master所需的最大时间。不过，即使过了这个超时，slaves 依然会被正确配置为指向master,但是就不按parallel-syncs所配置的规则来了
#默认三分钟
# sentine1 failover-timeout <master-name> <milliseconds>
sentine1 fai lover-ti meout mymaster 180000
# SCRIPTS EXECUTION
#配置当某一事件发生时所需要执行的脚本，可以通过脚本来通知管理员，例如当系统运行不正常时发邮件通知相关人员。
#对于脚本的运行结果有以下规则:
#若脚本执行后返回1，那么该脚本稍后将会被再次执行，重复次数目前默认为10
#若脚本执行后返回2，或者比2更高的一个返回值，脚本将不会重复执行。
#如果脚本在执行过程中由于收到系统中断信号被终止了，则同返回值为1时的行为相同。
#一个脚本的最大执行时间为60s，如果超过这个时间，脚本将会被-一个SIGKILL信号终止，之后重新执行。
#通知型脚本:当sentine1有任何警告级别的事件发生时(比如说redis实例的主观失效和客观失效等等)，将会去调用这个脚本，这时这个脚本应该通过邮件，SMS等 方式去通知系统管理员关于系统不正常运行的信息。调用该脚本时，将传给脚本两个参数，一 个是事件的类型，一个是事件的描述。如果sentine1. conf配置文件中配置了这个脚本路径，那么必须保证这个脚本存在于这个路径，并且是可执行的，否则sentine1无法正常启动成功。
#通知脚本
# she11编程
# sentine1 notification-script <master-name> <script-path>
sentine1 notificati on-script mymaster /var/redis/notify. sh
#客户端重新配置主节点参数脚本
#当一个master由于failover而发生改变时，这个脚本将会被调用，通知相关的客户端关于master地址已经发生改变的信息。
#以下参数将会在调用脚本时传给脚本:
# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
#目前<state>总是“failover",
# <role>是“Teader"或者"observer"中的-一个。
#参数from-ip， from-port， to-ip，to-port是用来和旧的master和新的master(即旧的s lave)通信的
#这个脚本应该是通用的，能被多次调用，不是针对性的。
# sentine1 client-reconfig-script <master-name> <script-path>
sentine1 client-reconfig-script mymaster /var/redis/reconfig.sh #一般都是由运维来配置!