秋招冲冲冲
Redis集群模式
Redis是一个高性能的开源键值对存储系统,广泛应用于缓存、消息队列等场景。为了应对大规模数据存储和高并发访问,Redis提供了多种集群模式来提升可用性和扩展性。本文将详细介绍Redis的三种集群模式:主从集群、哨兵集群和分片集群。
1. 主从集群模式
1.1 主从同步
主从集群模式是Redis最基础的集群形式。在此模式下,主节点(Master)可以执行读写操作,而从节点(Slave)只能执行读操作。主节点在写操作时会将数据同步给从节点。
1.1.1 全量同步(Full Resync)
全量同步是主从节点同步的初始阶段,过程如下:
-
建立连接和协商同步
从节点需要输入主节点的密码,执行replicaof 主节点IP 端口号命令以建立连接。主节点与从节点在同步时,主节点会发送psync ? -1,从节点会发送主节点ID和偏移量(offset),以确定同步进度。 -
进行全量同步
在第一次同步时,偏移量为0,主节点会执行bgsave命令生成dump.rdb文件,然后将其传输给从节点。从节点会清空内存,载入该dump.rdb文件。 -
主从同步数据
主节点执行bgsave生成dump.rdb,然后传输给从节点,从节点会清空当前内存并加载该文件。这一过程存在数据不一致的风险。为了弥补这一问题,主节点会将写操作命令写入到replication buffer缓冲区。 -
同步新的写操作
从节点加载完dump.rdb后,会向主节点发送确认信息,主节点会将replication buffer缓冲区中的写操作命令同步给从节点,此时数据一致。 -

1.1.2 长连接
主从节点建立的TCP长连接在完成全量同步后,会一直保持,进行命令同步。当某个节点发生宕机或网络不稳定时,连接可能会中断,恢复时不能直接依赖长连接进行同步。
1.1.3 增量同步
当从节点恢复网络后,它会向主节点发送 psync 主节点号 偏移量 请求,主节点根据偏移量判断是进行增量复制还是全量复制。如果从节点需要的数据仍在缓冲区,主节点会进行增量同步。否则,主节点会执行全量同步,从而避免数据丢失。
- 偏移量的来源
主节点在执行命令时,会将写命令写入repl_backlog_buffer(环形缓冲区)。主节点通过master_repl_offset标记写入位置,从节点通过slave_repl_offset标记读取位置。

1.1.4 主从从集群
为了避免主节点压力过大,可以为从节点再建立从节点,从节点会将数据同步给从从节点。这有助于分担主节点的压力,避免阻塞主线程。

1.2 主从复制中的两个缓冲区
- Replication Buffer:用于全量复制和增量复制阶段,主要用于主节点与从节点的命令同步。
- Repl Backlog Buffer:用于增量复制阶段。当缓冲区满时,主从节点会断开连接并重新进行全量复制。若
repl_backlog_buffer满了,主节点会覆盖并继续写入。

2. 哨兵集群模式
哨兵集群主要用于提高Redis集群的可用性,防止主节点故障时影响整个集群的运行。哨兵机制通过状态监控、故障恢复和状态通知来确保Redis集群的高可用性。
2.1 状态监控
哨兵集群通过向主从节点发送ping请求来监控Redis集群的状态。每秒钟,哨兵会发送ping请求,以判断节点是否正常响应。
- 主观下线:当某个哨兵发现节点没有正常响应时,会认为该节点主观下线。
- 客观下线:如果超过指定数量(
quorum)的哨兵认为某节点主观下线,则该节点被认为客观下线。
2.2 故障恢复
当主节点发生故障时,哨兵会选举出新的主节点,并通知Redis客户端。故障恢复的过程如下:
- 选举Leader:首先,选出一个Leader哨兵,Leader负责执行故障恢复。
- 选择新的主节点:Leader通过投票选举出一个从节点,切换为新的主节点。其他从节点会执行
slaveof 新主节点命令,开始同步数据。
2.2.1 选举Leader
Leader的选举遵循以下规则:
- 必须得到半数以上哨兵的赞成票。
- 得到的票数大于等于配置文件中的
quorum值。 - 通常,最早发起故障恢复的哨兵会当选。
2.2.2 选举新的主节点
选择新主节点时,考虑以下几个因素:
- 断开连接时间:若从节点与主节点断开连接时间过长,可能会被排除。
- 优先级(Priority):优先级越小的从节点越容易被选为主节点,0优先级除外。
- 偏移量(Offset):偏移量越大的从节点数据与主节点更一致,优先级越高。
- 运行ID(Run_ID):运行ID越小的从节点优先级越高。
3. 分片集群模式
分片集群用于解决Redis主从节点内存不足的问题,特别是在数据量大和高并发写操作的场景下。通过数据分片,将数据分布到多个Redis节点上,从而提升Redis的存储能力和性能。
3.1 分片的原理
Redis通过将 16384 个插槽分配到不同的实例来实现数据的分片。每个Redis节点负责一段连续的哈希槽,数据根据键的哈希值分配到相应的插槽。
- 分片依据:Redis使用CRC16算法根据键值计算哈希值,然后对16384取余,得到的余数即为插槽编号。
3.2 故障转移(故障恢复)
与哨兵集群类似,分片集群也会使用主观下线和客观下线机制来判断节点是否正常工作。若某个节点宕机,会通过投票选举新的主节点。

结语
点点赞和收藏谢谢家人们,一起冲刺秋招,会努力更新的!!!
1800

被折叠的 条评论
为什么被折叠?



