「这是我参与11月更文挑战的第17天，活动详情查看：2021最后一次更文挑战」。

哨兵模式（sentinel）

Sentinel(哨兵) 是用于监控redis集群中Master状态的工具，是Redis高可用性解决方案，sentinel可以监视一个或多个redis master服务，以及这些master服务的所有从服务；当某个master服务下线时，自动将该master下的某个从服务升级为master服务替代已下线的master服务继续处理请求。一般建议sentinel采取奇数台，因为选举必须超过半数才有效。

哨兵模式搭建

创建sentinel文件夹，将sentinel.conf复制进去，我们准备搭建三个哨兵的场景，再复制两份sentinal配置文件

接下来对配置文件进行配置

yaml复制代码
bind 0.0.0.0

protected-mode no

port 26379

daemonize yes

sentinel monitor mymaster 127.0.0.1 6378 3 //设置 主节点名称 ip 端口 参加选举的哨兵数

sentinel failover-timeout mymaster 3000 //主从切换超时时间

sentinel down-after-milliseconds mymaster 3000 // sentinel心跳检测3秒内无响应，视为挂掉，开始切换其他从为主。

其他两个也按上述配置，更改个端口号即可

然后进行启动,启动命令如下：

1 2	bash复制代码 ./redis-server ../sentinel/sentinel-26377.conf --sentinel

当我们把主节点强制下线，我们来看下从节点的情况

可以看到经过选举，6378的从节点变为了主节点

6377从节点指定的主节点变为了6378

当我们把原来的那个主节点进行重启

可以看到6379自动就变为了从节点

哨兵模式原理

工作方式

每个sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他Sentinel实例发送一个PING命令
如果一个实例距离最后一次有效回复PING命令时间超过own-after-milliseconds选项所指定的值，则这个实例会被Sentine标记为主观下线。
如果一个Master被标记为主观下线，则正在监视这个Master的所有sentinel要以每秒一次的频率确认Master的确进入主观下线状态。
一般情况下，每个Sentinel 会以每10秒一次的频率向它已知的所有Master，Slave发送 INFO 命令
当Master被sentinel标记为客观下线，sentinel向下线的master的所有salve发送info命令的频率会从10秒一次改为1秒一次。
若没有足够数量sentinel同意master下线，master客户下线状态会被移除。

三个定时任务

sentinel在内部有3个定时任务

每10秒每个sentinel会对master和slave执行info命令，这个任务达到两个目的：

发现slave节点

确认主从关系

每2秒每个sentinel通过master节点的channel交换信息（pub/sub）。master节点上有一个发布订阅的频道(sentinel:hello)。sentinel节点通过__sentinel__:hello频道进行信息交换(对节点的”看法”和自身的信息)，达成共识。
每1秒每个sentinel对其他sentinel和redis节点执行ping操作（相互监控），这个其实是一个心跳检测，是失败判定的依据。

主观下线

所谓主观下线（Subjectively Down，简称 SDOWN）指的是单个Sentinel实例对服务器做出的下线判断，即单个sentinel认为某个服务下线（有可能是接收不到订阅，之间的网络不通等等原因）。主观下线就是说如果服务器在down-after-milliseconds给定的毫秒数之内，没有返回 Sentinel 发送的 PING 命令的回复，或者返回一个错误，那么 Sentinel 将这个服务器标记为主观下线（SDOWN ）。

sentinel会以每秒一次的频率向所有与其建立了命令连接的实例（master，从服务，其他sentinel）发ping命令，通过判断ping回复是有效回复，还是无效回复来判断实例时候在线（对该sentinel来说是“主观在线”）。

sentinel配置文件中的down-after-milliseconds设置了判断主观下线的时间长度，如果实例在down-after-milliseconds毫秒内，返回的都是无效回复，那么sentinel回认为该实例已（主观）下线，修改其flags状态为SRI_S_DOWN。如果多个sentinel监视一个服务，有可能存在多个sentinel的down-after-milliseconds配置不同，这个在实际生产中要注意。

客观下线

客观下线（ODOWN）指的是多个sentinel实例在对同一个服务器做出SDOWN判断，并且通过 sentinel

is-master-down-by-addr 命令互相交流后，得出服务器下线判断，然后会开启failover。

客户下线要满足足够数量的sentinel都将一个服务器标记为主观下线之后，才会被标记我客观下线。

这个数量是由

entinel monitor 这里面的quorum来设置，quorum这个参数是进行客观下线的一个依据，意思是至少有quorum个sentinel主观认为master有故障，才会对master进行下线和故障转移，一般来说quorum的值设置为sentinel个数的二分之一加1，例如3个sentinel就设置2。

选举领头羊

一个redis服务被判断为客观下线，多个监视该服务的sentinel协商，选举一个领头sentinel，对该redis服务进行故障转移，选举领头sentinel遵循以下规则：

1）所有的sentinel都有公平被选举成领头的资格。

2）所有的sentinel都有且只有一次将某个sentinel选举成领头的机会（在一轮选举中），一旦选举某个sentinel为领头，不能更改。

3）sentinel设置领头sentinel是先到先得，一旦当前sentinel设置了领头sentinel，以后要求设置sentinel为领头请求都会被拒绝。

4）每个发现服务客观下线的sentinel，都会要求其他sentinel将自己设置成领头。

5）当一个sentinel（源sentinel）向另一个sentinel（目sentinel）发送is-master-down-by-addr ip port current_epoch runid命令的时候，runid参数是sentinel运行id，就表示源sentinel要求目标sentinel选举其为领头。

6）源sentinel会检查目标sentinel对其要求设置成领头的回复，如果回复的leader_runid和leader_epoch为源sentinel，表示目标sentinel同意将源sentinel设置成领头。

7）如果某个sentinel被半数以上的sentinel设置成领头，那么该sentinel既为领头。

8）如果在限定时间内，没有选举出领头sentinel，暂定一段时间，再选举。

自动故障转移机制

sentinel保存了主节点的所有从节点信息，领头sentinel按照如下规则从服务列表中选出新的主节点：

过滤掉主观下线的节点
选择slave-priority(权重值，可在配置文件中进行设定)最高的节点，如果有则返回没有就继续选择
选择出复制偏移量最大的节点，因为复制偏移量越大数据复制的越完整，如果有就返回，没有就继续。
选择run_id最小的节点。

通过slaveof no one 命令，让选出来的从节点成为主节点；并通过salveof命令让其他节点成为其从节点。当已下线的服务重新上线，sentinel会向其发送slaveof命令，让其成为新的从节点。

redis集群

集群搭建

创建cluster文件夹，将redis的配置文件放入进去

arduino复制代码
daemonize yes //开启守护线程

logfile "6379.log"

dbfilename "dump-6379.rdb"

protected-mode no //关闭代表外部网络可以直接访问，开启需配置bind ip或者访问密码

port 6379

bind 0.0.0.0

pidfile /var/run/redis_6379.pid //pidfile文件

cluster-enabled yes //开启集群

cluster-config-file nodes_6379.conf //集群的配置 配置文件首次启动自动生成

cluster-node-timeout 15000 //请求超时，默认15秒

这个配置完成后，再拷贝两个配置文件，修改端口号，其他不变

启动节点

bash复制代码
./redis-server ../cluster/redis-6380-master.conf

./redis-server ../cluster/redis-6381-master.conf

./redis-server ../conf/redis-6379-master.conf

接着要启动集群，启动集群要依赖ruby，所以先安装ruby

安装ruby

wget cache.ruby-lang.org/pub/ruby/2.…

tar -xvf ruby-2.3.1.tar.gz

./configure –prefix=/usr/local/ruby

make

make install

cd /usr/local/ruby

cp bin/ruby /usr/local/bin

cp bin/gem /usr/local/bin

wget rubygems.org/downloads/r…

gem install ./redis-3.3.0.gem

gem list –check redis gem

启动集群

1 2	css复制代码 redis-cli --cluster create 192.168.121.133:6379 192.168.121.133:6380 192.168.121.133:6381 192.168.121.133:6376 192.168.121.133:6377 192.168.121.133:6378 --cluster-replicas 1

最后的这个cluster-replicas 1 代表的是主节点和从节点的比例，比例算法是主节点/从节点，是1，代表主从是1:1,这就表明1个主节点就需要1个从节点，如果是三个主节点就需要三个从节点，集群默认必须要有三个主节点，所以就要再配三个从节点，也就是至少需要6个节点，如果集群没有启动成功就将所有的rdb文件和node开头的conf文件删除，然后重启再开启集群。

集群启动成功后，进入客户端命令后面要加-c

ruby复制代码
./redis-cli -p 6380 -c

127.0.0.1:6379> cluster info 查询集群信息

127.0.0.1:6379> cluster nodes 差群集群有多少节点

本文转载自: 掘金

开发者博客 – 和开发相关的这里全都有