Redis集群三种方式

最新推荐文章于 2025-04-10 13:41:52 发布

Notail^0^

最新推荐文章于 2025-04-10 13:41:52 发布

阅读量1w

点赞数 14

分类专栏： Redis 文章标签： redis Redis集群

此文章来自李晨璐专栏，转载请声明

本文链接：https://blog.youkuaiyun.com/lclcsdnblink/article/details/107107619

版权

Redis 专栏收录该内容

9 篇文章

订阅专栏

为什么要有集群

单个Redis存在不稳定性，当Redis服务宕机或硬盘故障，系统崩溃之后，就没有可用的服务了，还会造成数据的丢失
单个Redis的读写能力也是有限的
还由于互联网的三高架构，高并发，高性能，高可用

概念

通过添加服务器的数量，提供相同的服务，从而让服务器达到一个稳定，高效的状态

三种模式

主从模式
哨兵模式
Cluster模式

主从模式

在这里插入图片描述

为什么要用主从复制

单机redis的风险与问题

问题一：机器故障

硬盘故障，系统崩溃
本质：数据丢失，可能对业务造成灾难性打击

问题二：容量瓶颈

内存不足，一台redis内存是有限的

解决方案：

为了避免单点Redis服务器故障，准备多台服务器，互相联通，将数据复制多个副本保存在不同服务器上，连接在一起，并保证数据是同步的，即使有其中一台服务器宕机，其他服务器依然可以继续提供服务，实现Redis的高可用，同时实现数据冗余备份

特征

一个master可以拥有多个slave，一个slave只对应一个master
主从复制即将master中的数据及时，有效的复制到slave中

职责

master

写数据
执行写操作时，将出现变化的数据自动同步到slave
slave：
读数据，禁止写数据

作用

读写分离：master写，slave度，提高服务器的读写负载能力
负载均衡：基于主从结构，配合读写分离，由slave分担master负载，并根据需求的变化，改变slave的数据，通过多个结点分担数据读取负载，大大提高Redis服务器并发量与数据吞吐量
故障恢复：当master出现问题时，由slave提供服务，实现快速的故障恢复
数据冗余：实现数据热备份，是持久化之外的一种数据冗余方式
高可用基石：基于主从复制，构建哨兵模式与集群，实现Redis的高可用方案

工作流程

分三个阶段

建立连接阶段-建立slave到master的连接，使master能够识别slave，并保存slave端口号
数据同步阶段-在slave初次连接master后，复制master中的所有数据到slave
命令传播阶段-当master数据库状态被修改后，导致主从服务器数据库状态不一致，此时需要让主从数据同步到一致的状态

建立连接阶段

在这里插入图片描述

数据同步阶段

要想了解这一阶段，先了解这几个知识点：复制缓冲区

复制缓冲区

复制缓冲区，又名复制积压缓冲区，是一个先进先出的队列，用于存储服务器执行过的命令，每次传播命令，master都会将传播的命令记录下来，并存储在复制缓冲区
工作原理
组成：

偏移量（offset），用来记录已发送的信息对应的偏移量,作为下次发送信息的坐标依据
字节值，存放的用户的操作命令
原理：
通过偏移量区分不同的slave当前数据传播的差异（每个slave可能接受到master的命令的数量还不一样）
总结
复制缓冲区存的是全量复制之后的用户的一些操作，因为rdb不是实时的，需要有一个地方存储在全量复制更新期间，用户的一些操作命令，全量复制之后，这些命令都会发到slave，但不是一次性全发过去，而是有一定的规则去发，分好几次发送，每次都会记录命令发到了哪个位置，下回发送就从这个地方发送

在这里插入图片描述

注意事项

如果master数据量巨大，数据同步阶段应避开流量高峰期，避免造成master阻塞，影响业务正常执行
复制缓冲区大小设定不合理，会导致数据溢出。如进行全量复制周期太长，进行部分复制时发现数据已经存在丢失的清空，必须进行第二次全量复制
master单机内存占用主机内存的比例不应过大，建议使用50%-70%的内存，留下30%-50%的内存用于执行bgsave命令和创建复制缓冲区

命令传播阶段

要想了解这一阶段，先了解这几个知识点：复制缓冲区、服务器运行ID、心跳机制

服务器运行ID

服务器运行ID是每一台服务器每次运行的身份识别码，一台服务器多次运行可以生成多个运行id
组成：运行id由40位字符组成，是一个随机的十六进制字符例如：fdc9ff13b9bbaab28db42b3d50f852bb5e3fcdce
作用：运行id被用于在服务器间进行传输，识别身份如果想两次操作均对同一台服务器进行，必须每次操作携带对应的运行id，用于对方识别
实现方式：运行id在每台服务器启动时自动生成的，master在首次连接slave时，会将自己的运行ID发送给slave，slave保存此ID，通过info Server命令，可以查看节点的runid

心跳机制

进入命令传播阶段候，master与slave间需要进行信息交换，使用心跳机制进行维护，实现双方连接保持在
master心跳：

指令：PING
周期：由repl-ping-slave-period决定，默认10秒
作用：判断slave是否在线
查询：INFO replication 获取slave最后一次连接时间间隔，lag项维持在0或1视为正常
slave心跳任务
指令：REPLCONF ACK {offset}
周期：1秒
作用1：汇报slave自己的复制偏移量，获取最新的数据变更指令
作用2：判断master是否在线

在这里插入图片描述

常见问题

master数据巨大的时候，一旦master重启，runid将会发生变化，会导致全部的slave的全量复制操作
复制缓冲区过小，断网后slave的offset越界，触发全量复制

总结

主数据库可以进行读写操作，当读写操作导致数据变化时会自动将数据同步给从数据库
从数据库一般都是只读的，并且接收主数据库同步过来的数据
一个master可以拥有多个slave，但是一个slave只能对应一个master
slave挂了不影响其他slave的读和master的读和写，重新启动后会将数据从master同步过来
master挂了以后，不影响slave的读，但redis不再提供写服务，master重启后redis将重新对外提供写服务
master挂了以后，不会在slave节点中重新选一个master，只能手动的一个一个改，不合适，就有了之后的哨兵

哨兵模式

在这里插入图片描述

哨兵（sentinel）是一个分布式系统，用于对主从结构中的每台服务器进行监控，当出现故障时通过投票机制选择新的master并将所有slave连接到新的master

为什么有哨兵

主机宕机，如何能够高可用的恢复正常，不用人为进行干预

作用

监控
- 不断地检查master和slave是否正常运行
- master存活检测，master与slave运行清空检测
通知（提醒）
- 当被监控地服务器出现问题时，向其他（哨兵、客户端）发送通知
自动故障转移
- 断开master与slave连接，选取一个slave作为master，将其他slave连接到新地master，并告知客户端新地服务器地址

注意：

哨兵也是一台redis服务器，只是不提供数据服务
通常哨兵配置数量为单数

工作原理博客

Cluster

redis最开始使用主从模式做集群，若master宕机需要手动配置slave转为master；后来为了高可用提出来哨兵模式，该模式下有一个哨兵监视master和slave，若master宕机可自动将slave转为master，但它也有一个问题，就是不能动态扩充，哨兵模式还是只有一个master；所以在3.x提出cluster集群模式。

在这里插入图片描述

redis cluster在设计的时候，就考虑到了去中心化，去中间件，也就是说，集群中的每个节点都是平等的关系，都是对等的，每个节点都保存各自的数据和整个集群的状态。每个节点都和其他所有节点连接，而且这些连接保持活跃，这样就保证了我们只需要连接集群中的任意一个节点，就可以获取到其他节点的数据。
那么redis 是如何合理分配这些节点和数据的呢？
Redis 集群没有并使用传统的一致性哈希来分配数据，而是采用另外一种叫做哈希槽 (hash slot)的方式来分配的。redis cluster 默认分配了 16384 个slot，当我们set一个key 时，会用CRC16算法来取模得到所属的slot，然后将这个key 分到哈希槽区间的节点上，具体算法就是：CRC16(key) % 16384。