Redis-主从模式

目录

前言

一.主从节点介绍

二.配置redis主从结构 

二.主从复制

四.拓扑结构

五.数据同步

全量复制（Full Sync Replication）

局部复制（Partial Replication）

---

Redis的学习专栏：http://t.csdnimg.cn/a8cvV

前言

      在Redis当中，"节点"（node）通常指的是一个 Redis 实例，也可以称为 Redis 服务器。Redis 是一个内存中的数据结构存储系统，每个 Redis 服务器可以独立运行，管理自己的数据和客户端连接。  

Redis 支持单节点部署、主从复制、哨兵模式和集群部署：

1. 单节点模式：单个 Redis 服务器独立运行，处理所有的读写请求。

2. 主从复制：Redis 支持主从复制，即一个主节点可以拥有多个从节点。主节点负责写操作和数据同步，而从节点负责读操作。

3. 哨兵模式：Redis Sentinel 是一种监控和管理 Redis 实例的工具，可以用于实现高可用性。通过配置多个 Sentinel 和 Redis 主从节点，Sentinel 可以自动检测故障并进行故障转移，确保系统在主节点故障时能够自动切换到备用节点，保证服务的持续可用性。

4. 集群模式：多个 Redis 节点组成一个 Redis 集群。Redis 集群分为主节点（master）和从节点（slave）。主节点负责处理客户端请求和写操作，从节点则复制主节点的数据，负责读操作和故障转移。集群模式通过槽（slot）分区机制来分布数据，每个节点负责处理其中一部分数据的存储和操作。

但单节点往往会出现问题 ：

1. 单节点部署意味着整个 Redis 服务的可用性完全依赖于单个实例。如果这个实例发生故障，整个服务将不可用，导致系统中断或者数据不可访问。
2. 单个 Redis 实例的性能受到硬件资源的限制，如CPU、内存和网络带宽。一旦达到硬件资源的极限，无法进一步提升系统的性能。
3. 单节点部署可能会受到数据容量的限制。Redis 是一个内存数据库，其容量受到服务器内存的限制。如果数据量超过了单台服务器的处理能力，可能需要分片或者其他技术来处理大数据量。

因此分布式系统中的Redis使用的部署方式：主从复制、哨兵模式、集群模式

---

一.主从节点介绍

        在Redis节点上，存在主节点和从节点。假设三个redis服务器，我们分别部署一个redis-server进程，此时此刻，我们将一个节点作为主节点，另外两个作为从节点，从此从节点上的数据需要跟随主节点而改变，从节点是主节点的复制品，只能接收主节点的复制命令。

1. 主节点（Master）：

   • 主节点是数据的原始来源，负责处理客户端的写操作（写入数据）。
   • 主节点会将自己的写操作记录（写命令）发送给所有从节点，使得所有从节点都能保持与主节点的数据同步。

2. 从节点（Slave）：

   • 从节点是主节点的复制品，它们通过复制主节点的数据来实现与主节点的数据同步。
   • 从节点只能接收来自主节点的复制命令，并且不能接收客户端的写请求（只读）。
   • 从节点可以处理客户端的读请求，因此可以用来扩展读性能。

优点：单点模式，如果单个redis服务器挂了，整个服务将不可用，导致系统中断或者数据不可访问。但是主从节点，节点数目多，因此除非全世界停电，不然不可能数据不可访问！

二.配置redis主从结构 

        配置redis的主从结构，我们需要启动多个redis服务器。而分布式的概念即是每一个redis服务器程序在一个单独的主机上！

目前，我只有一个云服务器，但是我可以通过更改redis的端口，从而在云服务器主机运行多个redis-server进程。

1. 启动程序时，通过命令行直到端口号
2. 直接在配置文件中，设定端口

前提：redis没有密码！！！有密码可以参考第三节知识点

主要步骤：

1.配置文件redis.conf的修改

port 6379       # 设置主节点的端口号，通常为默认的6379
bind 0.0.0.0    # 绑定所有网络接口，或者指定特定IP
protected-mode no  # 如果需要从其他机器连接，需设置为no

2.复制redis.conf配置文件，修改名字 例如 A.conf和B.conf,修改复制的配置文件的启动端口号，任意端口号。然后添加一条指令：slaveof  IP地址 端口号  注：6版本之后使用 replicaof

3.在linux上创建一个文件夹，将两个配置配置放入其中

  3种方式配置主从结构：

1. 在配置文件当中加入，slaveof{masterHost} {masterPort} ,redis启动就有效
2. 在redis-server启动命令中加入 slaveof{masterHost}{masterPosrt} 生效
3. 直接使用redis命令：slaveof  {masterHost} {masterPort}         

    4.重启redis-server，但是netstat -anp | grep redis-server;然后使用kill杀死已经启动的进程

绑定查看：

可以判断是否连接上从节点：info replication

此时此刻，我们在主节点里写入数据，从节点也能获取到数据！

断开主从结构，在从节点里，发布命令：slaveof no one

二.主从复制

 结构流程图：

        从节点复制主节点的数据有以下注意点： 

安全性

        如果主节点设置了密码，从节点可以在配置文件中或者使用 replicaof 命令时指定密码。

replicaof master_ip master_port password your_password

         如果你使用的是6版本前的Redis，可以使用 slaveof 命令来配置从节点连接到主节点，也可以在Redis命令行中手动指定密码：

127.0.0.1:6379> AUTH password
127.0.0.1:6379> slaveof master_ip master_port

只读性

        默认情况下，从节点使用slave -read-only = yes 配置为只读节点，由于复制只能从主节点到从节点，对于从节点的修改，主节点一无所知，修改会造成主从数据不一致！

传输延迟

  原因：

1. 从节点与主节点之间的网络延迟（TCP的nagle算法）会导致从节点在接收到主节点更新数据的时间上有所滞后
2. 从节点本身处理了大量的读请求或者其他任务，可能会延迟从主节点接收新数据的更新。
3. 复制缓冲区来临时存储从主节点接收到的数据，如果复制缓冲区的大小不足或者由于某些原因（如瞬时的高网络负载）而导致延迟。

TCP的nagle算法：可以手动关闭，Redis当中的repl-disable-tcp-nodelay

1. 当关闭时，主节点产生的命令数据无论大小都会及时地发送给从节点，这样主从之间延迟会变小，但增加了网络带亮的消耗，适用于主从之间的网络环境良好的场景，如同机房部署。
2. 当开启时，主节点会合并较小的 TCP 数据包从而节省带宽。默认发送时间间隔取决于 Linux 的内核，一般默认为 40 毫秒。这种配置节省了带宽但增大主从之间的延迟。适用于主从网络环境复杂的场景，如跨机房部署。

四.拓扑结构

第一种结构：一主一仆

         大量的数据写入时，会给主节点造成压力，可以通过关闭主节点的AOF，在节点上开启AOF，但是这种情况下，也不安全，因为主节点一旦挂了，那么自动重启之后，由于没有AOF文件，无法恢复数据，然后从节点拷贝主节点，导致从节点给删除了！

 第二种：一主多仆

        主节点存储所有的写入数据，从节点作为备份，一旦主节点发生故障，可以快速将一个从节点升级为新的主节点，减少系统宕机时间和数据丢失的风险，将从节点部署在不同的地理位置或者逻辑集群中，可以在地理上分布数据，提高数据的局部性和访问速度。

缺点：

1. 主节点需要同时向多个从节点传输数据，可能会消耗大量的网络带宽。
2. 在主从复制中，由于主节点和从节点之间存在网络延迟和复制延迟，可能会导致从节点数据落后于主节点。虽然Redis保证最终一致性，但在数据复制期间可能会出现一段时间内的数据不一致

第三种：树形结构

这种情况可以解决主从传输次数多的情况，就是，从节点挂着从节点！缺陷：同步延时更长！

五.数据同步

    redis提供了psync命令，完成该命令。且不需要手动执行，建立好主从关系之后，自动执行！从节点复制执行psync，从节点从主节点获取数据！同步过程分为2种：

全量复制和局部复制 

指令命令：PSYNC replication_ID offset 

ID:每个Redis主节点在启动时都会生成一个唯一的运行ID。这个ID用于标识主节点当前的状态，包括复制进度和已经应用的命令数目。

offest: 表示从节点希望从主节点复制的数据的起始位置。对于部分同步，从节点会告诉主节点自己最后一次成功复制的位置（偏移量），主节点将从这个偏移量之后的数据发送给从节点。为-1 则是全量复制

全量复制（Full Sync Replication）

全量复制是Redis主从复制（Master-Slave Replication）的基本模式，主要流程包括：

1. 初次同步： 当一个从节点连接到主节点时，如果是第一次复制，主节点会将自己的整个数据集发送给从节点。这个过程中，从节点会被阻塞，直到数据完全同步完成。发送psync ? -1

2. 主节点回应：根据命令，解析，并且返回+FULLRESYNC响应

3. 持续同步： 在初次同步后，从节点会继续监听主节点的命令流，通过接收主节点的写命令来更新自己的数据集，保持与主节点的数据一致性。

4. 主节点执行 bgsave 进行 RDB 文件的持久化。

5. 从节点发送 RDB 文件给从节点，从节点保存 RDB 数据到本地硬盘.

6. 主节点将从生成 RDB 到接收完成期间执行的写命令，写入缓冲区中，等从节点保存完 RDB 文件后，主节点再致传入从节点。

7. 从节点加载 RDB 文件得到与主节点一致的数据。

8. 如果从节点加载 RDB 完成之后，并且开启了 AOF 持久化功能，它会进行 bgrewrite 操作，得到最近的 AOF 文件。

提问：RDB文件传输给子节点？能不能直接网络传输到从节点呢？

答：可以，但是虽然逐条命令传输可能在某些情况下更快，但这种方法会消耗更多的网络带宽和系统资源。如果主节点发生故障或者网络中断，从节点可以依赖其本地存储的RDB文件来进行恢复。这种方式可以提高系统的可用性和容错性。

局部复制（Partial Replication）

局部复制是一种在特定条件下可用的复制模式，主要特点包括：

1. 选择性复制： 局部复制允许从节点只复制部分的主节点数据集。这可以通过配置来指定需要复制的特定键空间，而不是复制整个数据集。

2. 应用场景： 局部复制适合于需要部分数据的读取操作，可以帮助减轻从节点的负载，专注于特定的数据集，提高性能和效率。

3. 配置灵活性： Redis允许管理员在需要的时候配置和启用局部复制，这样可以根据实际业务需求来调整和优化数据复制的效率和成本。

 额外补充

实时复制

        全局复制用于第一次建立连接，部分复制用于因为网络抖动而暂时断开连接，而实时复制是从节点和主节点之间同步好数据，然后主节点时时刻刻收到新的数据，并且同步给从节点！

在当中，节点和主节点会建立TCP长连接，主节点把自己收到的数据修改请求发送给从节点，从而一致性！

如何保证一致性呢？保证连接一直都是可用状态

心跳包机制

主节点：默认每隔10s从节点发送一个ping命令，从节点收到返回pong

从节点：默认每隔1s给主节点发送一个特点的请求，就会上报当前从节点复制数据的进度

如果未收到响应，则就断了！

额外补充：从节点升级为主节点，通过哨兵方式！