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

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

---

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 发生意外，它一般是由 3～5 个节点组成，这样就算挂了个别节点，该集群仍然可以正常运转。

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

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
   1

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
   1
   2
   3
   4
   5
   6
   7
   8
   9
   10
   11
   12
   13

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

   port 26379
   Sentinel monitor biancheng 127.0.0.1 6379 1
   1
   2

   配置文件说明如下：

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

4. 启动sentienl哨兵

   方式一: 
   redis-sentinel sentinel.conf
   方式二: 
   redis-server sentinel.conf --sentinel
   1
   2
   3
   4

   如果您想开启多个哨兵，只需配置要多个 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
   1
   2
   3
   4
   5
   6
   7

   哨兵的配置文件 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
   1
   2
   3
   4
   5
   6
   7
   8
   9
   10
   11
   12
   13
   14

sentinel.conf配置项

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

REF

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