Redis四种部署模式（原理、优缺点及解决方案）

少年做自己的英雄

已于 2023-04-12 22:16:12 修改

阅读量1.4w

点赞数 32

分类专栏： Redis 文章标签： redis 缓存集群部署模式

于 2021-09-16 00:02:15 首次发布

本文链接：https://blog.csdn.net/qq_26012495/article/details/120299332

版权

Redis 专栏收录该内容

3 篇文章 1 订阅

订阅专栏

目录

一、单节点模式

二、主从模式

2.1 主从复制

2.2 读写分离

2.3 主要作用

三、哨兵模式

3.1 定时监控任务

3.2 主观下线和客观下线

3.3 Sentinel集群的领导者选举

3.4 故障转移

四、集群模式

五、常见问题

1、Sentinel节点为什么是至少三个且奇数个？

2、Redis集群节点数为什么至少是6个？

3、为什么Redis Cluster槽位设计成16384个？
单节点模式
主从模式
哨兵模式（Sentinel）【2.8版本开始提供】
集群模式（Cluster）【3.0版本开始提供】

一、单节点模式

Redis默认启动，什么都不配置，默认就是Master节点，简单却不具备高可用。

优点

配置简单，操作简单

缺点

单点的宕机引来的服务的灾难、数据丢失
单点服务器内存瓶颈，无法无限纵向扩容

解决办法

单节点宕机，可以由其他节点暂时顶替，宕机的慢慢排查

二、主从模式

优点

有了主从，提高了Redis整体的可用性，当主节点（master）挂了，可以把从节点（slave）手动升级为主节点继续服务。

缺点

master挂了整个Redis将失去写操作的能力，仅具备读操作，需要运维半夜爬起来手动升级，中间的请求失败数据丢失无法容忍。

解决办法

可以有一种方式自动升级slave为master ------【哨兵】

2.1 主从复制

从一台Redis服务器的数据（主节点master），复制到其他Redis服务器（从节点slave）。数据复制单向，只能由主节点到从节点，master可读可写，slave只可读不可写；默认每台Redis服务器都是主节点，从节点需要在配置文件中单独配置，才会从默认的主节点变成从节点。一个主节点可以有0个或多个从节点，但每个从节点只能有一个主节点。

2.1.1 复制原理

slave第一次连接master，一定会执行一次全量复制
全量复制数据量过大，会造成很大的网络开销，消耗CPU/内存/硬盘IO
增量复制用于处理在主从复制中因网络等数据丢失的场景，当slave再次连接上master，并且就是原来的master，如果条件允许，master补发数据给slave，补发数据量小，避免全量复制的开销（到底能不能复制还要看offset和buffer的情况）
如果slave再次连上的master是新选举的master，那么只能进行全量复制
早期的redis只有全量复制，增量复制是对全量复制的重大优化，尽量采用2.8以上版本

2.1.1.1 全量复制

slave给master发一个sync同步命令
master通过bgsave命令fork子进程，持久化生成RDB文件
master通过网络将RDB文件传给slave
slave清空老数据，载入新的RDB文件，此时slave阻塞，无法响应客户端，专心复制

2.1.1.2 增量复制

主从节点各自维护自己的复制偏移量offset，主节点写入命令时，offset=offset+命令字节长度；从节点收到主节点命令也会相应增加自己的offset，并同步给主节点。主节点同时维护自己的offset和从节点的offset，以此来判断主从节点数据是否一致。
主节点指令记录在本地buffer（缓冲区），异步将buffer同步给从节点
若网络不好，同步速度慢了，buffer满了就会从头开始覆盖前面的内容，于是无法增量复制，必须全量复制

2.2 读写分离

大部分情况都是读操作，将读操作放在从节点，写操作放在主节点，减缓服务器压力；同时一些执行耗时比较久的操作也可以放在一台从节点完成，例如keys、sort。（什么时候连主节点写，什么时候连从节点读，由客户端自己控制）

最低配：一主二从，当主节点宕机后，其中一个从节点升级为主节点，还能剩一个从节点。

2.3 主要作用

数据冗余：热备份，持久化另一种方式
故障恢复：master宕机，快速升级slave为master
读写分离：master写，slave，提高服务器负载能力，同时可以根据需求添加slave
负载均衡：配合读写分离，读多写少场景，多个slave分担负载，大大提高并发
高可用基石：是实现哨兵和集群的基础

三、哨兵模式

试想一下，如果主从模式中，大半夜主节点挂了，运维从床上迷迷糊糊爬起来，打开电脑，手动升级处理，怕不是第二天就要上头条了。

哨兵模式的出现用于解决主从模式中无法自动升级主节点的问题，一个哨兵是一个节点，用于监控主从节点的健康，当主节点挂掉的时候，自动选择一个最优从节点升级为主节点。

但哨兵如果挂了怎么办？于是哨兵一般都会是一个集群，是集群高可用的心脏，一般由3-5个节点组成，即使个别节点挂了，集群还可以正常运行。

优点

可以在master挂掉后自动选举新的master

缺点

master挂了，切换新的master会造成未来得及主从同步的数据丢失
大数据高并发，单个master内存仍存在上限
主从全量同步仍然要耗费大量时间
单个Redis只能利用CPU的单个核心，应对海量数据捉襟见肘

解决办法

Redis集群方案

客户端连接Redis，会首先连接Sentinel，通过Sentinel查询master地址，然后再连接master进行数据交互。当master挂了，客户端重新跟Sentinel要master地址，连接新的master。

上图中可看，master挂了，原先的主从复制断开，客户端和master也断开。然后一个slave变成新的master，和其余的slave进行新的主从复制，客户端通过新的master继续交互，Sentinel持续监控已经挂掉的旧的master，一旦旧的master恢复，集群会变为下图，旧的master成为新的slave，从新的master建立主从复制关系。

一个Sentinel或Sentinel集群可以管理多个主从Redis，如果只有一个Redis，Sentinel没有意义
master挂了，Sentinel在slave中选举一个升级为master，并修改配置文件
挂了的master恢复后，只能当slave，跟新选举的master主从复制
Sentinel有可能会挂，所以Sentinel一般都是一个集群
每个Sentinel节点定期检测Redis数据节点、其余Sentinel节点是否可达
对于节点的故障是由多个Sentinel节点共同完成，有效防止误判
Redis主从复制为异步，master挂了，从节点可能会丢失一部分信息，Sentinel无法保证消息完全不丢失，但可以做到尽量少丢失
Sentinel.slave_for方法可以从连接池内采用轮询方案拿出一个slave地址，实现负载均衡

3.1 定时监控任务

每隔10秒，每个Sentinel节点会向主节点和从节点发送info命令获取最近的拓扑结构，可以感知新加入或故障转移的Redis数据节点
每隔2秒，每个Sentinel节点会与其他Sentinel节点通信，可以发现新的Sentinel节点，并与其他Sentinel节点交换对主节点的判断信息，方便故障转移及选举
每隔1秒，每个Sentinel节点会向主节点、从节点以及其他的Sentinel节点发送ping做一次心跳检测，来确认这些节点是否可达，实现对每个节点的监控