目录
为什么要有集群
概念
通过添加服务器的数量，提供相同的服务，从而让服务器达到一个稳定，高效的状态
三种模式
- 主从模式
- 哨兵模式
- 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数据库状态被修改后，导致主从服务器数据库状态不一致，此时需要让主从数据同步到一致的 状态
建立连接阶段
数据同步阶段
要想了解这一阶段，先了解这几个知识点：复制缓冲区
复制缓冲区
- 偏移量（offset），用来记录已发送的信息对应的偏移量,作为下次发送信息的坐标依据
- 字节值，存放的用户的操作命令
原理：
通过偏移量区分不同的slave当前数据传播的差异（每个slave可能接受到master的命令的数量还不一样）
总结
复制缓冲区存的是全量复制之后的用户的一些操作，因为rdb不是实时的，需要有一个地方存储在全量复制更新期间，用户的一些操作命令，全量复制之后，这些命令都会发到slave，但不是一次性全发过去，而是有一定的规则去发，分好几次发送，每次都会记录命令发到了哪个位置，下回发送就从这个地方发送
注意事项
- 如果master数据量巨大，数据同步阶段应避开流量高峰期，避免造成master阻塞，影响业务正常执行
- 复制缓冲区大小设定不合理，会导致数据溢出。如进行全量复制周期太长，进行部分复制时发现数据已经存在丢失的清空，必须进行第二次全量复制
- master单机内存占用主机内存的比例不应过大，建议使用50%-70%的内存，留下30%-50%的内存用于执行bgsave命令和创建复制缓冲区
命令传播阶段
要想了解这一阶段，先了解这几个知识点：复制缓冲区、服务器运行ID、心跳机制
服务器运行ID
心跳机制
- 指令：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-master节点一般用于接收读写，而redis-slave节点则一般只用于备份，其与对应的master拥有相同的slot集合，若某个redis-master意外失效，则再将其对应的slave进行升级为临时redis-master。
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/209492.html原文链接：https://javaforall.net
![重磅官宣：Nacos2.0性能提升10倍[通俗易懂]](https://javaforall.net/wp-content/uploads/2020/11/2020110817443450-480x300.jpg)
