Redis哨兵及集群搭建

程序员蛋蛋
1,351 阅读8分钟

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

哨兵模式（sentinel）

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

哨兵模式搭建

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

image.png

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


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秒内无响应，视为挂掉，开始切换其他从为主。

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

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


./redis-server ../sentinel/sentinel-26377.conf --sentinel

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

image.png

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

image.png

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

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

image.png

可以看到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的配置文件放入进去


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秒

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

启动节点


./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

启动集群


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


./redis-cli -p 6380 -c

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

127.0.0.1:6379> cluster nodes 差群集群有多少节点
avatar
文章
阅读
粉丝