基于哨兵和集群方式分别实现redis高可用

1、一主两从三哨兵模式

概念介绍:

在主从复制模式下,一旦主节点由于故障不能提供服务,需要人工将从节点晋升为主节点,同时还要通知应用方更新主节点地址,对于很多应用场景这种故障处理的方式是无法接受的。从Redis2.8开始正式提供Redis Sentinel(哨兵)架构来解决这个问题。

基于哨兵和集群方式分别实现redis高可用
哨兵模式

监控(Monitoring):
Sentinel会不断地检查主节点和从节点是否运作正常。

提醒(Notification):
当被监控的某个Redis服务器出现问题时,Sentinel可以通过API向管理员或者其他应用程序发送通知。

自动故障迁移(Automaticfailover):
当一个主服务器不能正常工作时,Sentinel会开始一次自动故障迁移操作,它会将失效主服务器的其中一个从服务器升级为新的主服务器,并让失效主服务器的其他从服务器改为复制新的主服务器;当客户端试图连接失效的主服务器时,集群也会向客户端返回新主服务器的地址,使得集群可以使用新主服务器代替失效服务器。

发现并连接主节点
Sentinel会与被监视的主节点创建两个网络连接:
命令连接用于向主节点发送命令;
订阅连接用于订阅指定的频道,从而发现监视同一主节点的其他Sentinel;

基于哨兵和集群方式分别实现redis高可用

发现并连接从服务器
Sentinel通过向主节点发送info命令(默认每隔10s)来自动获得所有从节点的地址。跟主节点一样,Sentinel会与每个被发现的从服务器创建命令连接和订阅连接。

发现其他Sentinel

Sentinel会通过命令连接向被监视的主从服务器发送“HELLO”信息,该消息包含Sentinel的IP、端口号、ID等内容,以此来向其他Sentinel宣告自己的存在。与此同时Sentinel会通过订阅连接接收其他Sentinel的“HELLO”信息,以此来发现监视同一个主服务器的其他Sentinel。

基于哨兵和集群方式分别实现redis高可用

每个Sentinel都订阅了被它监视的所有主节点与从节点的sentinel:hello频道,查找之前未出现过的Sentinel。当一个Sentinel发现一个新的Sentinel时,它会将新的Sentinel添加到一个列表中,这个列表保存了已知并且监视同一个主节点的所有其他Sentinel。Sentinel发送的信息中还包括完整的主节点当前配置(configuration)。如果一个Sentinel包含的主服务器配置比另一个Sentinel发送的配置要旧,那么这个Sentinel会立即升级到新配置上。
Sentinel之间只会互相创建命令连接,用于进行通信。因为已经有主从服务器作为发送和接收HELLO信息的中介,所以Sentinel之间不会创建订阅连接。

Sentinel使用以下规则来选择新的主服务器:

1)在失效主服务器属下的从服务器当中,那些被标记为主观下线、已断线、或者最后一次回复PING命令的时间大于五秒钟的从服务器都会被淘汰。
2)在失效主服务器属下的从服务器当中,那些与失效主服务器连接断开的时长超过down-after选项指定的时长十倍的从服务器都会被淘汰。
3)在经历了以上两轮淘汰之后剩下来的从服务器中,我们选出复制偏移量(replicationoffset)最大的那个从服务器作为新的主服务器;如果复制偏移量不可用,或者从服务器的复制偏移量相同,那么带有最小运行ID的那个从节点成为新的节点。

Sentinel自动故障转移的一致性特质:
1)Sentinel自动故障迁移使用Raft算法来选举领头(leader)Sentinel,从而确保在一个给定的周期(epoch)里,只有一个领头产生。
2)这表示在同一个周期中,不会有两个Sentinel同时被选中为领头,并且各个Sentinel在同一个节点中只会对一个领头进行投票。
3)更高的配置节点总是优于较低的节点,因此每个Sentinel都会主动使用更新的节点来代替自己的配置。
简单来说,我们可以将Sentinel配置看作是一个带有版本号的状态。一个状态会以最后写入者胜出(last-write-wins)的方式(也即是,最新的配置总是胜出)传播至所有其他Sentinel。

实验:

三哨兵的具体配置

实验准备:
主:192.168.1.10:6379
从1:192.168.1.11:6379
主2:192.168.1.12:6379
哨兵1:192.168.1.10:26379
哨兵2:192.168.1.11:26379
哨兵3:192.168.1.12:26379

单个配置sentinel哨兵实现高可用

vim /etc/redis-sentinel.conf

基于哨兵和集群方式分别实现redis高可用
基于哨兵和集群方式分别实现redis高可用

systemctl start redis-sentinel.service

netstat -anput | grep 26379

基于哨兵和集群方式分别实现redis高可用

检测:
redis-cli -h 192.168.1.10 -p 26379

info sentinel

基于哨兵和集群方式分别实现redis高可用

配置三哨兵

基本配置

vim /etc/redis.conf

基于哨兵和集群方式分别实现redis高可用
基于哨兵和集群方式分别实现redis高可用
基于哨兵和集群方式分别实现redis高可用

指定主库

vim /etc/redis.conf

11端

基于哨兵和集群方式分别实现redis高可用

12端

基于哨兵和集群方式分别实现redis高可用

配置哨兵(10 11 12)

vim /etc/redis-sentinel.conf

基于哨兵和集群方式分别实现redis高可用
基于哨兵和集群方式分别实现redis高可用

systemctl start redis-sentinel.service

netstat -anput | grep 26379

redis-cli -h 192.168.1.10 -p 26379

info sentinel

基于哨兵和集群方式分别实现redis高可用

sentinel masters

基于哨兵和集群方式分别实现redis高可用

redis-cli

info replication

基于哨兵和集群方式分别实现redis高可用

测试:宕机主库,查看主从变化

2、sentinel集群实现主从高可用

简介

当遇到单机、内存、并发、流量等瓶颈时,可以采用Cluster架构方案达到负载均衡目的。

数据分布
分布式数据库首先要解决把整个数据库集按照分区规则映射到多个节点的问题,即把数据集划分到多个节点上,每个节点负责整体数据的一个子集,需要关注的是数据分片规则,Redis Cluster 采用
哈希分片规则。(任务分配,共同完成)

基于哨兵和集群方式分别实现redis高可用
基于哨兵和集群方式分别实现redis高可用

这个图中,每一个蓝色的圈都代表着一个redis的服务器节点。它们任何两个节点之间都是相互连通的。客户端可以与任何一个节点相连接,然后就可以访问集群中的任何一个节点。对其进行存取和其他操作。

实现原理
在redis的每一个节点上,都有这么两个东西,一个是插槽(slot)可以理解为是一个可以存储两个数值的一个变量这个变量的取值范围是:0-16383。还有一个就是cluster我个人把这个cluster理解为是一个集群管理的插件。当我们的存取的key到达的时候,redis会根据crc16的算法得出一个结果,然后把结果对 16384 求余数,这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽,通过这个值,去找到对应的插槽所对应的节点,然后直接自动跳转到这个对应的节点上进行存取操作

基于哨兵和集群方式分别实现redis高可用

实验:

下载aliyun镜像源和安装包

wget -O /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-7.repo
sed -i -e '/mirrors.cloud.aliyuncs.com/d' -e '/mirrors.aliyuncs.com/d' /etc/yum.repos.d/CentOS-Base.repo
wget -O /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-7.repo
yum makecache
yum -y install redis

后台执行和允许其他服务器登录

vim /etc/redis.conf

基于哨兵和集群方式分别实现redis高可用
基于哨兵和集群方式分别实现redis高可用
基于哨兵和集群方式分别实现redis高可用

创建文件

mkdir -pv /etc/redis/6380

将配置文件复制到创建的目录下

cp -a /etc/redis.conf /etc/redis/6380/redis.conf

vim /etc/redis/6380/redis.conf

10端配置:

端口号修改

基于哨兵和集群方式分别实现redis高可用

pid文件位置

基于哨兵和集群方式分别实现redis高可用

日志目录

基于哨兵和集群方式分别实现redis高可用

数据目录

基于哨兵和集群方式分别实现redis高可用

开启集群模式,指定配置文件和节点的超时时间

基于哨兵和集群方式分别实现redis高可用
基于哨兵和集群方式分别实现redis高可用
基于哨兵和集群方式分别实现redis高可用

传送给11端和12端

scp /etc/redis/6380/redis.conf 192.168.1.11:/etc/redis/6380/redis.conf
scp /etc/redis/6380/redis.conf 192.168.1.12:/etc/redis/6380/redis.conf

创建指定的目录,并修改配置文件节点目录权限

cp -a /var/lib/redis /var/lib/redis2

开启redis主节点和从节点实例

systemctl start redis
redis-server /etc/redis/6380/redis.conf

高可用

下载环境包
下载ruby包
wget ftp://ftp.pbone.net/mirror/ftp5.gwdg.de/pub/opensuse/repositories/home%3A/takehironet/CentOS_CentOS-7/x86_64/ruby-2.3.6-2.2.x86_64.rpm
安装rpm包
yum -y localinstall ruby-2.3.6-2.2.x86_64.rpm

把阿里云镜像的ruby源拉下来
查找默认源
gem sources

基于哨兵和集群方式分别实现redis高可用
#移除默认源
gem sources --remove https://rubygems.org/
#添加新源
gem sources -a https://mirrors.aliyun.com/rubygems/

查看安装后的ruby源

基于哨兵和集群方式分别实现redis高可用

安装redis运行ruby的环境
gem install redis

如果想要使用ruby脚本,需要在装一个源码包的redis

wget http://download.redis.io/releases/redis-3.2.12.tar.gz   
tar xf redis-3.2.12.tar.gz
mv  /root/redis-3.2.12/src/redis-trib.rb /root

开启所有节点

systemctl start redis
redis-server /etc/redis/6380/redis.conf

执行脚本并指定参数

./redis-trib.rb create --replicas 192.168.1.10:6379 192.168.1.11:6379 192.168.1.12:6379 192.168.1.11:6380 192.168.1.12:6380 192.168.1.10:6380

执行结果

基于哨兵和集群方式分别实现redis高可用

测试主从复制

redis-cli -p 6379 -h 192.168.1.10 -c

创建一个键值对

set a 1

去从节点查看

redis-cli -p 6380 -h 192.168.1.11 -c

测试:关闭sentinel

info sentinel

基于哨兵和集群方式分别实现redis高可用

6380成为了主库

也可以去6380看一下

也可以去6380看一下

redis-cli -p 6380

info replication

基于哨兵和集群方式分别实现redis高可用

当我们重新开启6379时

systemctl start redis

在6380查看一下

info replication

基于哨兵和集群方式分别实现redis高可用

6379成为了从库

在sentinel查看

redis-cli -h 192.168.1.10 -p 26379

基于哨兵和集群方式分别实现redis高可用

发布者:LJH,转发请注明出处:https://www.ljh.cool/5311.html

(0)
上一篇 2021年5月21日 上午11:46
下一篇 2021年6月1日 上午1:52

相关推荐

发表回复

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