目录
前言
在Redis当中,"节点"(node)通常指的是一个 Redis 实例,也可以称为 Redis 服务器。Redis 是一个内存中的数据结构存储系统,每个 Redis 服务器可以独立运行,管理自己的数据和客户端连接。
Redis 支持单节点部署、主从复制、哨兵模式和集群部署:
-
单节点模式:单个 Redis 服务器独立运行,处理所有的读写请求。
-
主从复制:Redis 支持主从复制,即一个主节点可以拥有多个从节点。主节点负责写操作和数据同步,而从节点负责读操作。
-
哨兵模式:Redis Sentinel 是一种监控和管理 Redis 实例的工具,可以用于实现高可用性。通过配置多个 Sentinel 和 Redis 主从节点,Sentinel 可以自动检测故障并进行故障转移,确保系统在主节点故障时能够自动切换到备用节点,保证服务的持续可用性。
-
集群模式:多个 Redis 节点组成一个 Redis 集群。Redis 集群分为主节点(master)和从节点(slave)。主节点负责处理客户端请求和写操作,从节点则复制主节点的数据,负责读操作和故障转移。集群模式通过槽(slot)分区机制来分布数据,每个节点负责处理其中一部分数据的存储和操作。
但单节点往往会出现问题 :
- 单节点部署意味着整个 Redis 服务的可用性完全依赖于单个实例。如果这个实例发生故障,整个服务将不可用,导致系统中断或者数据不可访问。
- 单个 Redis 实例的性能受到硬件资源的限制,如CPU、内存和网络带宽。一旦达到硬件资源的极限,无法进一步提升系统的性能。
- 单节点部署可能会受到数据容量的限制。Redis 是一个内存数据库,其容量受到服务器内存的限制。如果数据量超过了单台服务器的处理能力,可能需要分片或者其他技术来处理大数据量。
因此分布式系统中的Redis使用的部署方式:主从复制、哨兵模式、集群模式
一.主从节点介绍
在Redis节点上,存在主节点和从节点。假设三个redis服务器,我们分别部署一个redis-server进程,此时此刻,我们将一个节点作为主节点,另外两个作为从节点,从此从节点上的数据需要跟随主节点而改变,从节点是主节点的复制品,只能接收主节点的复制命令。
-
主节点(Master):
- 主节点是数据的原始来源,负责处理客户端的写操作(写入数据)。
- 主节点会将自己的写操作记录(写命令)发送给所有从节点,使得所有从节点都能保持与主节点的数据同步。
-
从节点(Slave):
- 从节点是主节点的复制品,它们通过复制主节点的数据来实现与主节点的数据同步。
- 从节点只能接收来自主节点的复制命令,并且不能接收客户端的写请求(只读)。
- 从节点可以处理客户端的读请求,因此可以用来扩展读性能。
优点:单点模式,如果单个redis服务器挂了,整个服务将不可用,导致系统中断或者数据不可访问。但是主从节点,节点数目多,因此除非全世界停电,不然不可能数据不可访问!
二.配置redis主从结构
配置redis的主从结构,我们需要启动多个redis服务器。而分布式的概念即是每一个redis服务器程序在一个单独的主机上!
目前,我只有一个云服务器,但是我可以通过更改redis的端口,从而在云服务器主机运行多个redis-server进程。
- 启动程序时,通过命令行直到端口号
- 直接在配置文件中,设定端口
前提: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种方式配置主从结构:
- 在配置文件当中加入,slaveof{masterHost} {masterPort} ,redis启动就有效
- 在redis-server启动命令中加入 slaveof{masterHost}{masterPosrt} 生效
- 直接使用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 配置为只读节点,由于复制只能从主节点到从节点,对于从节点的修改,主节点一无所知,修改会造成主从数据不一致!
传输延迟
原因:
- 从节点与主节点之间的网络延迟(TCP的nagle算法)会导致从节点在接收到主节点更新数据的时间上有所滞后
- 从节点本身处理了大量的读请求或者其他任务,可能会延迟从主节点接收新数据的更新。
- 复制缓冲区来临时存储从主节点接收到的数据,如果复制缓冲区的大小不足或者由于某些原因(如瞬时的高网络负载)而导致延迟。
TCP的nagle算法:可以手动关闭,Redis当中的repl-disable-tcp-nodelay
- 当关闭时,主节点产生的命令数据无论大小都会及时地发送给从节点,这样主从之间延迟会变小,但增加了网络带亮的消耗,适用于主从之间的网络环境良好的场景,如同机房部署。
- 当开启时,主节点会合并较小的 TCP 数据包从而节省带宽。默认发送时间间隔取决于 Linux 的内核,一般默认为 40 毫秒。这种配置节省了带宽但增大主从之间的延迟。适用于主从网络环境复杂的场景,如跨机房部署。
四.拓扑结构
第一种结构:一主一仆
大量的数据写入时,会给主节点造成压力,可以通过关闭主节点的AOF,在节点上开启AOF,但是这种情况下,也不安全,因为主节点一旦挂了,那么自动重启之后,由于没有AOF文件,无法恢复数据,然后从节点拷贝主节点,导致从节点给删除了!
第二种:一主多仆
主节点存储所有的写入数据,从节点作为备份,一旦主节点发生故障,可以快速将一个从节点升级为新的主节点,减少系统宕机时间和数据丢失的风险,将从节点部署在不同的地理位置或者逻辑集群中,可以在地理上分布数据,提高数据的局部性和访问速度。
缺点:
- 主节点需要同时向多个从节点传输数据,可能会消耗大量的网络带宽。
- 在主从复制中,由于主节点和从节点之间存在网络延迟和复制延迟,可能会导致从节点数据落后于主节点。虽然Redis保证最终一致性,但在数据复制期间可能会出现一段时间内的数据不一致
第三种:树形结构
这种情况可以解决主从传输次数多的情况,就是,从节点挂着从节点!缺陷:同步延时更长!
五.数据同步
redis提供了psync命令,完成该命令。且不需要手动执行,建立好主从关系之后,自动执行!从节点复制执行psync,从节点从主节点获取数据!同步过程分为2种:
全量复制和局部复制
指令命令:PSYNC replication_ID offset
ID:每个Redis主节点在启动时都会生成一个唯一的运行ID。这个ID用于标识主节点当前的状态,包括复制进度和已经应用的命令数目。
offest: 表示从节点希望从主节点复制的数据的起始位置。对于部分同步,从节点会告诉主节点自己最后一次成功复制的位置(偏移量),主节点将从这个偏移量之后的数据发送给从节点。为-1 则是全量复制
全量复制(Full Sync Replication)
全量复制是Redis主从复制(Master-Slave Replication)的基本模式,主要流程包括:
-
初次同步: 当一个从节点连接到主节点时,如果是第一次复制,主节点会将自己的整个数据集发送给从节点。这个过程中,从节点会被阻塞,直到数据完全同步完成。发送psync ? -1
-
主节点回应:根据命令,解析,并且返回+FULLRESYNC响应
-
持续同步: 在初次同步后,从节点会继续监听主节点的命令流,通过接收主节点的写命令来更新自己的数据集,保持与主节点的数据一致性。
-
主节点执行 bgsave 进行 RDB 文件的持久化。
-
从节点发送 RDB 文件给从节点,从节点保存 RDB 数据到本地硬盘.
-
主节点将从生成 RDB 到接收完成期间执行的写命令,写入缓冲区中,等从节点保存完 RDB 文件后,主节点再致传入从节点。
-
从节点加载 RDB 文件得到与主节点一致的数据。
-
如果从节点加载 RDB 完成之后,并且开启了 AOF 持久化功能,它会进行 bgrewrite 操作,得到最近的 AOF 文件。
提问:RDB文件传输给子节点?能不能直接网络传输到从节点呢?
答:可以,但是虽然逐条命令传输可能在某些情况下更快,但这种方法会消耗更多的网络带宽和系统资源。如果主节点发生故障或者网络中断,从节点可以依赖其本地存储的RDB文件来进行恢复。这种方式可以提高系统的可用性和容错性。
局部复制(Partial Replication)
局部复制是一种在特定条件下可用的复制模式,主要特点包括:
-
选择性复制: 局部复制允许从节点只复制部分的主节点数据集。这可以通过配置来指定需要复制的特定键空间,而不是复制整个数据集。
-
应用场景: 局部复制适合于需要部分数据的读取操作,可以帮助减轻从节点的负载,专注于特定的数据集,提高性能和效率。
-
配置灵活性: Redis允许管理员在需要的时候配置和启用局部复制,这样可以根据实际业务需求来调整和优化数据复制的效率和成本。
额外补充
实时复制
全局复制用于第一次建立连接,部分复制用于因为网络抖动而暂时断开连接,而实时复制是从节点和主节点之间同步好数据,然后主节点时时刻刻收到新的数据,并且同步给从节点!
在当中,节点和主节点会建立TCP长连接,主节点把自己收到的数据修改请求发送给从节点,从而一致性!
如何保证一致性呢?保证连接一直都是可用状态
心跳包机制
主节点:默认每隔10s从节点发送一个ping命令,从节点收到返回pong
从节点:默认每隔1s给主节点发送一个特点的请求,就会上报当前从节点复制数据的进度
如果未收到响应,则就断了!
额外补充:从节点升级为主节点,通过哨兵方式!