Redis 一主二从三哨兵架构搭建

Redis 一主二从三哨兵架构搭建

哨兵模式也是建立在redis主从架构之上的,先搭建redis主从

redis哨兵架构图

redis主从架构搭建

  • 修改内核参数 (防止因系统重启redis数据丢失)

echo “vm.overcommit_memory” = 1 >>/etc/sysctl.conf

sysctl -p

  • 集群时间同步

ansible test -m cron -a “name=’ntpdate’ hour=’12’ day=’*/5′ job=’ntpdate ntp1.aliyun.com > /dev/null'”

test分组是我的redis集群节点

  • 下载redis安装包并解压(这里以官网最新稳定版本为准)

ansible test -m shell -a “wget http://download.redis.io/releases/redis-5.0.3.tar.gz “

tar -xvzf  redis-5.0.3.tar.gz -C /usr/local/ &&cd /usr/local/&&mv redis-5.0.3 ./redis

  • 编译安装redis   

cd redis && make -j 4 && echo $?   (判断安装是否成功)

mkdir /usr/local/redis/{conf,bin} -pv  (建立存放配置文件以及命令的目录,便于管理)

cd /usr/local/redis/src/ && find ./ -type f -perf 755 -maxdepth 1 |xargs -I {} mv {} /usr/local/redis/bin/

cd /usr/local/redis/src/ && find ./ -perm 755 -maxdepth 1 -type f |xargs -I {} mv {} /usr/local/redis/conf/

效果如图:

  • 添加环境变量

ansible test -m shell -a “echo export PATH=/usr/local/redis/bin:$PATH >>/etc/profile && source /etc/profile”

  • 修改redis为非root用户运行 (这个是因为后来发现redis用root启动有安全隐患后补充的 详见)

groupadd redis

useradd  redis -g redis -M -s /sbin/nologin

mkdir /var/run/redis/ -pv

chown redis:redis /var/run/redis -R

修改sentinel.conf 以及 redis.conf的pid 路径

修改开启启动文件里的pid路径即可

  • 配置文件修改(只修改了注释的部分,其他不用修改)

master :

slave:其他配置都相同,只需要额外添加注释的地方

  • 配置开机启动脚本

标题内容

[Unit]
#描述
Description=Redis
#在哪个服务之后启动
After=syslog.target network.target remote-fs.target nss-lookup.target

#表示服务信息
[Service]
Type=forking
#注意:需要和redis.conf配置文件中的信息一致
PIDFile=/var/run/redis_6379.pid
#启动服务的命令
#redis-server安装的路径 和 redis.conf配置文件的路径
ExecStart=/usr/local/redis/bin/redis-server /usr/local/redis/conf/redis.conf
#重新加载命令
ExecReload=/bin/kill -s HUP $MAINPID
#停止服务的命令
ExecStop=/bin/kill -s QUIT $MAINPID
PrivateTmp=true

#安装相关信息
[Install]
#以哪种方式启动
WantedBy=multi-user.target
#multi-user.target表明当系统以多用户方式(默认的运行级别)启动时,这个服务需要被自动运行。

  • 别名管理

alias redis-cli=’redis-cli -h 192.168.137.99 -a 123456′

  • 最终效果

温馨提示:有问题看日志

二.redis哨兵架构搭建

port 26379
daemonize yes
pidfile “/var/run/redis-sentinel.pid”
logfile “/var/log/redis/sentinel.log”
dir “/tmp”
#sentinel deny-scripts-reconfig yes
sentinel myid ffbf052b1901979830ec1a2913509be51c304b32
sentinel deny-scripts-reconfig yes
sentinel monitor mymaster 192.168.137.99 6379 2
sentinel down-after-milliseconds mymaster 60000
sentinel failover-timeout mymaster 100000
sentinel auth-pass mymaster 123456
sentinel config-epoch mymaster 2
protected-mode no
sentinel leader-epoch mymaster 2
# Generated by CONFIG REWRITE
sentinel known-replica mymaster 192.168.137.102 6379
sentinel known-replica mymaster 192.168.137.101 6379
sentinel known-sentinel mymaster 192.168.137.101 26379 da8228c60a436243a1e3cab0ef568570b7340856
sentinel known-sentinel mymaster 192.168.137.102 26379 7341efed9096d4ceb93e39e9ab6a07b66884f91f
sentinel current-epoch 2

配置sentinel开机启动服务

#表示基础信息
[Unit]
#描述
Description=Redis-Sentinel
#在哪个服务之后启动
After=syslog.target network.target remote-fs.target nss-lookup.target

#表示服务信息
[Service]
Type=forking
#注意:需要和redis.conf配置文件中的信息一致
PIDFile=/var/run/redis-sentinel.pid
#启动服务的命令
#redis-server安装的路径 和 redis.conf配置文件的路径
ExecStart=/usr/local/redis/bin/redis-sentinel /usr/local/redis/conf/sentinel.conf
#重新加载命令
ExecReload=/bin/kill -s HUP $MAINPID
#停止服务的命令
ExecStop=/bin/kill -s QUIT $MAINPID
PrivateTmp=true

#安装相关信息
[Install]
#以哪种方式启动
WantedBy=multi-user.target
#multi-user.target表明当系统以多用户方式(默认的运行级别)启动时,这个服务需要被自动运行。

 

启动sentinel服务

1.service sentinel start

2.redis-cli -h 192.168.137.99 -p 26379 -a 123456

执行info

3.查看日志

已经说明当前master主机是192.168.137.99,接下来kill掉master的redis查看故障转移的变化

这里quorum 2 代表投票数

登陆102节点再次确认是否故障转移成功

可以看到故障转移成功,至此redis 1主+2从+3哨兵节点搭建完成。

哨兵基本原理

关于哨兵的原理,关键是了解以下几个概念。

(1)定时任务:每个哨兵节点维护了3个定时任务。定时任务的功能分别如下:通过向主从节点发送info命令获取最新的主从结构(通过在redis主节点的info信息还可以知道有哪些哨兵在监测主,进而发现其他哨兵);通过发布订阅功能获取其他哨兵节点的信息;通过向其他节点(不仅仅是主节点,还有从节点,哨兵节点)发送ping命令进行心跳检测,判断是否下线。

(2)主观下线:在心跳检测的定时任务中,如果其他节点超过一定时间没有回复,哨兵节点就会将其进行主观下线。顾名思义,主观下线的意思是一个哨兵节点“主观地”判断下线;与主观下线相对应的是客观下线。

(3)客观下线:哨兵节点在对主节点进行主观下线后,会通过sentinel is-master-down-by-addr命令询问其他哨兵节点该主节点的状态;如果判断主节点下线的哨兵数量达到一定数值,则对该主节点进行客观下线

需要特别注意的是,客观下线是主节点才有的概念;如果从节点和哨兵节点发生故障,被哨兵主观下线后,不会再有后续的客观下线和故障转移操作。

(4)选举领导者哨兵节点:当主节点被判断客观下线以后,各个哨兵节点会进行协商,选举出一个领导者哨兵节点,并由该领导者节点对其进行故障转移操作

监视该主节点的所有哨兵都有可能被选为领导者,选举使用的算法是Raft算法;Raft算法的基本思路是先到先得:即在一轮选举中,哨兵A向B发送成为领导者的申请,如果B没有同意过其他哨兵,则会同意A成为领导者。选举的具体过程这里不做详细描述,一般来说,哨兵选择的过程很快,谁先完成客观下线,一般就能成为领导者

(5)故障转移:选举出的领导者哨兵,开始进行故障转移操作,该操作大体可以分为3个步骤:

  • 在从节点中选择新的主节点:选择的原则是,首先过滤掉不健康的从节点;然后选择优先级最高的从节点(由slave-priority指定);如果优先级无法区分,则选择复制偏移量最大的从节点;如果仍无法区分,则选择runid最小的从节点
  • 更新主从状态:通过slaveof no one命令,让选出来的从节点成为主节点;并通过slaveof命令让其他节点成为其从节点
  • 将已经下线的主节点(即6379)设置为新的主节点的从节点,当6379重新上线后,它会成为新的主节点的从节点。

重要配置说明

下面介绍与哨兵相关的几个配置。

(1) sentinel monitor {masterName} {masterIp} {masterPort} {quorum}

sentinel monitor是哨兵最核心的配置,在前文讲述部署哨兵节点时已说明,其中:masterName指定了主节点名称,masterIp和masterPort指定了主节点地址,quorum是判断主节点客观下线的哨兵数量阈值:当判定主节点下线的哨兵数量达到quorum时,对主节点进行客观下线。建议取值为哨兵数量的一半加1

(2) sentinel down-after-milliseconds {masterName} {time}

sentinel down-after-milliseconds与主观下线的判断有关:哨兵使用ping命令对其他节点进行心跳检测,如果其他节点超过down-after-milliseconds配置的时间没有回复,哨兵就会将其进行主观下线。该配置对主节点、从节点和哨兵节点的主观下线判定都有效

down-after-milliseconds的默认值是30000,即30s;可以根据不同的网络环境和应用要求来调整:值越大,对主观下线的判定会越宽松,好处是误判的可能性小,坏处是故障发现和故障转移的时间变长,客户端等待的时间也会变长。例如,如果应用对可用性要求较高,则可以将值适当调小,当故障发生时尽快完成转移;如果网络环境相对较差,可以适当提高该阈值,避免频繁误判。

(3) sentinel parallel-syncs {masterName} {number}

sentinel parallel-syncs与故障转移之后从节点的复制有关:它规定了每次向新的主节点发起复制操作的从节点个数。例如,假设主节点切换完成之后,有3个从节点要向新的主节点发起复制;如果parallel-syncs=1,则从节点会一个一个开始复制;如果parallel-syncs=3,则3个从节点会一起开始复制。

parallel-syncs取值越大,从节点完成复制的时间越快,但是对主节点的网络负载、硬盘负载造成的压力也越大;应根据实际情况设置。例如,如果主节点的负载较低,而从节点对服务可用的要求较高,可以适量增加parallel-syncs取值。parallel-syncs的默认值是1。

(4) sentinel failover-timeout {masterName} {time}

sentinel failover-timeout与故障转移超时的判断有关,但是该参数不是用来判断整个故障转移阶段的超时,而是其几个子阶段的超时,例如如果主节点晋升从节点时间超过timeout,或从节点向新的主节点发起复制操作的时间(不包括复制数据的时间)超过timeout,都会导致故障转移超时失败。

failover-timeout的默认值是180000,即180s;如果超时,则下一次该值会变为原来的2倍。

(5)除上述几个参数外,还有一些其他参数,如安全验证相关的参数,这里不做介绍。

总结

在主从复制的基础上,哨兵引入了主节点的自动故障转移,进一步提高了Redis的高可用性;但是哨兵的缺陷同样很明显:哨兵无法对从节点进行自动故障转移,在读写分离场景下,从节点故障会导致读服务不可用,需要我们对从节点做额外的监控、切换操作。此外,哨兵仍然没有解决写操作无法负载均衡、及存储能力受到单机限制的问题;这些问题的解决需要使用集群

参考 redis 哨兵官网文档:

http://redisdoc.com/topic/sentinel.html  (包含服务发现原理,故障转移原理,安装以及配置)

http://redisdoc.com/topic/replication.html (redis复制详解)

友链西门飞兵 http://www.fblinux.com/?p=157 (写的也很详细,也可以看看这篇)

点赞

发表评论

电子邮件地址不会被公开。 必填项已用*标注

Loading...