Redis系列-四种部署方式-单机部署+主从模式+哨兵模式【7】-CSDN博客

个人主页: 【⭐️个人主页】
需要您的【 点赞+关注】支持

---

Redis系列-四种部署方式-单机部署+主从模式【7】

redis-四种部署模式

• 单机模式
• 主从模式
• 哨兵模式
• 集群模式

为什么要搞这么多部署模式这就要涉及到高可用性了。

高可用是分布式的概念

Redis的高可用性是指在Redis集群中当主节点宕机了通过切换备用节点顶替它继续运行保持系统正常运行且数据可靠性不受影响。

通过实现Redis的高可用性可以提供以下几个主要优势

1. 避免单点故障通过配置和设置多个Redis节点如果其中一个节点发生故障其他节点可以接替工作避免了单点故障对整个系统的影响。

2. 数据冗余和复制通过数据的复制和持久化备份Redis能够在主节点出现故障时自动切换到备用节点并恢复数据确保数据的持久性和可用性。

3. 故障自动检测和故障转移Redis的高可用方案通常具备故障检测和自动故障转移的功能能够监控节点的健康状态并在节点故障时自动将从节点升级为主节点。

redis的高可用主要完成以下工作

1. 数据同步。主节点和从节点备用节点之间的数据需要进行同步。

2. 主从切换。若主节点宕机需要有一种机制可以切换从节点变成主节点。

单机模式

不是高可用的一般用在测试或开发节点。
本质上就是 单点redis服务提供服务给业务服务使用。一旦宕机或停机业务服务等依赖服务立刻不能使用。

直接再服务器上部署一个redis服务并提供给外部使用。

服务个数 1

主从模式

主从模式是在单机模式的基础上添加了数据备份的功能
主从复制是数据同步方式解决了单点故障的问题但不能保证高可用是高可用的基础。
主要用来实现 redis 数据的可靠性防止主 redis 所在磁盘损坏造成数据永久丢失。

在主从模式中Redis节点被分为主节点和从节点。
主节点负责处理所有的写操作
而从节点则复制主节点的数据并负责处理读操作。
主从模式的主要优点是提高了可靠性和可扩展性。
如果主节点发生故障可以使用从节点来恢复数据。

主从之间采用异步复制的方式以及采用读写分离的方式
主节点master可以进行读写操作从节点replica一般是只读。也就是说所有的数据修改只在主节点上进行然后将最新的数据同步给节点这样就使得主从服务器的数据是一致的。

需要注意的是

1主从复制无法提供高可用和数据保护能力因为主节点发生故障时需要手动进行故障转移。

2从节点主动向主节点建立连接从节点主动同步主节点的数据

数据同步的方式

全量数据同步

1. 全量数据同步是在从节点刚加入复制集群或者需要进行完整数据更新时执行的同步过程。

2. 它的目标是将主节点上的所有数据完整地同步到从节点。

   全量数据同步的过程是将主节点上的所有内存数据通过快照RDB文件方式发送给从节点从节点接收到快照后将其加载到自己的数据库中。

3. 全量数据同步会消耗较大的网络带宽和时间特别是在数据集较大的情况下。并且在全量数据同步过程中从节点无法处理外部的读取请求因为它正在重新加载大量的数据。

增量数据同步

1. 增量数据同步是在全量数据同步完成后用于保持主从节点之间数据的一致性。

2. 它通过记录主节点上的增量写命令例如AOF日志文件并将其发送给从节点来实现。

   增量数据同步的过程是在主节点上记录所有的写操作并将这些操作记录传输给从节点从节点接收到后执行这些操作以保持与主节点的数据一致。

3. 增量数据同步具有实时性可以减少数据同步的延迟

从数据库会记录一个偏移量offset即记录同步到哪里了。当从数据库断开重连主数据库补发丢失数据到从数据库。此时如果offset在环形缓冲区当中从数据库就会将offset后面的那部分数据同步过来增量同步如果offset不在环形缓存区中说明数据过期太久就会全量同步把主数据库内部所有数据都同步过来。

Redis哨兵模式

可以完成高可用性的要求.

哨兵模式是一种特殊的模式Redis 为其提供了专属的哨兵命令它是一个独立的进程能够独立运行。下面使用 Sentinel 搭建 Redis 集群基本结构图如下所示

在上图过程中哨兵主要有两个重要作用

• 第一哨兵节点会以每秒一次的频率对每个 Redis 节点发送PING命令并通过 Redis 节点的回复来判断其运行状态。
• 第二当哨兵监测到主服务器发生故障时会自动在从节点中选择一台将机器并其提升为主服务器然后使用 PubSub 发布订阅模式通知其他的从节点修改配置文件跟随新的主服务器。

在实际生产情况中Redis Sentinel 是集群的高可用的保障为避免 Sentinel 发生意外它一般是由 35 个节点组成这样就算挂了个别节点该集群仍然可以正常运转。

上图所示多个哨兵之间也存在互相监控这就形成了多哨兵模式现在对该模式的工作过程进行讲解介绍如下

1. 主观下线
主观下线适用于主服务器和从服务器。

   如果在规定的时间内(配置参数down-after-milliseconds)Sentinel 节点没有收到目标服务器的有效回复则判定该服务器为“主观下线”。

   比如 Sentinel1 向主服务发送了PING命令在规定时间内没收到主服务器PONG回复则 Sentinel1 判定主服务器为“主观下线”。.

2. 客观下线
客观下线只适用于主服务器。 Sentinel1 发现主服务器出现了故障它会通过相应的命令询问其它 Sentinel 节点对主服务器的状态判断。如果超过半数的 Sentinel 节点认为主服务器 down 掉则 Sentinel1 节点判定主服务为“客观下线”。

3. 投票选举
投票选举所有 Sentinel 节点会通过投票机制按照谁发现谁去处理的原则选举 Sentinel1 为领头节点去做 Failover故障转移操作。Sentinel1 节点则按照一定的规则在所有从节点中选择一个最优的作为主服务器然后通过发布订功能通知其余的从节点slave更改配置文件跟随新上任的主服务器master。至此就完成了主从切换的操作。

对上对述过程做简单总结

Sentinel 负责监控主从节点的“健康”状态。当主节点挂掉时自动选择一个最优的从节点切换为主节点。客户端来连接 Redis 集群时会首先连接 Sentinel通过 Sentinel 来查询主节点的地址然后再去连接主节点进行数据交互。当主节点发生故障时客户端会重新向 Sentinel 要地址Sentinel 会将最新的主节点地址告诉客户端。因此应用程序无需重启即可自动完成主从节点切换。

总结缺点

1部署麻烦哨兵模式的配置相对复杂需要管理和维护多个哨兵节点以及与它们关联的 Redis 服务器。调试和故障排除也可能变得更加困难。

2数据一致性哨兵模式下的故障转移是异步进行的这意味着在发生主服务器故障时可能会有一段时间内的数据丢失。因此在一些对数据一致性要求非常高的场景下哨兵模式可能无法满足需求。

3难以在线扩容的缺点Redis的容量受限于单机配置

4延迟增加当主服务器故障时哨兵节点需要通过选举机制选择新的主服务器并通知其他从服务器切换到新的主服务器。这个过程需要时间至少十几秒会导致系统的延迟增加。

5单点故障哨兵节点是集群的核心它们负责监控主服务器和从服务器的状态并执行故障转移操作。然而如果哨兵节点本身发生故障整个系统的可用性将会受到影响。

哨兵模式应用

Redis Sentinel 哨兵模式适合于在 Linux 系统中使用所以下面的应用都基于 Ubuntu 实现。

1. 安装SENTINEL
   Sentinel 需要作为插件单独安装安装方式如下

   sudo apt install redis-sentinel
   

2. 搭建主从模式

   接下来在本地环境使用主从模式搭建一个拥有三台服务器的 Redis 集群命令如下所示

   启动6379的redis服务器作为master主机:
   sudo /etc/init.d/redis-server start
   
   启动6380的redis服务器设置为6379的slave:
   redis-server --port 6380
   $ redis-cli -p 6380
   127.0.0.1:6380> slaveof 127.0.0.1 6379
   OK
   
   启动6381的redis服务器设置为6379的salve
   redis-server --port 6381
   $ redis-cli -p 6381
   127.0.0.1:6381> slaveof 127.0.0.1 6379
   

3. 配置SENTINEL哨兵
   首先新建 sentinel.conf 文件并对其进行配置如下所示

   port 26379
   Sentinel monitor biancheng 127.0.0.1 6379 1
   

   配置文件说明如下

   	port 26379 # sentinel监听端口默认是26379可以更改
   sentinel monitor <master-name> <ip> <redis-port> <quorum>
   
   第二个配置项表示让 sentinel 去监控一个地址为 ip:port 的主服务器这里的 master-name 可以自定义<quorum> 是一个数字表示当有多少个 sentinel 认为主服务器宕机时它才算真正的宕机掉通常数量为半数或半数以上才会认为主机已经宕机<quorum> 需要根据 sentinel 的数量设置。
   
   
   

4. 启动sentienl哨兵

   方式一: 
   redis-sentinel sentinel.conf
   方式二: 
   redis-server sentinel.conf --sentinel
   

   如果您想开启多个哨兵只需配置要多个 sentinel.conf 文件即可一个配置文件开启一个。

5. 停止主服务器服务

   下面模拟主服务意外宕机的情况首先直接将主服务器的 Redis 服务终止然后查看从服务器是否被提升为了主服务器。执行以下命令

   #终止master的redis服务
   `sudo /etc/init.d/redis-server stop`
   
   执行完上述命令您会发现 6381 称为了新的 master而其余节点变成了它的从机执行命令验证
   
   127.0.0.1:6381> set webname www.biancheng.net
   OK
   

   哨兵的配置文件 sentinel.conf 也发生了变化

   # port 26379
   # sentinel myid 4c626b6ff25dca5e757afdae2bd26a881a61a2b2
   # Generated by CONFIG REWRITE
   dir "/home/biancheng"
   maxclients 4064
   sentinel myid 4c626b6ff25dca5e757afdae2bd26a881a61a2b2
   sentinel monitor biancheng 127.0.0.1 6379 1
   sentinel config-epoch biancheng 2
   sentinel leader-epoch biancheng 2
   sentinel known-slave biancheng 127.0.0.1 6379
   sentinel known-slave biancheng 127.0.0.1 6380
   sentinel known-slave biancheng 127.0.0.1 6381
   port 26379
   sentinel current-epoch 2
   

sentinel.conf配置项

下面对 Sentinel 配置文件的其他配置项做简单说明

sentinel配置文件说明
配置项	参数类型	说明
dir	文件目录	哨兵进程服务的文件存放目录默认为 /tmp。
port	端口号	启动哨兵的进程端口号默认为 26379。
sentinel down-after-milliseconds	<服务名称><毫秒数(整数)>	在指定的毫秒数内若主节点没有应答哨兵的 PING 命令此时哨兵认为服务器主观下线默认时间为 30 秒。
sentinel parallel-syncs	<服务名称><服务器数(整数)>	指定可以有多少个 Redis 服务同步新的主机一般而言这个数字越小同步时间越长而越大则对网络资源要求就越高。
sentinel failover-timeout	<服务名称><毫秒数(整数)>	指定故障转移允许的毫秒数若超过这个时间就认为故障转移执行失败默认为 3 分钟。
sentinel notification-script	<服务名称><脚本路径>	脚本通知配置当某一事件发生时所需要执行的脚本可以通过脚本来通知管理员例如当系统运行不正常时发邮件通知相关人员。
sentinel auth-pass	<服务器名称><密码>	若主服务器设置了密码则哨兵必须也配置密码否则哨兵无法对主从服务器进行监控。该密码与主服务器密码相同。

REF

https://zhuanlan.zhihu.com/p/615864640