Redis 主从 以及哨兵
单实例Redis 不足:
上述的是一个单实例的Redis。 我们可以先分析下有哪些不足:
- 单点故障 (是每个单实例必须面对的问题)
- 容量有限 (Redis毕竟是缓存型数据库,容量取决于服务器分配的容量,但容量毕竟是有限的)
- 压力大(如果出现高并发的场景,所有查询的压力都集中在Redis上)
所以我们的目的就是针对每个不足进行修复。
我们先来了解下 一些前置知识。
Redis 主备 认识
以上示意图就是主备
大致含义。
-
从一定程度上
主备
解决了单实例的单点故障。因为如果主Redis 如果因为某些原因停止提供服务,可以启动备Redis 继续工作。 -
但是依旧无法解决
容量有限
以及压力大
的问题。因为从始至终都是一台Redis实例在工作。
Redis 主从 认识
以上示意图就是主从
的大致含义
- 因为一旦master Redis停止服务后,slave Redis可以晋升为master,继续提供服务。所以给单点故障提供了保障
- 部署
主从
后,一般来说master 节点负责写数据。slave 节点服务读数据。这样可以有效的避免所有socket请求,都访问一个节点,从而降低了压力。
一般我们生产环境中会部署主从
。所以我们会以主从
来做详细的讲解
数据的一致性
保证
数据的一致性
是分布式部署的通病。按主从部署
来讲,虽然数据已经写入到master 节点,但是需要master节点往slave 节点同步数据。在这个同步的过程中可能因为网络等种种原因,无法正常的同步。这就面临着数据一致性的问题。
接下来我们分析几种数据一致性的方案:
强一致性
如果想要实现数据的强一致性,master节点必须等待slave节点返回正确的结果。但是实际的业务场景中,会遇到各种问题导致slave节点延迟 或是 无法返回正确的数据,所以相当于master节点写数据失败。使用这种方式会破坏高可用
弱一致性
其实弱一致性的本质就是:通过异步的形式给slave节点发送数据。如果数据发送失败了,会导致主从数据不一致。
最终一致性
其实最终一致性
是在弱一致性
的基础上做了升级。我们可以利用一些特殊的手段,最大可能性保证数据完整的传输。
比如:master节点可以将数据以同步阻塞的方式,传递给kafka
. 由kafka
给每个slave节点发送数据。有可能在某一个时点数据是不一致的,但是最终数据是一致性的。
因为kafka
给slave节点传递数据是需要时间的,如果此时间段内,数据的查询是高并发的,有可能出现部分用户拿到的数据不一致,分别是同步前 以及同步后的数据。
主从配置过程
接下俩我们实操下主从的配置过程:
步骤1:关闭Redis
也许服务器上启动了redis,如果再配置相同的端口,会出现一些意想不到的情况,所以我们先将redis关闭掉。
通过上述截图中我们会发现仍然有redis 占用6379
端口。所以我们需要将其关闭掉,下面列举出两种方式任意选择:
方案 1
直接通过kill
命令杀死进程。
kill -9 19191
通过cli 关闭redis
[root@VM-8-3-centos bin]# pwd
/opt/redis/bin
[root@VM-8-3-centos bin]# ./redis-cli shutdown
[root@VM-8-3-centos bin]# ps aux | grep redis
root 20135 0.0 0.0 112812 980 pts/0 S+ 15:40 0:00 grep --color=auto redis
[root@VM-8-3-centos bin]#
步骤2:配置主从的前置工作
创建文件
cd /opt
mkdir -p redis-replica/master
mkdir -p redis-replica/slave1
mkdir -p redis-replica/slave2
复制redis 配置文件
这里我们直接使用shell 来移动文件
- 创建并编辑 sh文件
vi mv-redis.sh
- 直接将下面的内容复制到sh中
#!/bin/bash
cp -r /opt/redis/bin/* /opt/redis-replica/master
cp -r /opt/redis/bin/* /opt/redis-replica/slave1
cp -r /opt/redis/bin/* /opt/redis-replica/slave2
- 通过命令执行shell
/bin/bash mv-redis.sh
步骤3:修改配置文件
为了不影响我们之前的单机版
Redis
,我们修改主从的配置
修改master 节点配置
修改前
# Accept connections on the specified port, default is 6379 (IANA #815344).
# If port 0 is specified Redis will not listen on a TCP socket.
port 6379
修改后
# Accept connections on the specified port, default is 6379 (IANA #815344).
# If port 0 is specified Redis will not listen on a TCP socket.
port 6380
修改slave1 节点配置
修改前
# Accept connections on the specified port, default is 6379 (IANA #815344).
# If port 0 is specified Redis will not listen on a TCP socket.
port 6379
修改后
# Accept connections on the specified port, default is 6379 (IANA #815344).
# If port 0 is specified Redis will not listen on a TCP socket.
port 6381
指定 master节点:我们需要在slave 配置文件中指定master节点
修改前
# 3) Replication is automatic and does not need user intervention. After a
# network partition replicas automatically try to reconnect to masters
# and resynchronize with them.
#
# replicaof <masterip> <masterport>
修改后
# 3) Replication is automatic and does not need user intervention. After a
# network partition replicas automatically try to reconnect to masters
# and resynchronize with them.
#
replicaof 127.0.0.1 6380
如果是不同的服务器。此处的127.0.0.1
可以修改为 指定的IP。 但是如果服务器上有密码就需要指定字段masterauth
修改slave2 配置文件
跟slave1 修改方式保持一致。只不过端口为6382
步骤4:启动服务
这次我们还是通过shell 进行启动以及关闭
#!/bin/bash
cd /opt/redis-replica/master
./redis-server ./redis.conf
cd /opt/redis-replica/slave1
./redis-server ./redis.conf
cd /opt/redis-replica/slave2
./redis-server ./redis.conf
执行shell
cd /opt/redis-replica
/bin/bash setup.sh
通过上述截图中我们看到,我们的多个redis 实例是启动成功的。
步骤5:查看 启动状态
步骤6:查看 主从信息
我们是可以通过命令
info replication
来查看在master节点中 追随了几个slave节点。
主节点设置值
从节点可以读取
步骤7:主从配置总结
如果看到这里,以为主从配置就结束了吗?不不不,如果以为就这样结束了, 那就大错特错了。上述步骤虽然进行了
主从部署
,但是master节点负责写数据,slave 节点负责读数据。如果master节点宕机了,也就是意味着Redis就不具备写的功能,基本算是废了。
如果是人工发现master节点宕机了,会将slave节点升级为master节点,其他的slave节点跟随新的master节点。
那么我们接下来分析的哨兵,就实现了该功能。应该由人做的事情,将其交给第三方插件做
哨兵
在主从部署中默认是只有主节点具备写的能力,而从节点只能读。如果主宕机,整个节点不具备写能力。但是如果这是让一个从变成主,整个节点就可以继续工作。即使之前的主恢复过来也当做这个节点的从即可。
Redis的哨兵就是帮助监控master 节点的,当节点出现宕机等情况,帮助重新选取主。
Redis中哨兵支持单哨兵和多哨兵。单哨兵是只要这个哨兵发现master宕机了,就直接选取另一个master。而多哨兵是根据我们设定,达到一定数量哨兵认为master宕机后才会进行重新选取主。我们以多哨兵演示
多哨兵模式下,选择几个合适呢???
此时我们的多哨兵节点有5个
全部哨兵节点
当master节点因为某种原因停止服务,可能所有的哨兵都检测到了。但是因为网络原因无法进行汇总,导致4个哨兵认为master宕机了,一个哨兵迟迟没有回应。
这种部署方式 有点类似于 数据强一致性
。会破坏可用性。
一个哨兵节点
- 如果是一个哨兵就可以判断master 节点是否宕机的话,会造成判断结果不精准,因为会有很多原因造成哨兵判断失误,例如:网络
- 但是如果每个哨兵结果都不同的话,会发生一种情况:
脑裂
。
n/2+1 节点
- 为了增加结果的准确性,我们建议是过半的哨兵如果判断master 节点宕机的话,那master 节点就是宕机了
- 这种方式也避免了
脑裂
的情况发生。
如果是部署4台哨兵的话,>=3台认为master宕机了,我们就认为宕机
如果是部署5台哨兵的话,>=3台认为master宕机了,我们就认为宕机
所以为了更好的分区容忍性,我们是建议部署奇数台哨兵。
哨兵配置过程
创建目录
mkdir -p /opt/redis-replica/sentinel
cp /opt/redis-replica/master/redis-sentinel /opt/redis-replica/sentinel
从之前的解压目录 复制配置文件
cp /tmp/soft/redis-5.0.14/sentinel.conf /opt/redis-replica/sentinel/
复制多份配置文件,修改配置文件
三个配置文件 修改内容类似,如下内容:
port 26379
daemonize yes
logfile "/opt/redis-replica/sentinel/26379.log"
sentinel monitor mymaster 127.0.0.1 6380 2
启动sentinel
杀死master节点,主动自动切换
文章来源:https://www.toymoban.com/news/detail-414413.html
等杀死master节点后,等待一段时间后,通过哨兵,第一个从节点升级为master节点了。文章来源地址https://www.toymoban.com/news/detail-414413.html
到了这里,关于【Redis 进阶之路】3. Redis 主从 以及哨兵的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!