Redis集群方案之主从模式、哨兵模式、分片集群。

最新推荐文章于 2024-07-06 20:12:43 发布

代码忍者

最新推荐文章于 2024-07-06 20:12:43 发布

阅读量502

点赞数 4

分类专栏：笔记文章标签： redis java 数据库

本文链接：https://blog.csdn.net/m0_56615376/article/details/136910458

版权

笔记专栏收录该内容

20 篇文章 0 订阅

订阅专栏

Redis集群方案

Redis集群方案有主从模式、哨兵模式、分片集群。

主从模式：

单个Redis的并发能力是有上限的，为了提高并发能力，一般搭建主从集群，实现读写分离，把Redis分成一个主节点（master）和多个从节点（slave），一般的数据操作都是读操作较多，写操作较少，所以主节点负责写操作，从节点负责读操作。主节点执行完写操作后把数据同步到从节点。

主从全量同步流程以及可能出现的问题和解决方式：

全量同步：是指将主节点上的所有数据复制到从节点的过程。这有助于从节点在主节点发生故障时承担读写请求，以及提供数据备份和扩展读性能。

流程：

从节点（slave）执行replicaof命令，向主节点（master）请求数据同步，主节点判断是否是第一次同步，从节点会传输replid和offset。

replid：是数据集的表示，ID一致说明是同一个数据集，每一个master都有唯一的replid，slave则会继承master节点的replid。

offset：偏移量，随着记录在repl_baklog中的数据增多而逐渐增大，slave完成同步时也会记录当前的offset。如果slave的offset下雨master的offset，说明slave数据落后于master，需要更新。

如果replid不一致，说明从节点是第一次到主节点进行数据同步，主节点会将自己的数据版本信息返回给从节点。从节点保存版本信息。主节点执行bgsave，生成RDB文件，并发送给从节点。从节点清空本地数据，加载RDB文件。

如果这个时候主节点的数据又有修改。则会生成repl_baklog日志文件。会记录RDB期间的所有命令。然后发送repl_baklog中的命令给从节点，从节点执行接收到的命令。

如果replid一致，说明已经同步过数据，就不会再去生成RDB文件，而是直接通过repl_baklog去执行。

建立连接：从节点连接主节点，并发送命令请求进行全量同步。
主节点创建RDB文件：主节点开始执行 BGSAVE 命令创建 RDB 文件（快照文件），并在创建期间继续接受命令请求。
传输RDB文件：一旦 RDB 文件创建完毕，主节点会将该文件发送给从节点。
加载RDB文件：从节点接收到 RDB 文件后，会先保存当前内存中的数据，然后载入主节点发来的 RDB 文件。
增量复制：主节点会继续将接收到的更新命令缓存起来，传输给从节点，从节点接收并执行这些命令，实现增量复制。

可能遇到的问题以及解决方式：

网络问题：
- 问题：网络不稳定或者断线可能导致主从同步中断。
- 解决方式：监控网络状态，确保网络连接稳定。使用 Redis Sentinel 或者 Redis Cluster 进行故障转移，切换到其他可用节点。
主节点负载问题：
- 问题：主节点负载过高可能影响 RDB 文件的创建和传输。
- 解决方式：优化主节点的配置，合理分配资源。可以考虑在非生产环境进行主从同步操作，减轻生产环境的负载。
RDB 文件过大：
- 问题：RDB 文件过大可能导致传输时间过长，影响同步速度。
- 解决方式：可以通过设置合理的保存策略，避免生成过大的 RDB 文件。也可以考虑使用 AOF 持久化方式进行主从同步。
从节点初始化问题：
- 问题：从节点在初始化时需要保存当前内存中的数据，可能导致内存占用过高。
- 解决方式：合理规划从节点的内存大小，确保能够容纳主节点的数据。
版本兼容性问题：
- 问题：主从节点的 Redis 版本不兼容可能导致同步失败。
- 解决方式：确保主从节点使用相同或兼容的 Redis 版本，避免因版本不一致导致的同步问题。

主从增量同步流程以及可能出现的问题和解决方式：

增量同步：是指主节点将新的写操作以及数据变化发送给从节点的过程。在增量同步过程中，主节点会将自己的写操作实时地传输给从节点，以保持从节点的数据与主节点的数据一致。

流程：

主要发生在从节点重启后，从节点会发送请求，传递replid和offset。主节点判断replid是否一致。如果不是第一次，回复continue，这个时候主节点会从repl_baklog中获取offset之后的数据，主节点把获取之后的数据发送给从节点，从节点执行命令。

写操作记录：主节点将所有的写操作以及数据变化记录在内存中的命令缓冲区。
传输操作日志：定期或者基于一定条件，主节点将命令缓冲区中的写操作记录发送给从节点。
从节点执行操作：从节点接收到主节点发送的写操作记录后，依次执行这些写操作，从而保持数据的一致性。

可能遇到的问题以及解决方式：

网络问题：
- 问题：网络不稳定或者断线可能导致主从同步中断。
- 解决方式：监控网络状态，确保网络连接稳定。使用 Redis Sentinel 或者 Redis Cluster 进行故障转移，切换到其他可用节点。
命令丢失：
- 问题：在传输命令过程中可能出现部分命令丢失的情况。
- 解决方式：使用较新版本的 Redis，该版本有更加健壮的复制功能，可以更好地处理命令传输过程中的异常情况。
从节点复制延迟：
- 问题：从节点复制主节点的操作速度跟不上主节点写入的速度，导致从节点数据滞后。
- 解决方式：可以通过调整从节点的配置，增加带宽或者优化网络环境，以提高从节点的复制速度。
并发写冲突：
- 问题：主节点和从节点同时对同一数据进行写操作可能导致冲突。
- 解决方式：在应用层面处理并发写冲突，或者使用 Redis 的乐观锁机制来避免并发写冲突。
版本兼容性问题：
- 问题：主从节点的 Redis 版本不兼容可能导致同步失败。
- 解决方式：确保主从节点使用相同或兼容的 Redis 版本，避免因版本不一致导致的同步问题。

哨兵模式：

实现主从集群下的自动故障恢复，保证高可用。

哨兵的作用：

**监控：**哨兵会不断检查主节点（master）和从节点（slave）是否按照预期工作。

**自动故障修复：**当主节点出现问题，会在从节点中选出一个作为新的主节点，老的主节点恢复后也以新的主节点为主。

**通知：**当集群发生故障转移时，会将最新信息推送给Redis客户端。

服务状态监控：基于心跳机制监控服务状态，每秒会向集群中的每个实例发送ping命令。

主观下线：如果哨兵节点发现集群中的某个实例没有在规定内相应，则认为这个实例主观下线。

客观下线：如果超过一定数量的哨兵都认为实例主管下线，则实例客观下线。

哨兵模式的选主规则：

1、可以通过从节点与主节点断开时间选取。

2、可以通过offset的值进行选取主节点，offset值越大说明从节点的数据越完整。

哨兵模式脑裂：

因为网络问题，哨兵和主节点与从节点不在一个网络分区下，哨兵监测不到主节点，会认为主节点客观下线，这时候就会在从节点中重新选取一个主节点，但是之前的主节点并没有挂掉，这个时候就会出现两个主节点，当网络回复后，老的主节点会降级，成为新主节点的从节点。老的主节点会删除数据重新去新的主节点上同步新主节点的数据。但是因为之前老的主节点并没挂掉，还是可以写入数据，恢复后变成从节点后，会导致之前写入的数据丢失。这就是脑裂问题出现之后导致数据丢失问题。

**解决脑裂的方法：**修改Redis的参数配置

min-replicas-to-write 1 表示最少的有一个从节点。

min-replicas -max -lag 5 表示数据复制和同步的延迟不超过5秒。