Redis 集群同步技术实现与一致性高可用解决方案

Redis 集群同步技术主要通过主从复制机制实现，包括全量同步和增量同步两个阶段，利用 PSYNC 命令和复制偏移量确保数据一致。高可用性通过哨兵模式或 Cluster 集群模式解决，主节点故障时自动切换从节点。数据一致性方面，通常采用异步复制追求性能，接受最终一致性；强一致性场景可通过同步阻塞或消息队列重试机制保障，但需权衡可用性。生产环境多采用旁路缓存模式，写操作删缓存、读操作更新缓存，结合 Binlog 订阅确保最终一致性。

Redis 进阶知识全解析：高可用部署与数据一致性实战

一、Redis 高可用基础：主从复制 (Master-Replica Replication) Redis 单节点部署存在明显短板：一旦节点宕机，服务直接不可用;单节点处理能力有限，无法承载高并发读写。主从复制是 Redis 高可用的基础，核心是“一主多从”架构，主节点负责写操作，从节点负责读操作，实现读写分离、故障备份。1. 主从复制核心原理 主从复制的核心是“数据同步”,即从节点复制主节点的数据集，保持与主节点数据一致，整个过程分为三个阶段，且默认采用异步复制模式 (低延迟、高性能，适配绝大多数 Redis 用例): 初始化同步 (全量同步):当从节点首次连接主节点时，会发送 PSYNC 命令，请求全量同步。主节点会 fork 一个子进程，生成 RDB 快照文件，同时缓冲这段时间内的所有写命令;子进程将 RDB 文件发送给从节点，从节点接收后加载 RDB 文件，完成初始数据同步;最后主节点将缓冲的写命令发送给从节点，从节点执行这些命令，确保与主节点数据完全一致。增量同步：全量同步完成后，主节点会将后续所有写命令 (set、hset 等) 实时发送给从节点，从节点接收并执行命令，保持数据实时同步。主节点会维护一个复制偏移量，每发送一个字节的复制流，偏移量就递增;从节点也会维护自身的偏移量，用于向主节点确认已接收的数据量，实现精准增量同步。断连重连：若主从节点因网络问题断开连接，从节点会自动重新连接主节点。连接成功后，从节点会发送自身的复制 ID 和偏移量，主节点会判断是否能进行增量同步 (若主节点缓冲区有足够的积压数据);若无法增量同步，则触发全量同步，确保数据一致。

Redis 集群详解

此时虽然解决了单实例存在的三个问题，那么又会带来数据一致性问题。解决数据一致性问题：同步阻塞方式：假如说一个客户端做了一个写操作，到达主 Redis，那么 client 将阻塞，直到主 Redis 通知两个备 Redis 都成功写入才返回结果。这时候为强一致性，带来的问题是，假如说备用 Redis 这时候挂掉，没有写入成功，那么主 Redis 等待超时之后，就返回给客户端失败，相当于服务不可用，破坏了可用性。异步方式：弱一致性：容忍数据丢失一部分，当 client 发送一个写请求，Redis 立刻返回 OK，这时候通知备 Redis 去写，如果两个都写失败了，那么就会丢失数据。最终一致性：这种方式虽然数据最终会一致，但是在这期间如果有客户端去读数据，可能会造成脏读。

Redis 一致性、缓存策略与高可用设计 的综合性深度指南-CSDN 博客

第一部分：核心基础——为什么要使用 Redis? 在深入细节之前，我们需要明确 Redis 在架构中的定位。通常，我们使用 Redis 是基于“二八定律”:80% 的请求访问 20% 的热点数据。架构模型：客户端->Redis (内存)->MySQL (磁盘) 核心矛盾：性能:Redis 读写延时在微秒级别 (数万 QPS),MySQL 在毫秒级别 (数千 QPS)。数据:Redis 是易失性存储，MySQL 是持久化存储。没有完美的技术，只有合适的取舍。在高并发下，我们通常优先保证系统的可用性和性能，通过设计来追求数据的最终一致性，而非强一致性。第二部分：缓存与数据库的一致性 (终极方案) 这是面试和架构设计中的“珠穆朗玛峰”。我们首先要明确一个共识：对于绝大多数业务场景，由于网络延迟和并发问题，无法实现绝对的实时强一致性。我们的目标是尽最大可能缩短不一致的时间窗口，并保证最终一致性。1. 主流策略：旁路缓存模式 这是业界标准的策略，核心思想是：写操作删缓存，读操作更新缓存。读请求：先查 Redis，命中则返回;未命中则查 DB，写回 Redis，返回。写请求：先更新 DB，成功后删除 Redis 中的旧数据。为什么是删除缓存而不是更新缓存？这是一个高频面试题。浪费计算资源：如果一个缓存被更新 100 次，但只在期间被读 1 次，那么更新 100 次就是浪费 CPU。并发安全问题：并发更新时，先更新的线程可能被后更新的线程覆盖，导致数据错乱。

redis cluster 原理详解_redis cluster 原理

一、RedisCluster 1.1 数据如何读写 在单个的 redis 节点中，我们都知道 redis 把数据已 k-v 结构存储在内存中，使得 redis 对数据的读写非常之快。Redis Cluster 是去中心化的，它将所有数据分区存储。也就是说当多个 Redis 节点搭建成集群后，每个节点只负责自己应该管理的那部分数据，相互之间存储的数据是不同的。Redis Cluster 将全部的键空间划分为 16384 块，每一块空间称之为槽 (slot),又将这些槽及槽所对应的 k-v 划分给集群中的每个主节点负责。如下图：key -> slot 的算法选择上，Redis Cluster 选择的算法是 hash(key) mod 16383，即使用 CRC16 算法对 key 进行 hash，然后再对 16383 取模，结果便是对应的 slot。常见的数据分区方法：节点取余分区：对特定数据取 hash 值再对节点数取余来决定映射到哪一个节点。优点是简单，缺点是扩容或收缩时需重新计算映射结果，极端情况下会导致数据全量迁移。一致性哈希分区：给每个节点分配一个 0～2^32 的 token，使其构成一个环，数据命中规则为根据 key 的 hash 值，顺时针找到第一个 token 大于等于该 hash 的节点。优点是加减节点只影响相邻的节点，缺点是节点少的时候优点变缺点，反倒会影响环中大部分数据，同时加减节点时候会导致部分数据无法命中。虚拟槽分区：使用分散度良好的 hash 函数将数据映射到一个固定范围的整数集合，这些整数便是槽位，再分给具体的节点管理。Redis Cluster 使用的便是虚拟槽分区。

Redis 高可用 (cluster 集群):从单点故障到集群弹性扩展

一、高可用的概念 高可用是分布式的概念。假如 redis 只有一个节点，如果在工作当中 redis 突然宕机了，而服务器程序的业务逻辑又依赖于 redis 的数据，这时系统就是不可用的状态。为解决这个问题，就要求 redis 具备高可用。所谓高可用，就是一个 redis 的主节点宕机了，还有备用节点可以顶替它继续运行，服务器程序切换连接新的节点，从而保证系统的可用性。这里探究的是 redis 的高可用，所以高可用机制是由 redis 完成的。它主要完成以下工作:(1) 数据同步。数据复制过来，备用节点才是可用的。(2) 主从切换。提供一种机制，告诉服务器程序，主节点宕机了，备用节点变成主节点了。高可用要有一个程度，这个程度由主从切换的时间决定，通常是秒级别。二、redis 主从复制 主要用来实现 redis 数据的可靠性;防止主 redis 所在磁盘损坏 或 redis 宕机，造成数据永久丢失。主从复制是高可用的基础。redis 通常是一主二从的备份方式，而且是在不同的机器中，即异地备份。对于 redis 而言，是由备份节点连接主节点，而且由备份节点从主节点拉取数据。也就是，redis 是采用异步复制的方式，因为 redis 要提供高效的 key-value 存储。所说的数据同步主要是 rdb 的数据同步，也就是内存的二进制数据。

FAQ

Redis 主从复制是同步还是异步？

Redis 主从复制默认采用异步复制模式，主节点写入后立刻返回，随后将写命令发送给从节点，这种方式低延迟高性能，但存在数据丢失风险。

如何保证 Redis 集群数据一致性？

通常追求最终一致性，可通过消息队列重试删除缓存或订阅 Binlog 实现；强一致性可采用同步阻塞方式，但会牺牲可用性。

Redis Cluster 如何分片？

Redis Cluster 将键空间划分为 16384 个槽，使用 CRC16 算法对 key 进行 hash 后取模分配槽位，每个主节点负责一部分槽。