redis 《三》--- 高可用与集群（redis 哨兵）

最新推荐文章于 2024-06-13 10:08:05 发布

cwy_linux

最新推荐文章于 2024-06-13 10:08:05 发布

阅读量94

点赞数

分类专栏： linux架构学习文章标签： redis 数据库 linux

本文链接：https://blog.csdn.net/cwyxf123/article/details/120075448

版权

linux架构学习专栏收录该内容

36 篇文章 3 订阅

订阅专栏

一、 redis 集群

上一个步骤的主从架构无法实现master和slave角色的自动切换，即当master出现redis服务异常、主机断电、磁盘损坏等问题导致master无法使用，而redis高可用无法实现自故障转移(将slave提升为master)，需要手动改环境配置才能切换到slave redis服务器，另外也无法横向扩展Redis服务的并行写入性能，当单台Redis服务器性能无法满足业务写入需求的时候就必须需要一种方式解决以上的两个核心问题，即：1.master和slave角色的无缝切换，让业务无感知从而不影响业务使用 2.可以横向动态扩展Redis服务器，从而实现多台服务器并行写入以实现更高并发的目的。

Redis 集群实现方式：客户端分片代理分片 Redis Cluster

1.1. Sentinel(哨兵)

Sentinel 进程是用于监控redis集群中Master主服务器工作的状态，在Master主服务器发生故障的时候，可以实现Master和Slave服务器的切换，保证系统的高可用，其已经被集成在redis2.6+的版本中，Redis的哨兵模式到了2.8版本之后就稳定了下来。一般在生产环境也建议使用Redis的2.8版本的以后版本。哨兵(Sentinel) 是一个分布式系统，可以在一个架构中运行多个哨兵(sentinel) 进程，这些进程使用流言协议(gossip protocols)来接收关于Master主服务器是否下线的信息，并使用投票协议(Agreement Protocols)来决定是否执行自动故障迁移,以及选择哪个Slave作为新的Master。每个哨兵(Sentinel)进程会向其它哨兵(Sentinel)、Master、Slave定时发送消息，以确认对方是否”活”着，如果发现对方在指定配置时间(可配置的)内未得到回应，则暂时认为对方已掉线，也就是所谓的”主观认为宕机” ，主观是每个成员都具有的独自的而且可能相同也可能不同的意识，英文名称：Subjective Down，简称SDOWN。有主观宕机，肯定就有客观宕机。当“哨兵群”中的多数Sentinel进程在对Master主服务器做出 SDOWN 的判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的Master Server下线判断，这种方式就是“客观宕机”，客观是不依赖于某种意识而已经实际存在的一切事物，英文名称是：Objectively Down，简称 ODOWN。通过一定的vote算法，从剩下的slave从服务器节点中，选一台提升为Master服务器节点，然后自动修改相关配置，并开启故障转移（failover）。

Sentinel 机制可以解决master和slave角色的切换问题

1.2 规划

ip	主机名	角色
10.10.100.130	node1	Master
10.10.100.131	node2	slave
10.10.100.132	node3	slave

redis安装目录/apps/redis，安装配置见redis 《一》 —安装配置及持久化

1.3 手动配置master

需要手动先指定某一台Redis服务器为master，然后将其他slave服务器使用命令配置为master服务器的slave,哨兵的前提是已经手动实现了一个redis master-slave的运行环境。

实现一个一主两从基于哨兵的高可用redis架构

在这里插入图片描述

1.4 配置slave服务器

#node2配置slave 
10.10.100.131:6379> SLAVEOF 10.10.100.130 6379
OK
10.10.100.131:6379> CONFIG SET masterauth cwy
OK
10.10.100.131:6379> INFO Replication
# Replication
role:slave
master_host:10.10.100.130
master_port:6379
master_link_status:up
master_last_io_seconds_ago:8
master_sync_in_progress:0
slave_repl_offset:44355
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:30fe89b4d2cf24c474b2bae583017683f5b5c45e
master_replid2:0000000000000000000000000000000000000000



#node3配置slave 
10.10.100.132:6379> SLAVEOF 10.10.100.130 6379
OK
10.10.100.132:6379> CONFIG SET masterauth cwy
OK
10.10.100.132:6379> INFO Replication
# Replication
role:slave
master_host:10.10.100.130
master_port:6379
master_link_status:up
master_last_io_seconds_ago:10
master_sync_in_progress:0
slave_repl_offset:44299
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:30fe89b4d2cf24c474b2bae583017683f5b5c45e
master_replid2:0000000000000000000000000000000000000000

1.5 查看master状态

10.10.100.130:6379> INFO Replication
# Replication
role:master
connected_slaves:2
slave0:ip=10.10.100.131,port=6379,state=online,offset=44467,lag=1
slave1:ip=10.10.100.132,port=6379,state=online,offset=44467,lag=1
master_replid:30fe89b4d2cf24c474b2bae583017683f5b5c45e
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:44481
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:536870912
repl_backlog_first_byte_offset:1
repl_backlog_histlen:44481

1.6 应用程序如何连接redis

Redis 官方客户端：https://redis.io/clients

java客户端连接redis是通过Jedis来实现的，java代码用的时候只要创建Jedis对象就可以建多个Jedis连接池来连接redis，应用程序再直接调用连接池即可连接Redis。

而Redis为了保障高可用,服务一般都是Sentinel部署方式，当Redis服务中的主服务挂掉之后,会仲裁出另外一台Slaves服务充当Master。这个时候,我们的应用即使使用了Jedis 连接池,Master服务挂了,我们的应用将还是无法连接新的Master服务，为了解决这个问题, Jedis也提供了相应的Sentinel实现,能够在Redis Sentinel主从切换时候,通知我们的应用,把我们的应用连接到新的Master服务。

Redis Sentinel的使用也是十分简单的,只是在JedisPool中添加了Sentinel和MasterName参数，JRedis Sentinel底层基于Redis订阅实现Redis主从服务的切换通知，当Reids发生主从切换时，Sentinel会发送通知主动通知Jedis进行连接的切换，JedisSentinelPool在每次从连接池中获取链接对象的时候,都要对连接对象进行检测,如果此链接和Sentinel的Master服务连接参数不一致,则会关闭此连接,重新获取新的Jedis连接对象。

1.7 编辑哨兵配置文件sentinel.conf

哨兵可以不和Redis服务器部署在一起

[root@node1 redis]# cat /apps/redis/etc/sentinel.conf
bind 0.0.0.0
port 26379
daemonize yes
pidfile "redis-sentinel.pid"
logfile "sentinel_26379.log"
dir "/apps/redis/logs"
#法定人数限制(quorum)，即有几个slave认为master down了就进行故障转移
sentinel monitor mymaster 10.10.100.130 6379 2

#redis连接密码
sentinel auth-pass mymaster cwy

#(SDOWN)主观下线的时间
sentinel down-after-milliseconds mymaster 10000

#发生故障转移时候同时向新master同步数据的slave数量，数字越小总同步时间越长
sentinel parallel-syncs mymaster 1

#所有slaves指向新的master所需的超时时间
sentinel failover-timeout mymaster 180000

#禁止修改脚本
#sentinel deny-scripts-reconfig yes

将配置文件拷贝到node2和node3

[root@node1 redis]# scp ./etc/sentinel.conf 10.10.100.131:/apps/redis/etc/
root@10.10.100.131's password:
sentinel.conf                                                                                                100%  689     1.1MB/s   00:00
[root@node1 redis]# scp ./etc/sentinel.conf 10.10.100.132:/apps/redis/etc/
root@10.10.100.132's password:
sentinel.conf                                                                                                100%  689     1.3MB/s   00:00

1.8 启动哨兵

#三台节点都启动哨兵
[root@node1 ~]# /apps/redis/bin/redis-sentinel /apps/redis/etc/sentinel.conf
[root@node2 ~]# /apps/redis/bin/redis-sentinel /apps/redis/etc/sentinel.conf
[root@node3 ~]# /apps/redis/bin/redis-sentinel /apps/redis/etc/sentinel.conf

1.9 验证哨兵端口

在这里插入图片描述

1.10 查看日志

在这里插入图片描述

1.11 查看当前redis master状态

10.10.100.130:6379> info Replication
# Replication
role:master
connected_slaves:2
slave0:ip=10.10.100.131,port=6379,state=online,offset=93415,lag=1
slave1:ip=10.10.100.132,port=6379,state=online,offset=93415,lag=1
master_replid:30fe89b4d2cf24c474b2bae583017683f5b5c45e
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:93697
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:536870912
repl_backlog_first_byte_offset:1
repl_backlog_histlen:93697

1.12 当前sentinel状态

在sentinel状态中尤其是最后一行，涉及到masterIP是多少，有几个slave，有几个sentinels，必须是符合全部服务器数量的。

[root@node1 ~]# redis-cli -h 10.10.100.130 -p 26379
10.10.100.130: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=10.10.100.130:6379,slaves=2,sentinels=3

1.13 停止Redis Master测试故障转移

#停止master(node1上的redis)
[root@node1 ~]# systemctl stop redis
[root@node1 ~]# redis-cli -h 10.10.100.130 -p 26379
10.10.100.130:26379> INFO sentinel

#查看哨兵信息,可以看到master转移到node2(10.10.100.131)上了
# 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=10.10.100.131:6379,slaves=2,sentinels=3


#查看node2 master状态
10.10.100.131:6379> INFO Replication
# Replication
role:master
connected_slaves:1
slave0:ip=10.10.100.132,port=6379,state=online,offset=340867,lag=1
master_replid:f5282d5a4e6d13553a4a628a4edc676369d88f84
master_replid2:30fe89b4d2cf24c474b2bae583017683f5b5c45e
master_repl_offset:340867
second_repl_offset:175601
repl_backlog_active:1
repl_backlog_size:536870912
repl_backlog_first_byte_offset:43236
repl_backlog_histlen:297632

查看哨兵日志
在这里插入图片描述

1.14 故障转移后的哨兵配置文件

故障转移后redis.conf中的replicaof行的master IP会被修改，sentinel.conf中的sentinel monitor IP会被修改。

在这里插入图片描述

1.15 启动刚刚停掉的node1上的redis

#启动redis在配置文件填如下配置，将node1添加node2的slave
[root@node1 ~]# vim /apps/redis/etc/redis.conf
#slaveof 哨兵会根据先master地址自动添加到配置文件，masterauth 需要自己手动配置
slaveof 10.10.100.131 6379
masterauth cwy

在这里插入图片描述

查看master信息
在这里插入图片描述

cwy_linux

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
redis 《三》--- 高可用与集群（redis 哨兵）

一、 redis 集群上一个步骤的主从架构无法实现master和slave角色的自动切换，即当master出现redis服务异常、主机断电、磁盘损坏等问题导致master无法使用，而redis高可用无法实现自故障转移(将slave提升为master)，需要手动改环境配置才能切换到slave redis服务器，另外也无法横向扩展Redis服务的并行写入性能，当单台Redis服务器性能无法满足业务写入需求的时候就必须需要一种方式解决以上的两个核心问题，即：1.master和slave角色的无缝切换，让业务无感
复制链接

扫一扫