深度讲解Redis主从复制、哨兵、Cluster三种模式

在Redis中，有三种不同的部署模式：主从复制(Master-Slave Replication)、哨兵(Sentinel)模式和集群(Cluster)模式。每种模式都有其特定的用途和优势，适用于不同的场景。下面我将分别介绍这三种模式，并探讨它们的特点和应用。

redis集群类型

redis集群模式主要有以下几种方式：

主从复制(redis2.8版本之前的模式)

Redis Sentinel 哨兵模式(redis2.8及之后的模式)

Redis Cluster集群模式(客户端sharding)(redis3.0版本之后)

Jedis sharding集群(客户端sharding)

利用中间件代理

在这里主要讲述主从复制、哨兵模式、Redis Cluster集群这三种方式。

主从复制

主从复制概念

主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master)，后者称为从节点(slave)，数据的复制是单向的，只能由主节点到从节点。

默认情况下，每台Redis服务器都是主节点;且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。

如果Master和Slave之间的链接出现断连现象，Slave可以自动重连Master，但是在连接成功之后，一次完全同步将被自动执行。

工作原理

从服务器连接主服务器，发送SYNC命令;

主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令;

主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令;

从服务器收到快照文件后丢弃所有旧数据，载入收到的快照;

主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令;

从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令;(从服务器初始化完成)

主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令 (从服务器初始化完成后的操作)

主从复制启用

从节点开启主从复制，有3种方式：

配置文件：在从服务器的配置文件中加入：slaveof

启动命令： redis-server启动命令后加入 --slaveof

客户端命令： Redis服务器启动后，直接通过客户端执行命令：slaveof

，则该Redis实例成为从节点。

通过 info replication 命令可以看到复制的一些信息

主从复制优缺点

优点

支持主从复制，可以进行读写分离

为了分载Master的读操作压力，Slave服务器可以为客户端提供只读操作的服务，写服务仍然必须由Master来完成

Slave同样可以接受其它Slaves的连接和同步请求，这样可以有效的分载Master的同步压力。

Master Server是以非阻塞的方式为Slaves提供服务。所以在Master-Slave同步期间，客户端仍然可以提交查询或修改请求。

Slave Server同样是以非阻塞的方式完成数据同步。在同步期间，如果有客户端提交查询请求，Redis则返回同步之前的数据

缺点

Redis不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复。

主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性。

Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。

哨兵模式

基本概念

当主服务器中断服务后，可以将一个从服务器升级为主服务器，以便继续提供服务，但是这个过程需要人工手动来操作。为此，Redis 2.8中提供了哨兵工具来实现自动化的系统监控和故障恢复功能。

它的功能包括以下两个：

监控主服务器和从服务器是否正常运行。

主服务器出现故障时自动将从服务器转换为主服务器。

哨兵模式的优缺点

优点

哨兵模式是基于主从模式的，所有主从模式的优点，哨兵模式都具有。

主从可以自动切换，进行故障转移，系统更健壮，可用性更高。

缺点

Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。

Redis-Cluster集群

cluster集群概述

在 Redis 3.0 之前，使用 哨兵(sentinel)机制来监控各个节点之间的状态，基本已经可以实现高可用，读写分离。

而Redis Cluster 是 Redis 的分布式解决方案，在 3.0 版本正式推出，有效地解决了 Redis 在 分布式 方面的需求。当遇到 单机内存、并发、流量 等瓶颈时，可以采用 Cluster 架构方案达到 负载均衡 的目的。

Redis 支持三种集群模式，分别为主从模式、哨兵模式和Cluster模式。

最初，Redis采用主从模式构建集群。在这种模式下，如果主节点(master)出现故障，需要手动将从节点(slave)转换为主节点。然而，这种模式在故障恢复方面效率不高。

为了提高系统的可用性，Redis引入了哨兵模式。在哨兵模式中，一个哨兵集群负责监控主节点和从节点。如果检测到主节点故障，系统可以自动将从节点晋升为新的主节点。这提高了故障恢复的自动化程度。

尽管如此，哨兵模式仍然面临内存容量和写入性能的限制，因为这种模式的写入能力仍然局限于单个节点。为了解决这一问题，Redis在3.x版本之后推出了Cluster集群模式。Cluster模式通过数据分片和节点的水平扩展，实现了更高效的内存利用和写入性能。

Redis 主从模式架构介绍

概要

在Redis的主从复制架构中，系统通过定义主库(master)和从库(slave)的角色，实现数据的高效同步和备份。这一架构具体包含以下特点：

master的读写能力：master是系统中的数据中心，它不仅承担全部的写操作，还能处理读请求。当在master上执行任何改变数据的操作时，这些更改会自动且实时地同步到所有slave。

单向数据流：数据同步流是单向的，意味着数据只从master流向slave，确保了数据同步的一致性和可靠性。

slave的只读特性：slave通常被配置为只读模式，它们接收并存储从master传来的数据。这样设计主要是为了分散读取压力，从而提高系统的整体读取性能。

主slave的对应关系：一个master可以对应多个slave，形成一对多的关系。这种结构利于数据的冗余备份和读取负载的分散。相反，一个slave只能对应一个master，以保持数据同步的一致性。

slave的容错性：如果某个slave出现故障，它对系统其他部分的影响是最小的。即便在slave宕机的情况下，其它slave仍能继续提供读服务，master也能保持正常的读写操作。当故障的slave恢复后，它会自动从master同步缺失的数据。

master故障的影响：master的故障会导致Redis暂时无法处理新的写请求，但已连接的slave可以继续提供读服务。一旦master恢复，Redis会重新提供完整的读写服务。

master故障的应对机制：在当前的master发生故障时，系统不会自动在slave中选择一个新的master。这需要通过额外的高可用性解决方案来实现，例如使用Redis Sentinel或Redis Cluster来管理master的选举和故障转移。

在Redis主从复制架构，Redis能够有效地提供高可用性、数据冗余以及读写分离，从而在维持高性能的同时确保数据的安全和一致性。

Redis主从复制原理

在本文档中，我们将重点介绍Redis版本2.8及其后续版本的主从复制机制。

无是哪种场景，Redis 的主从复制机制均采用异步复制，也称为乐观复制，因此不能完全保证主从数据的一致性。

不论在什么场景下，Redis的主从复制机制都采用了所谓的“异步复制”或“乐观复制”。这种复制方式意味着不能完全保证主库和从库数据的实时一致性。

Redis的主从复制机制可以根据不同的运行场景和条件采取不同的实现方式。以下是一些主要场景及其对应的复制实现和说明：

第一次启动：在从库第一次连接到主库时，将采用psync复制方式进行全量复制。这意味着从库会从头开始复制主库中的全部数据。

正常运行期间：在正常运行状态下，从库通过读取主库的缓冲区来进行增量复制。这个过程涉及复制主库上发生的新的数据变更。

从库第二次启动(主库缓冲区未溢出)：当从库重新启动且主库的缓冲区未溢出时，将通过读取主库的缓冲区进行部分复制。这种方式能够快速同步中断期间发生的数据变更，而不会对主库造成重大影响。

Redis 2.8及以上版本的从库第二次启动(针对主库)：当从库第二次启动且系统版本为Redis 2.8或以上时，将采用psync复制进行全量复制。这种情况通常发生在主库的缓冲区数据无法满足从库需要同步的数据量时。

通过上述不同的复制策略，Redis能够在保证数据备份和减少系统负载的同时，灵活应对各种运行场景。尽管异步复制机制可能导致主从数据存在短暂的不一致，但这种设计在绝大多数应用场景中已被证明是既高效又可靠的。

PS：异步复制是Redis的复制方式，而psync是实现这种复制方式的具体命令。乐观复制或乐观并发控制则是另一种与Redis的异步复制机制不同的数据库事务处理概念。不少博客或说明介绍异步复制和乐观复制是同一个概念。

PSYNC 工作原理

PSYNC 命令是Redis中用于从节点与主节点之间数据同步的关键命令。它的工作原理包括以下几个步骤：

启动或重连判断：

当从节点(Slave)启动或与主节点(Master)的连接断开后重连时，从节点需要确定是否曾经同步过。

如果从节点没有保存任何主节点的运行ID(runid)，它将视为第一次连接到主节点。

第一次同步处理：

在第一次同步的情况下，从节点会发送 PSYNC -1 命令给主节点，请求进行全量数据同步。

全量同步是指主节点将其所有数据完整地复制一份给从节点。

断线重连处理：

对于之前已经同步过的从节点，它会发送 PSYNC runid offset 命令，其中runid是主节点的唯一标识符，offset是从节点上次同步数据的偏移量。

主节点的响应：

主节点接收到PSYNC命令后，会检查runid是否匹配，以及offset是否在复制积压缓冲区的范围内。

如果匹配且offset有效，主节点将回复CONTINUE，并发送自从节点上次断开连接以来的所有写命令。

全量同步触发条件：

如果runid不匹配，或offset超出了积压缓冲区的范围，主节点将通知从节点执行全量同步，回复FULLRESYNC runid offset。

复制积压缓冲区的作用：

主节点会在处理写命令的同时，将这些命令存入复制积压队列，同时记录队列中存放命令的全局offset。

当从节点断线重连，且条件允许时，它可以通过offset从积压队列中进行增量复制，而不是全量复制。

数据一致性保障：

PSYNC机制允许从节点在网络不稳定或其他意外断开连接的情况下，能够以增量方式重新同步数据，保持主从节点数据的一致性。

PS：判断是否进行全量同步，需要考虑两个关键因素：首先，确认这是否是第一次进行数据同步;其次，检查缓存区是否已经达到或超过其容量上限。只有在是第一次同步，或者缓存区已溢出的情况下，才会执行全量同步。