Redis主从复制——哨兵模式

本文介绍了Redis主从复制的基本概念,包括其工作原理、在读写分离和故障恢复中的作用,以及哨兵模式带来的高可用性和自动化故障切换。还讨论了单点故障、容量限制及哨兵模式的优缺点。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

Redis主从复制

主从复制,是指将一台 Redis 服务器的数据,复制到其他的 Redis 服务器

  • 前者称为主节点(master / leader),后者称为从节点(slave / follower)。
  • 数据的复制是单向的,只能由主节点到从节点。
  • Master 以写为主,Slave 以读为主。
  • 一个主节点可以有多个从节点(或没有从节点),但一个从节点只能有一个主节点。
  • 默认情况下,每台 Redis 服务器都是主节点。

主从复制,读写分离,

80%操作都是读,可将写操作放在主机上,读操作放在从机上,从而减缓服务器压力

作用:

数据冗余

主从复制实现了数据的热备份,是持久化之外的一种数据冗余方式。

故障恢复

当主节点出现问题时,可以由从节点提供服务,实现快速的故障恢复。这也是一种服务的冗余。

负载均衡

在主从复制的基础上,配合读写分离,可以由主节点提供写服务,由从节点提供读服务,分担服务器负载。

尤其是在写少读多的场景下,通过多个从节点分担读负载,可以大大提高 Redis 服务器的并发量。

高可用(集群)

主从复制是哨兵和集群能够实施的基础,因此说主从复制是 Redis 高可用的基础。

一般来说,要将 Redis 运用于工程项目中,只使用一台 Redis 是万万不能的,原因如下:

  • 结构上:单个 Redis 服务器会发生单点故障,并且一台服务器需要处理所有的请求负载,压力较大。
  • 容量上:单个 Redis 服务器内存容量有限,一般来说,单台 Redis 最大使用内存不应该超过 20G。

环境配置

只用配置从机,因为Redis服务器默认自己是主机

127.0.0.1:6379> info replication        # 查看当前库信息
# Replication
role:master                         # 角色  master
connected_slaves:0                  # 从机数量
master_failover_state:no-failover
master_replid:2d3dc23fc4b48e1c653f2065edb63796e127909b
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

复制几个配置文件,修改

  1. port
  2. pid
  3. log文件名
  4. dump.rdb文件名

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

一主二从

默认情况下,每台redis服务器都是主节点

认主机

slaveof 127.0.0.1 6379
# slaveof 主机 端口

真正的主从配置应该在配置文件中配置,用命令只是暂时的,一旦重启,从机会变为主机

主机可以写,从机只能读

主机中所有的数据都能自动被从机保存

主机连接断开,从机依旧连接到主机

层层链路

在这里插入图片描述

这样的方式也能实现主从复制

中间的那个redis服务器仍然是从机,不能执行写操作

哨兵模式

主从切换技术的操作是:当主机宕机后,需要手动把一台从机切换为主机。

这就需要人工干预,费事费力,还会造成一段时间内服务不可用。

老大不在后,自动选举老大的模式

能够后台监控主机是否故障,如果故障了根据投票数自动将从机转换为主机。

原理

哨兵模式是一种特殊的模式,首先 Redis 提供了哨兵的命令,哨兵是一个独立的进程,它会独立运行。

其原理是哨兵通过发送命令,等待 Redis 服务器响应,从而监控运行的多个 Redis 实例。

这里的哨兵有两个作用:

  • 通过发送命令,让Redis服务器返回其运行状态,包括主机和从机
  • 当master宕机后,哨兵会通过投票算法,在从机中选出新主机,然后通过发布订阅模式,通知其他从机,让其修改配置文件,切换主机

然而一个哨兵进程对 Redis 服务器进行监控,可能会出现问题,为此,我们可以使用多个哨兵进行监控。

各个哨兵之间还会进行监控,这样就形成了多哨兵模式

假设哨兵1先检测到master宕机,系统不会马上进行failover(故障转移) 过程,仅仅是主观下线,等到一定数量的哨兵检测到主机宕机,就会进行一次投票选取新的主机,切换成功后,会通过发布订阅模式,各个哨兵告诉自己监控的从机切换主机,称为客观下线

优点:

  • 哨兵集群模式是基于主从模式的,所有主从的优点,哨兵模式同样具有。
  • 主从可以切换,故障可以转移,系统可用性更好。
  • 哨兵模式是主从模式的升级,系统更健壮,可用性更高。

缺点:

  • Redis较难支持在线扩容,在集群容量达到上限时在线扩容会变得很复杂。
  • 实现哨兵模式的配置也不简单,甚至可以说有些繁琐。
### 单台服务器上的Redis主从模式与哨兵配置 #### 主从复制配置 为了实现单台服务器上的Redis主从架构,在`redis.conf`文件中需针对主节点和从节点分别做相应配置。对于从节点而言,其配置应包含如下设置: - `slave-read-only yes`表示当该实例作为从属角色时只允许读操作[^1]。 具体来说,假设运行两个不同端口的Redis服务来模拟多机部署场景下的主从关系,则可以在各自的配置文件里指定监听地址及端口号,并通过命令行参数或修改配置项告知哪个是Master而哪些又是Slaves。 例如,创建名为`master.conf`用于定义Master节点的行为;同样地,为每一个Slave准备独立的`.conf`文档(比如命名为`slave_6380.conf`, `slave_6381.conf`),其中指明它们所追随的那个Master的位置信息。 ```bash # In slave_xxxx.conf files... slaveof 127.0.0.1 6379 ``` 这使得即使在同一物理机器上也能构建起逻辑分离的服务单元,从而达到实验目的。 #### 哨兵(Sentinel)监控机制 一旦完成了上述基本设定之后就可以着手安装并初始化Sentinel组件了。它负责监视整个系统的健康状况——特别是自动发现新的Slave加入进来、判断现有成员的状态变化情况等等重要职责[^2]。 编辑一个新的配置文件叫做`sentry.conf`: ```text port 26379 daemonize yes pidfile "/var/run/redis-sentinel.pid" logfile "" dir "./" sentinel monitor mymaster 127.0.0.1 6379 2 sentinel down-after-milliseconds mymaster 5000 sentinel failover-timeout mymaster 60000 sentinel parallel-syncs mymaster 1 ``` 这里的关键部分在于告诉Sentinel去跟踪哪一个集群(`mymaster`)及其对应的IP地址加端口组合(即之前提到过的那个充当Leader身份的具体实例),还有就是关于判定失败的时间阈值等细节调整。 启动哨兵程序可以通过下面的方式完成: ```bash redis-server /path/to/sentry.conf --sentinel ``` 这样就实现了在一个单独的操作系统环境中建立起完整的Redis HA解决方案框架[^3]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值