redis 之redis-sentinel主从复制高可用
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了redis 之redis-sentinel主从复制高可用，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含8772字，纯文字阅读大概需要13分钟。
内容图文
一.redis主从复制背景问题
Redis主从复制可将主节点数据同步给从节点，从节点此时有两个作用：
(1)一旦主节点宕机，从节点作为主节点的备份可以随时顶上来。
(2)扩展主节点的读能力，分担主节点读压力。
但是问题是：
一旦主节点宕机，从节点上位，那么需要人为修改所有应用方的主节点地址（改为新的master地址），还需要命令所有从节点复制新的主节点
那么这个问题，redis-sentinel就可以解决了
二. Redis-Sentinel
Redis-Sentinel是redis官方推荐的高可用性解决方案，
当用redis作master-slave的高可用时，如果master本身宕机，redis本身或者客户端都没有实现主从切换的功能。
而redis-sentinel就是一个独立运行的进程，用于监控多个master-slave主从复制，
自动发现master宕机，进行自动切换slave > master。
sentinel主要功能如下：
不时的监控redis是否良好运行，如果节点不可达就会对节点进行下线标识
如果被标识的是主节点，sentinel就会和其他的sentinel节点“协商”，如果其他节点也人为主节点不可达，就会选举一个sentinel节点来完成自动故障转义
在master-slave进行切换后，master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变，即master_redis.conf中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换
三.Sentinel的工作方式
每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个 PING 命令
如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel 标记为主观下线。
如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。
当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态， 则Master会被标记为客观下线
在一般情况下， 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有Master，Slave发送 INFO 命令
当Master被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次
若没有足够数量的 Sentinel 同意 Master 已经下线， Master 的客观下线状态就会被移除。
若 Master 重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除。
主观下线和客观下线
主观下线：Subjectively Down，简称 SDOWN，指的是当前 Sentinel 实例对某个redis服务器做出的下线判断。
客观下线：Objectively Down， 简称 ODOWN，指的是多个 Sentinel 实例在对Master Server做出 SDOWN 判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的Master Server下线判断，然后开启failover.
SDOWN适合于Master和Slave，只要一个 Sentinel 发现Master进入了ODOWN， 这个 Sentinel 就可能会被其他 Sentinel 推选出， 并对下线的主服务器执行自动故障迁移操作。
ODOWN只适用于Master，对于Slave的 Redis 实例，Sentinel 在将它们判断为下线前不需要进行协商， 所以Slave的 Sentinel 永远不会达到ODOWN。
四.Redis Sentinel架构
redis的一个进程，但是不存储数据，只是监控redis
sentinel 会通过命令连接向被监视的主从服务器发送 “hello”信息,该信息包含sentinel的ip,端口号,id等内容,以此来向其他sentinel宣告自己的存在。与此同时sentinel会通过订阅连接接收其他sentinel的”hello”信息，以此来发现监视同一个主服务器的其他sentinel。
从图中sentinel1 通过发送hello信息来让sentinel2和sentinel3发现自己，其他两个sentinel也会进行类似的操作。
redis主库服务故障，主从复制重新判断主从结构的过程
1.redis命令整理
官网地址：http://redisdoc.com/
redis-cli info #查看redis数据库信息
redis-cli info replication #查看redis的复制授权信息
redis-cli info sentinel #查看redis的哨兵信息
2.配置哨兵模式redis sentinel实现主从复制及自动切换过程
配置五个redis数据库, 一主四从
环境：
192.168.1.209 配置了1主2从
192.168.1.209 配置了2从
（注意由于虚拟机上配置，虚拟机有限，所以将一台服务配置多个从库，生产从不会是这样的，生产中都是一个库一台服务器的）
(1)主从库配置文件如下
192.168.1.209 主库
# 声明端口 port 6379 # 表示后台启动 daemonize yes # 将pid文件放到某目录下 pidfile /data/6379/redis.pid # 日志级别和日志目录 loglevel notice logfile "/data/6379/redis.log" # 持久化相关 # dir /data/6379 # 安全模式 protected-mode no # 密码设置,redis一般不要密码 # requirepass hsz
192.168.1.209 从库1 6380端口
# 声明端口 port 6380 # 表示后台启动 daemonize yes # 将pid文件放到某目录下 pidfile /data/6380/redis.pid # 日志级别和日志目录 loglevel notice logfile "/data/6380/redis.log" # 持久化相关 # dir /data/6380 # 安全模式 protected-mode no # 密码设置,redis一般不要密码 # requirepass hsz slaveof 192.168.1.209 6379
192.168.1.209 从库2 6381 端口
# 声明端口 port 6381 # 表示后台启动 daemonize yes # 将pid文件放到某目录下 pidfile /data/6381/redis.pid # 日志级别和日志目录 loglevel notice logfile "/data/6381/redis.log" # 持久化相关 # dir /data/6380 # 安全模式,如果开启文件不会被修改 protected-mode no # 密码设置,redis一般不要密码 # requirepass hsz dir /data/6381/ dbfilename dbmp.rdb save 900 1 save 300 10 save 60 10000 slaveof 192.168.1.209 6379
192.168.1.208 从库1 6381端口
port 6381 daemonize yes pidfile /data/6381/redis.pid loglevel notice logfile "/data/6381/redis.log" dbfilename dump.rdb dir /data/6381 protected-mode no # 主库ip和端 slaveof 192.168.1.209 6379
192.168.1.208 从库1 6382端口
port 6382 daemonize yes pidfile /data/6382/redis.pid loglevel notice logfile "/data/6382/redis.log" dbfilename dump.rdb dir /data/6382 protected-mode no # 主库ip和端口 slaveof 192.168.1.209 6379
做好配置文件后都进行redis启动
redis-server redis配置文件名
最后确定主从信息及关系：
(2)配置五个哨兵
在配置之前首先进行学习下，配置哨兵的配置文件的各项解析：
# Sentinel节点的端口 port 26379 dir /var/redis/data/ logfile "26379.log" # sentinel announce-ip 127.0.0.1 # 宣告哨兵IP, 此配置只有当使用非127.0.0.1的IP配置哨兵无法成功时加上，同时redis三个服务端也需要同步修改IP # 当前Sentinel节点监控 127.0.0.1:6379 这个主节点 # 2代表判断主节点失败至少需要2个Sentinel节点节点同意 # mymaster是主节点的别名 sentinel monitor mymaster 127.0.0.1 6379 2 # 每个Sentinel节点都要定期PING命令来判断Redis数据节点和其余Sentinel节点是否可达，如果超过30000毫秒30s且没有回复，则判定不可达 sentinel down-after-milliseconds mymaster 30000 # 当Sentinel节点集合对主节点故障判定达成一致时，Sentinel领导者节点会做故障转移操作，选出新的主节点，原来的从节点会向新的主节点发起复制操作，限制每次向新的主节点发起复制操作的从节点个数为1 sentinel parallel-syncs mymaster 1 # 故障转移超时时间为180000毫秒 sentinel failover-timeout mymaster 180000 daemonize yes
关于哨兵的配置，将5个哨兵配置到两台上，一台3个一台2个
那么接下来哨兵1配置（由于和主机同一台所以配置127.0.0.1）：
# vim redis-sentinel-26379.conf
port 26379 dir /var/redis/data/ logfile "26379.log" sentinel monitor mymaster 192.168.1.209 6379 2 sentinel down-after-milliseconds mymaster 30000 sentinel parallel-syncs mymaster 1 sentinel failover-timeout mymaster 180000 daemonize yes
启动之前新建日志目录
#mkdir -p /var/redis/data/
使用以下命令启动redis-sentinel
# redis-sentinel redis-sentinel-26379.conf
然后进行查看通信状态：# redis-cli -p 26379 info sentinel
可以从信息看出，有一台主库，ip及端口，4台从库，和1个哨兵，因为才配置一个，所有哨兵为
哨兵2配置：
# vim redis-sentinel-26380.conf
port 26380 dir /var/redis/data/ logfile "26380.log" sentinel monitor mymaster 192.168.1.209 6379 2 sentinel down-after-milliseconds mymaster 30000 sentinel parallel-syncs mymaster 1 sentinel failover-timeout mymaster 180000 daemonize yes
启动之前新建日志目录
# mkdir -p /var/redis/data/
使用以下命令启动redis-sentinel
# redis-sentinel redis-sentinel-26380.conf
然后进行查看通信状态：# redis-cli -p 26380 info sentinel
哨兵3配置
# vim redis-sentinel-26380.conf
port 26380 dir /var/redis/data/ logfile "26380.log" sentinel monitor mymaster 192.168.1.209 6379 2 sentinel down-after-milliseconds mymaster 30000 sentinel parallel-syncs mymaster 1 sentinel failover-timeout mymaster 180000 daemonize yes
启动之前新建日志目录
# mkdir -p /var/redis/data/
使用以下命令启动redis-sentinel
# redis-sentinel redis-sentinel-26380.conf
然后进行查看通信状态：# redis-cli -p 26380 info sentinel
哨兵4配置
# vim redis-sentinel-26381.conf
port 26381 dir /var/redis/data/ logfile "26381.log" sentinel monitor mymaster 192.168.1.209 6379 2 sentinel down-after-milliseconds mymaster 30000 sentinel parallel-syncs mymaster 1 sentinel failover-timeout mymaster 180000 daemonize yes
启动之前新建日志目录
# mkdir -p /var/redis/data/
使用以下命令启动redis-sentinel
# redis-sentinel redis-sentinel-26381.conf
然后进行查看通信状态：# redis-cli -p 26381 info sentinel
哨兵5配置
# vim redis-sentinel-26382.conf
port 26382 dir /var/redis/data/ logfile "26382.log" sentinel monitor mymaster 192.168.1.209 6379 2 sentinel down-after-milliseconds mymaster 30000 sentinel parallel-syncs mymaster 1 sentinel failover-timeout mymaster 180000 daemonize yes
启动之前新建日志目录
# mkdir -p /var/redis/data/
使用以下命令启动redis-sentinel
# redis-sentinel redis-sentinel-26382.conf
然后进行查看通信状态：# redis-cli -p 26382 info sentinel
最后可以查看下哨兵的配置文件，会自动加上这些内容：
而从库的配置文件会修改为这一句配置：
(3)进行redis高可用故障实验
关闭主库进程（模拟生产中服务器挂掉）如下截图：
此时进行等待30秒。。。。
从其中一个哨兵进行查看
查看可知：新的主库为192.168.1.209:6381
# redis-cli -p 6381 info replication
到这个redis主库进行查看信息，并查看数据，可知从库可同步数据：
最后高可用实现
内容总结
以上是互联网集市为您收集整理的redis 之redis-sentinel主从复制高可用全部内容，希望文章能够帮你解决redis 之redis-sentinel主从复制高可用所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。