Redis集群模式
Posted
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Redis集群模式相关的知识，希望对你有一定的参考价值。
参考技术A 拓扑结构介绍：192.168.43.70 redis01 （6379,6380）
192.168.43.71 redis02 （6379,6380）
192.168.43.72 redis03 （6379,6380）
OS : CentOS Linux release 7.7.1908 (Core)
Redis : redis-5.0.9.tar.gz
根据实验我们统计出MS对应关系,一共是3对MS("A","B","C")，分别为：
"A" -> 192.168.43.70:6379(Master) -> 192.168.43.71:6380(Slave)
"B" -> 192.168.43.71:6379(Master) -> 192.168.43.72:6380(Slave)
"C" -> 192.168.43.72:6379(Master) -> 192.168.43.70:6380(Slave)
---- ------ ----- --------- --------- -- ------ --
| -- | 6379 | 6380 |
---- ------ ----- --------- --------- -- ------ --
|192.168.43.70 | "A" | "C" |
|192.168.43.71 | "B" | "A" |
|192.168.43.72 | "C" | "B" |
---- ------ ----- --------- --------- -- ------ --
注意: 每台服务器启动2个Redis实例进行测试，端口分别为6379与6380。
参阅：《redis的安装配置》
[root@redis01 redis]# mkdir /usr/local/redis_6379
[root@redis01 redis]# mkdir /usr/local/redis_6380
[root@redis01 redis]# cat redis_6379.conf
bind 192.168.43.70 127.0.0.1
daemonize yes
port 6379
dir "/usr/local/redis_6379"
logfile "/var/log/redis_6379.log"
pidfile "/var/run/redis_6379.pid"
cluster-enabled yes
cluster-config-file redis_6379.conf
cluster-node-timeout 15000
appendonly yes
appendfilename aof-6379.aof
appendfsync everysec
no-appendfsync-on-rewrite yes
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
[root@redis01 redis]# cat redis_6380.conf
bind 192.168.43.70 127.0.0.1
daemonize yes
port 6380
dir "/usr/local/redis_6380"
logfile "/var/log/redis_6380.log"
pidfile "/var/run/redis_6380.pid"
cluster-enabled yes
cluster-config-file redis_6380.conf
cluster-node-timeout 15000
appendonly yes
appendfilename aof-6380.aof
appendfsync everysec
no-appendfsync-on-rewrite yes
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
[root@redis01 redis]#
[root@redis01 src]# ./redis-server ../redis_6379.conf
[root@redis01 src]# ./redis-server ../redis_6380.conf
[root@redis01 src]# ps -ef | grep redis
root 24438 1 0 16:14 ? 00:00:00 ./redis-server 192.168.43.70:6379 [cluster]
root 24443 1 0 16:14 ? 00:00:00 ./redis-server 192.168.43.70:6380 [cluster]
root 24450 1238 0 16:15 pts/0 00:00:00 grep --color=auto redis
[root@redis01 src]# netstat -anultp | grep redis
tcp 0 0 127.0.0.1:16379 0.0.0.0:* LISTEN 24438/./redis-serve
tcp 0 0 192.168.43.70:16379 0.0.0.0:* LISTEN 24438/./redis-serve
tcp 0 0 127.0.0.1:16380 0.0.0.0:* LISTEN 24443/./redis-serve
tcp 0 0 192.168.43.70:16380 0.0.0.0:* LISTEN 24443/./redis-serve
tcp 0 0 127.0.0.1:6379 0.0.0.0:* LISTEN 24438/./redis-serve
tcp 0 0 192.168.43.70:6379 0.0.0.0:* LISTEN 24438/./redis-serve
tcp 0 0 127.0.0.1:6380 0.0.0.0:* LISTEN 24443/./redis-serve
tcp 0 0 192.168.43.70:6380 0.0.0.0:* LISTEN 24443/./redis-serve
[root@redis01 src]#
选择任意一节点执行：
[root@redis01 src]# ./redis-cli --cluster create 192.168.43.70:6379 192.168.43.70:6380 \
> 192.168.43.71:6379 192.168.43.71:6380 192.168.43.72:6379 \
> 192.168.43.72:6380 --cluster-replicas 1
>>> Performing hash slots allocation on 6 nodes...
Master[0] -> Slots 0 - 5460
Master[1] -> Slots 5461 - 10922
Master[2] -> Slots 10923 - 16383
Adding replica 192.168.43.71:6380 to 192.168.43.70:6379
Adding replica 192.168.43.72:6380 to 192.168.43.71:6379
Adding replica 192.168.43.70:6380 to 192.168.43.72:6379
M: 21c8a195443f80d9a34714370e2bdad5fa1a302c 192.168.43.70:6379
slots:[0-5460] (5461 slots) master
S: cd878e102829bc46e8251a81a466438e13adbb41 192.168.43.70:6380
replicates 9a6f102b66cf56eca259ef4405a61c506c4dc2fb
M: 4fbd33604f9a7546a8f8b709427e4b3aeb757fc3 192.168.43.71:6379
slots:[5461-10922] (5462 slots) master
S: 47f5f3d12040ce9cf93c5fd6088be35d4c5b667f 192.168.43.71:6380
replicates 21c8a195443f80d9a34714370e2bdad5fa1a302c
M: 9a6f102b66cf56eca259ef4405a61c506c4dc2fb 192.168.43.72:6379
slots:[10923-16383] (5461 slots) master
S: df2d579ac711c222d53b38d7f2449dfd83a630b8 192.168.43.72:6380
replicates 4fbd33604f9a7546a8f8b709427e4b3aeb757fc3
Can I set the above configuration? (type 'yes' to accept): yes # 这里敲：yes
>>> Nodes configuration updated
>>> Assign a different config epoch to each node
>>> Sending CLUSTER MEET messages to join the cluster
Waiting for the cluster to join
.....
>>> Performing Cluster Check (using node 192.168.43.70:6379)
M: 21c8a195443f80d9a34714370e2bdad5fa1a302c 192.168.43.70:6379
slots:[0-5460] (5461 slots) master
1 additional replica(s)
M: 4fbd33604f9a7546a8f8b709427e4b3aeb757fc3 192.168.43.71:6379
slots:[5461-10922] (5462 slots) master
1 additional replica(s)
S: cd878e102829bc46e8251a81a466438e13adbb41 192.168.43.70:6380
slots: (0 slots) slave
replicates 9a6f102b66cf56eca259ef4405a61c506c4dc2fb
M: 9a6f102b66cf56eca259ef4405a61c506c4dc2fb 192.168.43.72:6379
slots:[10923-16383] (5461 slots) master
1 additional replica(s)
S: 47f5f3d12040ce9cf93c5fd6088be35d4c5b667f 192.168.43.71:6380
slots: (0 slots) slave
replicates 21c8a195443f80d9a34714370e2bdad5fa1a302c
S: df2d579ac711c222d53b38d7f2449dfd83a630b8 192.168.43.72:6380
slots: (0 slots) slave
replicates 4fbd33604f9a7546a8f8b709427e4b3aeb757fc3
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.
[root@redis01 src]#
[root@redis01 src]# ./redis-cli -c -p 6379 # -c 表示加入集群中
127.0.0.1:6379> cluster nodes
4fbd33604f9a7546a8f8b709427e4b3aeb757fc3 192.168.43.71:6379@16379 master - 0 1598949484973 3 connected 5461-10922
cd878e102829bc46e8251a81a466438e13adbb41 192.168.43.70:6380@16380 slave 9a6f102b66cf56eca259ef4405a61c506c4dc2fb 0 1598949485980 5 connected
9a6f102b66cf56eca259ef4405a61c506c4dc2fb 192.168.43.72:6379@16379 master - 0 1598949483000 5 connected 10923-16383
21c8a195443f80d9a34714370e2bdad5fa1a302c 192.168.43.70:6379@16379 myself,master - 0 1598949481000 1 connected 0-5460
47f5f3d12040ce9cf93c5fd6088be35d4c5b667f 192.168.43.71:6380@16380 slave 21c8a195443f80d9a34714370e2bdad5fa1a302c 0 1598949484000 4 connected
df2d579ac711c222d53b38d7f2449dfd83a630b8 192.168.43.72:6380@16380 slave 4fbd33604f9a7546a8f8b709427e4b3aeb757fc3 0 1598949485000 6 connected
127.0.0.1:6379>
127.0.0.1:6379> set test 'test redis cluster.'
-> Redirected to slot [6918] located at 192.168.43.71:6379
OK
192.168.43.71:6379> get test
"test redis cluster."
192.168.43.71:6379>
采用去中心化的思想，没有中心节点的说法，它使用hash slot方式将16348个hash slot覆盖到所有节点上，对每个key计算CRC16值，然后对16384取模，可以获取key对应的hash slot，
并在访问key的时候就去找他的hash slot在哪一个节点上，然后由当前访问节点从实际被分配了这个hash slot的节点去取数据，redis cluster中每个master都会持有部分slot，
比如有3个master，那么可能每个master持有5000多个hash slot。如果增加一个master，就将其他master的hash slot移动部分过去，减少一个master，就将它的hash slot移动到其他master上去。
节点之间使用轻量协议通信减少带宽占用性能很高，自动实现负载均衡与高可用，自动实现failover并且支持动态扩展，官方已经玩到可以1000个节点,实现的复杂度低。
在redis cluster写入数据的时候，其实是你可以将请求发送到任意一个master上去执行。但是，每个master都会计算这个key对应的CRC16值，然后对16384个hashslot取模，
找到key对应的hashslot，找到hashslot对应的master。如果对应的master就在自己本地的话，set mykey1 v1，mykey1这个key对应的hashslot就在自己本地，那么自己就处理掉了。
但是如果计算出来的hashslot在其他master上，那么就会给客户端返回一个moved error，告诉你，你得到哪个master上去执行这条写入的命令。
默认情况下，redis cluster的核心的理念，主要是用slave做高可用的，每个master挂一两个slave，主要是做数据的热备，还有master故障时的主备切换，实现高可用的。
redis cluster默认是不支持slave节点读或者写的，只有在Master出现故障的时候，Slave会自动转化为Master进行读写操作，跟我们手动基于replication搭建的主从架构不一样的。
跟集中式不同，不是将集群元数据（节点信息，故障，等等）集中存储在某个节点上，而是互相之间不断通信，保持整个集群所有节点的数据是完整的
集中式：好处在于，元数据的更新和读取，时效性非常好，一旦元数据出现了变更，立即就更新到集中式的存储中，其他节点读取的时候立即就可以感知到; 不好在于，所有的元数据的跟新压力全部集中在一个地方，可能会导致元数据的存储有压力
gossip：好处在于，元数据的更新比较分散，不是集中在一个地方，更新请求会陆陆续续，打到所有节点上去更新，有一定的延时，降低了压力; 缺点，元数据更新有延时，可能导致集群的一些操作会有一些滞后
每个节点都有一个专门用于节点间通信的端口，就是自己提供服务的端口号+10000，比如7001，那么用于节点间通信的就是17001端口
每隔节点每隔一段时间都会往另外几个节点发送ping消息，同时其他几点接收到ping之后返回pong
故障信息，节点的增加和移除，hash slot信息，等等
其内部中也需要配置主从，并且内部也是采用哨兵模式，如果有半数节点发现某个异常节点，共同决定更改异常节点的状态，如果改节点是主节点，
则对应的从节点自动顶替为主节点，当原先的主节点上线后，则会变为从节点。如果集群中的master没有slave节点，则master挂掉后整个集群就会进入fail状态，
因为集群的slot映射不完整。如果集群超过半数以上的master挂掉，无论是否有slave，集群都会进入fail状态。
参阅：
https://www.cnblogs.com/guolianyu/p/10345387.html
https://redis.io/topics/cluster-tutorial
https://www.cnblogs.com/mengchunchen/p/10059436.html
redis集群介绍与搭建（主从哨兵cluster集群）！
redis集群
一.Redis集群
1.简介
Redis集群是一个提供在多个Redis间节点间共享数据的程序集
Redis集群并不支持处理多个keys的命令,因为这需要在不同的节点间移动数据，从而达不到像Redis那样的性能，在高负载的情况下可能会导致不可预料的错误
Redis集群通过分区来提供一定程度的可用性,在实际环境中当某个节点宕机或者不可达的情况下可继续处理命令
2.Redis集群的优势
自动分割数据到不同的节点上
整个集群的部分节点失败戟者不可达的情况下能够继续处理命令
3.Redis集群的实现方法
有客户端分片
代理分片
服务器端分片
二.Redis三种模式原理介绍
Redis群集有三种模式：
主从同步/复制
哨兵模式
Cluster
1.主从模式
（1）通过持久化功能，redis保证了即使在服务器重启的情况下也不会丢失(或少量丢失)数据，因为持久化会把内存中的数据保存到硬盘上，重启会从硬盘上加载数据，但是由于数据是存储在一台服务器上的，如果这台服务器出现硬盘故障等问题，也会导致数据丢失。为了避免单点故障，通常的做法是将数据库复制多个副本以部署在不同的服务器上，这样即使有一台服务器出现故障，其他服务器依然可以继续提供服务，为此，redis提供了复制(replication)功能，可以实现当一台数据库中的数据更新后，自动将更新的数据同步到其他数据库上。
在复制的概念中，数据库分为两类，一类是主数据库(master)，另一类是从数据(slave)。主数据可以进行读写操作，当写操做导致数据变化时自动把数据同步给从数据库，而从数据库一般是只读的，并接收主数据同步过来的数据。一个主数据库可以拥有多个从数据库，而一个从数据库只能拥有一个主数据库
（2）主从复制流程
redis-主
① 缓存写入操作的命令
② 主redis派生一个子进程，触发RDB持久化，生成RDB快照文件
在触发RDB持久化到完成的过程中，客户端在持续写入，这段数据是保存在内存、缓存，这类的数据，靠AOF进行持久化
③ 在ADB持久化完成，生成.rdb文件后，主会将.rdb文件和aof持久化的缓存命令，全部交给redis-从服务
④ 在持续的主从同步过程中，客户端会持续进行写入命令操作，命令操作也会由主安按照一定的规则来同步给从服务器
redis-从
rdb文件和缓存的命令
基于以上部分进行加载以达到与master趋于一致的状态
2.哨兵模式(Sentinel)
（1）哨兵模式集群架构
哨兵是Redis集群架构中非常重要的一个组件，哨兵的出现主要是解决了主从复制出现故障时需要人为干预的问题
（2）哨兵模式主要功能
①集群监控：负责监控Redis的master和slave进程是否正常工作
②消息通知：如果某个Redis实例有故障，那么哨兵负责发送消息作为告警通知给管理员
③故障转移：如果master node(master角色)挂掉了，会自动转移到slave node上
④配置中心：如果故障转移发生了，通知client客户端新的master地址
使用一个或者多个哨兵(Sentinel)实例组成的系统，对redis节点进行监控在主节点出现故障的情况下，能将从节点中的一个从节点角色升级为主节点，进行故障转义，保证系统的可用性
（3）哨兵们监控整个系统节点的过程
①：哨兵之间相互进行命令连接目的为了在同一频道进行信息共享和监控
②：哨兵们向master发送命令连接和订阅连接(周期性)
③：哨兵10/s向master发送info,iR-M会回应哨兵本节点的信息状态+从节点的位置
④：哨兵收到回复之后,知晓R-S01 R-S02的位置
⑤：然后再向slaves发送命令连接和订阅连接(周期性) ,以达到监控整个集群的目的
（4）哨兵模式下的故障迁移
①：主观下线
哨兵(Sentinel)节点会每秒一次的频率向建立了命令连接的实例发送PING命令，如果在down-after-milliseconds毫秒内没有做出有效响应包括(PONG/ LOADING/MASTERDOWN)以外的响应，哨兵就会将该实例在本结构体中的状态标记为SRI_s_DOWN主观下线
②：客观下线
当一个哨兵节点发现主节点处于主观下线状态是，会向其他的哨兵节点发出询问，该节点是不是已经主观下线了。如果超过配置参数quorum个节点认为是主观下线时，该哨兵节点就会将自己维护的结构体中该主节点标记为SRIO DOWN客观下线询问命令SENTINEL is-master-down-by-addr
③：master选举
在认为主节点客观下线的情况下，哨兵节点节点间会发起一.次选举，命令为:SENTINEL is-master-down-by-addr只是runid这次会将自己的runid带进去， 希望接受者将自己设置为主节点。如果超过半数以.上的节点返回将该节点标记为leacer的情况下，会有该leader对故障进行迁移
⑥：故障转移
在从节点中挑选出新的主节点
通讯正常
优先级排序
优先级相同时选择offset最大的( 最接近master的)
将该节点设置成新的主节点SLAVEOFnoone,并确保在后续的INGO命令时该节点返回状态为master
将其他的从节点设置成从新的主节点的从节点，SLAVEQF命令
将旧的主节点变成新的主节点的从节点
3.Cluster集群模式
主节点负责读写请求和集群信息的维护，从节点只进行主节点数据和状态信息的复制
作用
（1）数据分区
数据分区( 或称数据分片)是集群最核心的功能( 分布式)
集群将数据分散到多个节点，一方面突破了Redis
单机内存大小的限制，存储容量大大增加，另一方面每个主节点都可以对外提供读服务和写服务，大大提高了集群的响应能力
Redis单机内存大小受限问题，在介绍持久化和主从复制时都有提及
例如，如果单机内存太大，bgsave 和bgrewriteaof的fork操作可能导致主进程阻塞，主从环境下主机切换时可能导致从节点长时间无法提供服务，全量复制阶段主节点的复制缓冲区可能溢出
（2）高可用
集群支持主从复制(模式)和主节点的自动故障转移(与哨兵类似)，当任意节点发送故障时，集群仍然可以对外提供服务
（3）数据分片
Redis 集群引入了哈希槽的概念，有16384 个哈希槽(编号0~16383)
集群的每个节点负责一部分哈希槽，每个Key通过CRC16校验后对16384取余来决定放置哪个哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存
取操作
以3个节点组成的集群为例:
节点A包含0~5469号的哈希槽
节点B包含5461~10922号的哈希槽
节点C包含10923~16383 号的哈希槽
三.搭建主从复制
1.实验准备
一主2从
master：192.168.206.166
slave1:192.168.206.177
slave2:192.168.206.188
3台服务器做时间同步
3台服务器分别安装redis数据库
2.修改配置文件
（1）master节点
[root@redis-master ~]# vim /etc/ redis/ 6379. conf
70 bind 0.0.0.0 #修改监听地址为0.0.0.0
137 daemonize yes #开启守护进程
172 logfile /var/log/redis_6379.log #指定日志文件目录
264 dir /var/lib/redis/6379 #指定工作目录
700 appendonly yes #开启AOF持久化功能
[root@redis-master ~]# /etc/init.d/redis_6379 restart
Stopping ...
Waiting for Redis to shutdown ...
Redis stopped
Starting Redis server...
（2）slave1、2节点
[root@redis-slave1 ~]# vim /etc/redis/6379.conf
70 bind 0.0.0.0 #修改监听地址为0.0.0.0
137 daemonize yes #开启守护进程
172 logfile /var/log/redis_6379.log #指定日志文件目录
264 dir /var/lib/redis/6379 #指定工作目录
288 replicaof 192.168.206.166 6379 #添加一条指定要同步的Master节点IP和端口
700 appendonly yes #开启AOF持久化功能
[root@redis-slave1 ~]# /etc/init.d/redis_6379 restart
Stopping ...
Redis stopped
Starting Redis server...
[root@redis-slave1 ~]#
3.验证主从效果
（1）查看日志
[root@redis-master ~]# cat /var/log/redis_6379.log
82151:C 14 Aug 2021 23:40:51.418 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
82151:C 14 Aug 2021 23:40:51.418 # Redis version=5.0.7, bits=64, commit=00000000, modified=0, pid=82151, just started
82151:C 14 Aug 2021 23:40:51.418 # Configuration loaded
82153:M 14 Aug 2021 23:40:51.420 * Increased maximum number of open files to 10032 (it was originally set to 1024).
_._
_.-``__ ''-._
_.-`` `. `_. ''-._ Redis 5.0.7 (00000000/0) 64 bit
.-`` .-```. ```\\/ _.,_ ''-._
( ' , .-` | `, ) Running in standalone mode
|`-._`-...-` __...-.``-._|'` _.-'| Port: 6379
| `-._ `._ / _.-' | PID: 82153
`-._ `-._ `-./ _.-' _.-'
|`-._`-._ `-.__.-' _.-'_.-'|
| `-._`-._ _.-'_.-' | http://redis.io
`-._ `-._`-.__.-'_.-' _.-'
|`-._`-._ `-.__.-' _.-'_.-'|
| `-._`-._ _.-'_.-' |
`-._ `-._`-.__.-'_.-' _.-'
`-._ `-.__.-' _.-'
`-._ _.-'
`-.__.-'
[root@redis-master ~]# redis-cli info replication
# Replication
role:master #角色是master
connected_slaves:2 #连接从服务器2个
slave0:ip=192.168.206.177,port=6379,state=online,offset=1638,lag=1
slave1:ip=192.168.206.188,port=6379,state=online,offset=1638,lag=0 #master启动时生成的40位16进制的随机字符串，用来标识master节点
master_replid:6c2c582dacb6686c551ffc405c6561b1d7f9e44c #切换主从的时候master节点标识会有更改
master_replid2:0000000000000000000000000000000000000000 #复制流中的一个偏移量，master处理完写入命令后，会把命令的字节长度做累加记录，统计在该字段。该字段也是实现部分复制的关键字段
master_repl_offset:1638 #无论主从，以下内容都表示自己上次主实例repid1和复制偏移量;用于兄弟实例或级联复制，主库故障切换
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:1638
（2）master创建aaa键
[root@redis-master ~]# redis-cli
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> set aaa 11
OK
127.0.0.1:6379> get aaa
"11"
127.0.0.1:6379>
（3）slave查看aaa键
[root@redis-slave1 ~]# redis-cli
127.0.0.1:6379> keys *
1) "aaa"
127.0.0.1:6379> get aaa
"11"
127.0.0.1:6379>
[root@redis-slave2 ~]# redis-cli
127.0.0.1:6379> keys *
1) "aaa"
127.0.0.1:6379> get aaa
"11"
127.0.0.1:6379>
四.搭建哨兵模式
哨兵的启动依赖于主从模式，所以须把主从模式安装好的情况下再去做哨兵模式，所有节点上都需要部署哨兵模式，哨兵模式会监控所有的Redis 工作节点是否正常。
1.实验准备
以主从模式为基础，先搭建主从模式，搭建步骤如上面介绍一样
master：192.168.206.166
slave1:192.168.206.177
slave2:192.168.206.188
2.修改配置文件，每一台服务器均修改
[root@redis-master ~]# vim /opt/redis-5.0.7/sentinel.conf
17 protected-mode no #关闭保护模式
21 port 26379 #Redis哨兵默认的监听端口
26 daemonize yes #开启守护进程
36 logfile "/var/log/sentinel.log" #指定日志存放路径
65 dir /var/lib/redis/6379 #指定数据库存放路径
84 sentinel monitor mymaster 192.168.206.166 6379 2 #指定哨兵节点；2：至少需要2个哨兵节点同意，才能判定主节点故障并进行故障转移
113 sentinel down-after-milliseconds mymaster 30000 #判定服务器down掉的时间周期，默认30000毫秒 (30秒)
146 sentinel failover- timeout mymaster 180000 #故障节点的最大超时时间为180000 (180秒)
3.启动哨兵模式
先启动master节点，再启动slave节点
[root@redis-master ~]# cd /opt/redis-5.0.7/
[root@redis-master redis-5.0.7]# redis-sentinel sentinel.conf &
[1] 83298
[root@redis-master redis-5.0.7]#
[root@redis-slave1 ~]# cd /opt/redis-5.0.7/
[root@redis-slave1 redis-5.0.7]# redis-sentinel sentinel.conf &
[1] 68923
[root@redis-slave1 redis-5.0.7]#
[root@redis-slave2 ~]# cd /opt/redis-5.0.7/
[root@redis-slave2 redis-5.0.7]# redis-sentinel sentinel.conf &
[1] 104237
[root@redis-slave2 redis-5.0.7]#
4.查看哨兵信息
[root@redis-master redis-5.0.7]# redis-cli -p 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.206.166:6379,slaves=2,sentinels=3
[1]+ 完成 redis-sentinel sentinel.conf
[root@redis-master redis-5.0.7]#
5.模拟故障
查看redis进程，并杀死进程，模拟故障
[root@redis-master ~]# netstat -antp | grep redis
[root@redis-master ~]# kill -9 82756
[root@redis-master ~]# netstat -antp | grep redis
6.查看验证
查看日志
[root@redis-master ~]# tail -f /var/log/sentinel.log
83299:X 15 Aug 2021 01:14:40.875 # +sdown master mymaster 192.168.206.166 6379
83299:X 15 Aug 2021 01:14:40.896 # +new-epoch 1
83299:X 15 Aug 2021 01:14:40.896 # +vote-for-leader a3a29dfa08bab9945a7afb9a5739752ffeb635ad 1
83299:X 15 Aug 2021 01:14:40.966 # +odown master mymaster 192.168.206.166 6379 #quorum 3/2
83299:X 15 Aug 2021 01:14:40.966 # Next failover delay: I will not start a failover before Sun Aug 15 01:20:40 2021
83299:X 15 Aug 2021 01:14:41.747 # +config-update-from sentinel a3a29dfa08bab9945a7afb9a5739752ffeb635ad 192.168.206.188 26379 @ mymaster 192.168.206.166 6379
83299:X 15 Aug 2021 01:14:41.747 # +switch-master mymaster 192.168.206.166 6379 192.168.206.177 6379
83299:X 15 Aug 2021 01:14:41.747 * +slave slave 192.168.206.188:6379 192.168.206.188 6379 @ mymaster 192.168.206.177 6379
83299:X 15 Aug 2021 01:14:41.747 * +slave slave 192.168.206.166:6379 192.168.206.166 6379 @ mymaster 192.168.206.177 6379
83299:X 15 Aug 2021 01:15:11.793 # +sdown slave 192.168.206.166:6379 192.168.206.166 6379 @ mymaster 192.168.206.177 6379
[root@redis-slave1 redis-5.0.7]# watch -n 1 redis-cli -p 26379 info sentinel
Every 1.0s: redis-cli -p 26379 info sentinel Sun Aug 15 01:41:55 2021
# 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=sdown,address=192.168.206.166:6379,slaves=2,sentinels=3
Every 1.0s: redis-cli -p 26379 info sentinel Sun Aug 15 01:41:55 2021
# 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=odown,address=192.168.206.166:6379,slaves=2,sentinels=3
status=sdown #s表示主观下线
status=odown #o即objectively客观下线
sdown到odown到ok的状态时间比较快,ok后切换到177
五.搭建集群
redis的集群一般需要6个节点，3主3从。方便起见，这里所有节点在同一台服务器上模拟
以端口号进行区分: 3个主节点端口号: 6001/6002/6003， 对应的从节点端口号: 6004/ 6005/ 6006
1.创建6个端口工作目录
[root@redis-cluster redis]# mkdir -p redis-cluster/redis6001..6
[root@redis-cluster redis]# cd redis-cluster/
[root@redis-cluster redis-cluster]# ls
redis6001 redis6002 redis6003 redis6004 redis6005 redis6006
用脚本复制配置文件
[root@redis-cluster redis-cluster]# vim /opt/redis.sh
#!/bin/bash
for i in 1..6
do
cp /opt/redis-5.0.7/redis.conf /etc/redis/redis-cluster/redis600$i
cp /opt/redis-5.0.7/src/redis-cli /opt/redis-5.0.7/src/redis-server /etc/redis/redis-cluster/redis600$i
done
[root@redis-cluster redis-cluster]# sh -x /opt/redis.sh
+ for i in '1..6'
+ cp /opt/redis-5.0.7/redis.conf /etc/redis/redis-cluster/redis6001
+ cp /opt/redis-5.0.7/src/redis-cli /opt/redis-5.0以上是关于Redis集群模式的主要内容，如果未能解决你的问题，请参考以下文章