Redis 同步机制全面解析

一、redis 同步机制的核心与价值

1.1 核心需求：数据备份与读写分离

数据备份

在实际生产环境中，单机redis实例存在多种风险：

• 服务器硬件故障导致数据永久丢失
• 操作系统崩溃导致内存数据未持久化
• 误操作删除关键数据

通过同步机制建立主从架构，可以实现：

1. 多副本存储：数据至少存在于2个节点（1主1从），典型配置为1主2从
2. 容灾恢复：当主节点故障时，可快速提升从节点为新主节点
3. 数据持久化保障：结合rdb和aof持久化策略，即使主节点完全损坏，从节点也能提供完整的数据恢复点

示例场景：电商平台商品库存数据，通过同步机制确保即使主节点宕机，从节点也能继续提供服务，避免超卖。

读写分离

redis的主从架构天然支持读写分离：

• 主节点(master)：处理所有写入操作（set, incr等）和部分关键读请求
• 从节点(slave)：处理90%以上的读请求（get, hget等），支持配置多个从节点实现水平扩展

优势体现：

• 提升系统整体吞吐量：读性能随从节点数量线性增长
• 降低主节点负载：将cpu密集型操作（如复杂lua脚本）分流到从节点
• 实现地域就近访问：在不同机房部署从节点，减少网络延迟

典型应用：

• 社交平台：主节点处理发帖/点赞等写操作，从节点处理信息流展示
• 内容管理系统：主节点处理内容更新，从节点处理内容查询

1.2 关键目标：高效、可靠、低延迟

高效性实现

redis采用智能复制策略平衡效率：

• 全量复制：
  • 初次连接时执行
  • 通过rdb快照完成
  • 优化措施：支持无盘复制（diskless replication）
• 增量复制：
  • 基于复制积压缓冲区（repl-backlog-buffer）
  • 默认大小1mb，可根据网络质量调整
  • 仅传输变更命令，大幅减少带宽占用

配置建议：

repl-backlog-size 16mb  # 提升缓冲区大小应对网络不稳定
repl-diskless-sync yes  # 启用无盘复制加速全量同步

可靠性保障

redis通过多种机制确保同步可靠性：

• 断点续传：基于复制偏移量（replication offset）记录同步进度
• 心跳检测：主从定期（默认10秒）ping-pong通信
• 自动重连：网络恢复后自动重新建立同步连接
• 数据校验：使用crc64校验和验证数据一致性

低延迟优化

为实现毫秒级同步延迟，redis采用：

1. tcp长连接：避免频繁建立连接的开销
2. 异步复制：主节点不等待从节点ack继续处理请求
3. 延迟监控：

   info replication  # 查看master_repl_offset和slave_repl_offset差值

4. 硬件优化：
   • 主从节点部署在同一可用区减少网络延迟
   • 使用高性能网卡（如10gbps）

性能指标：

• 同机房延迟：通常<1ms
• 跨机房延迟：取决于网络质量，通常<10ms
• 极端情况下可配置wait命令实现同步写（牺牲性能换取更强一致性）

二、基础同步：主从复制（master-slave replication）

主从复制是 redis 同步机制的基石，所有高级同步（哨兵、集群）均基于此扩展。其核心逻辑是通过主节点(master)和从节点(slave)的协作，实现数据的分布式存储和读写分离。从节点主动连接主节点，复制主节点的数据集，并实时同步主节点的写操作。这种架构设计不仅提高了系统的可用性，还能有效分担主节点的读请求压力。

2.1 主从复制的三个核心阶段

主从复制全流程分为"建立连接"、"数据同步"、"命令传播"三个阶段，缺一不可。这三个阶段构成了一个完整的数据同步生命周期，确保主从节点之间的数据最终一致性。

阶段 1：建立连接（握手阶段）

从节点通过配置slaveof <master-ip> <master-port>（redis 5.0 后推荐使用更符合现代语义的replicaof）触发连接流程，具体步骤如下：

• 初始化连接：
  • 从节点启动后，向主节点发送sync命令（redis 2.8 前）或更先进的psync命令（redis 2.8 后，支持增量复制）
  • 主节点收到命令后，首先验证从节点的requirepass（若配置）与自身masterauth是否一致
  • 验证通过后，主节点返回+ok响应
• 建立通信通道：
  • 主节点创建一个专门的"复制客户端"（用于向从节点发送数据）
  • 从节点创建"复制监听器"（用于接收主节点发送的数据）
  • 双方完成tcp连接初始化，为后续数据传输做好准备
• 连接确认：
  • 从节点会定期发送ping命令检测连接状态
  • 主节点响应pong确认连接正常

阶段 2：数据同步（全量 / 增量复制）

这是同步的核心阶段，分为两种模式：全量复制（首次同步或从节点断线过久）和增量复制（从节点短期断线后恢复）。选择哪种模式取决于从节点的同步状态和断开时间。

2.2.1 全量复制：从 0 到 1 复制完整数据集

当遇到以下情况时会触发全量复制：

• 从节点是全新节点，从未同步过数据
• 从节点的replid（主节点标识）与主节点不一致
• 从节点的复制偏移量offset不在主节点的复制积压缓冲区范围内

全量复制详细流程：

• 发起请求：
  • 从节点发送psync ? -1命令（表示请求全量复制）
• 主节点准备rdb：
  • 主节点接收到请求后，执行bgsave命令在后台生成rdb快照文件
  • 在生成rdb期间，主节点会缓存所有写操作（如set、hset）到"复制积压缓冲区"
• 传输rdb文件：
  • rdb生成完成后，主节点通过专用连接将rdb文件分块传输给从节点
  • 传输过程中使用tcp滑动窗口机制优化网络传输效率
• 从节点加载数据：
  • 从节点收到rdb文件后，首先安全地清空自身数据集
  • 然后将rdb文件加载到内存中，重建数据库
• 同步缓冲命令：
  • 主节点发送完rdb后，将"复制积压缓冲区"中的写操作按顺序发送给从节点
  • 从节点执行这些命令，确保与主节点数据完全一致

性能考量：

• rdb生成过程会fork子进程，可能导致短暂延迟
• 网络传输大数据量可能成为瓶颈
• 从节点加载rdb时会出现服务暂停
• 建议在业务低峰期执行全量复制，并确保网络带宽充足

2.2.2 增量复制：仅同步断线期间的增量数据

当从节点短期断线（如网络闪断）后重新连接，且主节点的"复制积压缓冲区"仍保留断线期间的写操作时，触发增量复制。这种模式显著提高了同步效率。

增量复制详细流程：

• 重新连接：
  • 从节点重新连接主节点时，发送psync <replid> <offset>命令
  • replid是主节点标识，offset是从节点最后一次同步的位置
• 主节点验证：
  • 主节点验证replid是否与自身一致
  • 检查offset是否在"复制积压缓冲区"的有效范围内（缓冲区保留[master_offset - backlog_size, master_offset]的操作）
• 执行增量同步：
  • 验证通过后，主节点仅将offset之后的写操作从缓冲区发送给从节点
  • 从节点执行这些增量命令，快速追上主节点数据状态

增量复制的关键条件：

1. 从节点需正确记录上一次同步的replid和offset（存储在replica.conf中）
2. 主节点的"复制积压缓冲区"需足够大，能够容纳断线期间的写操作
3. 断线时间未超过repl-backlog-ttl（默认3600秒），避免缓冲区被清空

优化建议：

• 对于写操作频繁的场景，适当增大repl-backlog-size
• 监控从节点的复制延迟，及时发现潜在问题
• 定期检查复制积压缓冲区的使用情况

阶段 3：命令传播（实时同步写操作）

数据同步完成后，主从进入"命令传播"阶段，这是维持数据一致性的关键环节。主节点每执行一次写命令，都会将该命令发送给所有从节点，从节点执行相同命令，确保数据实时同步。

命令传播的详细机制：

• 写命令传播流程：
  • 客户端向主节点发送写命令（如set key value）
  • 主节点执行命令并修改本地数据
  • 主节点将命令封装为redis协议格式，发送给所有从节点
  • 从节点接收并执行相同命令
• 性能优化策略：
  • 主节点采用"异步发送"模式：写命令执行后立即返回客户端，随后异步将命令发送给从节点
  • 从节点通过repl-disable-tcp-nodelay配置控制tcp特性：
  • 默认no（关闭tcp_nodelay）：tcp会缓冲小数据包，减少网络请求数，但可能增加毫秒级延迟
  • 设为yes（开启tcp_nodelay）：写命令立即发送，延迟降低，但网络请求数增加
• 复制偏移量监控：
  • 主从节点都会维护复制偏移量offset
  • 通过info replication可以查看主从节点的master_repl_offset和slave_repl_offset
  • 两者的差值反映了复制延迟

2.2 主从复制的核心配置

主节点配置

从节点配置

配置验证方法

• 主节点检查：

• redis-cli -a yourpassword info replication

• 查看connected_slaves是否为预期的从节点数量，以及每个从节点的状态信息。
• 从节点检查：

• redis-cli -a yourpassword info replication

• 确认master_host和master_port是否正确，master_link_status是否为up（表示连接正常）。
• 复制延迟监控： 比较主节点的master_repl_offset和从节点的slave_repl_offset，两者的差值即为复制延迟。

常见问题处理

• 连接失败：
  • 检查防火墙设置
  • 验证密码配置是否正确
  • 确认主节点bind配置允许远程连接
• 同步中断：
  • 检查网络连接状态
  • 查看日志文件定位问题
  • 适当增大repl-timeout（默认60秒）
• 性能优化：
  • 对于大型数据集，考虑在低峰期执行全量同步
  • 适当调整repl-backlog-size避免频繁全量同步
  • 监控复制延迟，及时发现性能瓶颈

三、高可用同步：哨兵模式（sentinel）

3.1 哨兵模式的核心角色与架构

哨兵模式是一个分布式系统，由以下三部分组成：

• 哨兵节点（sentinel）：
  • 独立的redis进程，不存储业务数据
  • 主要职责：
  • 持续监控主从节点健康状态
  • 检测到主节点故障时自动触发故障转移
  • 通知客户端主从拓扑变更
  • 充当服务发现的配置中心
• 主节点（master）：
  • 与普通redis主节点功能相同
  • 需要响应哨兵的监控请求
  • 向哨兵报告其从节点列表
• 从节点（slave）：
  • 与普通redis从节点功能相同
  • 自动被哨兵发现并监控
  • 在故障转移时可能被提升为新主节点

架构设计要点：

• 哨兵节点数量必须≥3且为奇数（推荐3或5个）
  • 原因：避免脑裂，确保故障转移需要"多数哨兵同意"的机制能正常工作
  • 示例：3个哨兵时，至少需要2个哨兵达成共识才能执行故障转移
• 主从节点数量可根据业务需求灵活配置
  • 典型配置：1主2从+3哨兵（适合中小规模应用）
  • 大型系统可能采用：1主5从+5哨兵

3.2 哨兵模式的同步逻辑（故障转移流程）

步骤1：监控（sentinel monitoring）

哨兵节点通过以下机制实现全面监控：

• 初始配置：

• sentinel monitor mymaster 192.168.1.1 6379 2

  • mymaster：主节点别名
  • 192.168.1.1:6379：主节点地址
  • 2：判定客观下线需要的哨兵票数
• 健康检查机制：
  • 每1秒发送ping命令到所有被监控节点
  • 正常响应：返回pong
  • 每10秒发送info replication到主节点
  • 获取从节点列表及其复制状态
  • 自动发现新增的从节点
• 哨兵集群通信：
  • 使用redis的pub/sub功能
  • 每2秒通过__sentinel__:hello频道广播节点状态
  • 维护哨兵之间的共识状态

步骤2：主观下线与客观下线

• 主观下线（sdown）：
  • 触发条件：单个哨兵在down-after-milliseconds（默认30秒）内未收到主节点的有效响应
  • 处理动作：该哨兵将主节点标记为"主观下线"
• 客观下线（odown）：
• 触发流程：
  • 发起投票：哨兵发送sentinel is-master-down-by-addr命令询问其他哨兵
  • 收集响应：等待其他哨兵回复（包含它们对主节点状态的判断）
  • 达成共识：当≥quorum个哨兵同意主节点不可用时，标记为"客观下线"
  • 示例：配置quorum=2时，需要至少2个哨兵确认主节点故障

步骤3：选举新主节点

选举过程采用多级排序策略：

• 第一优先级：replica-priority
  • 配置项：replica-priority（默认100）
  • 规则：数值越小优先级越高
  • 应用场景：可以手动指定某些从节点优先被选为主节点
• 第二优先级：复制偏移量（offset）
  • 比较各从节点与主节点的数据同步进度
  • 选择复制进度最接近原主节点的从节点
  • 确保数据丢失最少
• 第三优先级：runid
  • redis实例启动时生成的唯一标识
  • 按字典序选择runid较小的节点
  • 作为最终裁决条件

步骤4：故障转移执行

完整的故障转移流程：

• 提升新主：

• slaveof no one
  

  • 取消新主节点的从属关系
  • 使其开始接受写请求
• 重配置从节点：

• replicaof <new-master-ip> <new-master-port>
  

• 所有从节点开始同步新主节点的数据
• 采用增量复制或全量复制（取决于复制偏移量）
• 旧主节点处理：
  • 当旧主节点恢复后，自动被配置为新主节点的从节点
  • 通过info replication命令可以验证复制关系
• 客户端通知：
  • 哨兵通过+switch-master事件通知客户端
  • 客户端应实现自动重连机制

3.3 哨兵模式的核心配置（实战）

关键配置详解

配置示例

# sentinel.conf
port 26379
sentinel monitor mycluster 10.0.0.1 6379 2
sentinel down-after-milliseconds mycluster 50000
sentinel failover-timeout mycluster 120000
sentinel auth-pass mycluster mysecurepassword
sentinel parallel-syncs mycluster 2

运维检查清单

1. 启动哨兵：

   redis-sentinel /etc/redis/sentinel.conf

2. 监控命令：

   redis-cli -p 26379 sentinel masters  # 查看所有监控的主节点
   redis-cli -p 26379 sentinel slaves mymaster  # 查看指定主节点的从节点

3. 故障模拟测试：

   # 模拟主节点宕机
   redis-cli -p 6379 debug sleep 60
   # 观察哨兵日志
   tail -f /var/log/redis/sentinel.log

4. 客户端配置：

   • 应配置连接所有哨兵节点地址
   • 实现自动故障转移处理逻辑
   • 示例java客户端配置：

     jedissentinelpool pool = new jedissentinelpool("mymaster",
         new hashset<string>(arrays.aslist(
             "sentinel1:26379",
             "sentinel2:26379",
             "sentinel3:26379")));

四、分布式同步：redis cluster（集群模式）

4.1 集群模式的核心概念

分片机制详解

redis cluster 使用 crc16 算法计算 key 的哈希值，然后对 16384 取模得到对应的哈希槽。例如：

• key "user:1001" 的 crc16 值为 12345，则哈希槽为 12345 % 16384 = 12345
• key "product:2002" 的 crc16 值为 54321，则哈希槽为 54321 % 16384 = 54321

哈希槽分配示例：

• 3 节点集群：节点1(0-5460)、节点2(5461-10922)、节点3(10923-16383)
• 5 节点集群：每个节点约 3276 个槽

主从复制架构

每个主节点可以配置多个从节点，形成多副本保护。从节点会：

• 实时同步主节点数据
• 在主节点故障时参与选举
• 可配置为可读副本分担读压力

客户端重定向机制

当客户端访问错误节点时，会收到两种重定向响应：

1. moved：永久重定向，表示槽已迁移到指定节点
2. ask：临时重定向，发生在集群扩容/缩容期间

4.2 集群模式的同步逻辑

4.2.1 分片内同步优化

• 集群感知复制：
  • 从节点加入时通过 cluster meet 发现拓扑
  • 只同步所属分片的槽数据
  • 定期交换集群状态信息
• 读写分离配置：

• # 允许从节点处理读请求
  cluster-replica-ok yes

  • 启用后，从节点可以：
  • 响应本地持有的槽的读请求
  • 其他槽请求仍返回 moved

4.2.2 故障转移流程详解

• 故障检测阶段：
  • 从节点每秒发送 ping
  • 超时后标记主节点为 pfail (possible failure)
  • 收集其他节点的确认信息
• 选举投票规则：
  • 每个主节点有且只有一票
  • 从节点按以下条件竞选：
  • 复制偏移量最新
  • 节点运行时间最长
  • 节点id字典序最小
• 数据同步阶段：
  • 新主节点生成新的复制id
  • 其他从节点执行部分重同步(psync)
  • 故障期间写入使用故障转移标记

4.3 集群模式的核心配置与实战

配置参数详解

集群搭建完整流程

准备阶段：

# 创建6个实例配置
for port in {6379..6384}; do
  mkdir -p /redis/${port}
  cp redis.conf /redis/${port}/
  sed -i "s/port 6379/port ${port}/" /redis/${port}/redis.conf
done

启动节点：

# 启动所有节点
for port in {6379..6384}; do
  redis-server /redis/${port}/redis.conf
done

创建集群：

redis-cli --cluster create \
  127.0.0.1:6379 127.0.0.1:6380 127.0.0.1:6381 \
  127.0.0.1:6382 127.0.0.1:6383 127.0.0.1:6384 \
  --cluster-replicas 1 \
  --cluster-yes

验证集群：

# 检查集群状态
redis-cli -p 6379 cluster nodes | grep master
# 测试数据分布
redis-cli -c -p 6379 set foo bar

生产环境建议

• 节点规划：
  • 至少3个物理机部署
  • 每个物理机部署主从节点对
  • 预留30%内存用于故障转移
• 监控指标：
  • 槽分布均衡性
  • 节点间延迟
  • 故障转移次数
  • 集群状态变化
• 运维操作：
  • 使用 redis-cli --cluster reshard 进行槽迁移
  • 定期执行 cluster replicate 调整拓扑
  • 备份时使用 cluster saveconfig

五、redis 同步机制的常见问题与优化方案

5.1 问题1：全量复制频繁触发

现象表现

从节点频繁断开与重连，每次重连都触发全量复制(rdb文件传输)，导致主节点cpu和网络带宽占用过高，影响正常业务请求处理。监控中可观察到主节点cpu使用率周期性飙升，网络出口流量激增。

原因分析

1. 复制缓冲区过期：从节点断线时间超过repl-backlog-ttl(默认3600秒)后，复制积压缓冲区被清空，无法支持增量复制
2. 缓冲区容量不足：复制积压缓冲区(repl-backlog-size)设置过小(默认16mb)，断线期间的写操作超出缓冲区容量
3. 主节点标识变更：主节点runid因重启等原因变更，导致从节点保存的replid与主节点不一致
4. 网络环境不稳定：网络抖动或带宽不足导致连接频繁中断

优化方案

• 调整缓冲区参数：
  • 将repl-backlog-size从16mb调整为64-128mb(根据业务写入量计算：缓冲区大小=平均写入速率×最大预期断线时间)
  • 将repl-backlog-ttl从3600秒延长至86400秒(1天)
• 保障主节点稳定性：
  • 主节点配置appendonly yes，开启aof持久化
  • 使用config set命令动态调整参数，避免重启
  • 部署主节点高可用方案(如哨兵)
• 网络优化：
  • 主从节点部署在同一机房或可用区
  • 使用专线连接跨机房节点
  • 避免在网络拥堵时段进行部署或维护
• 监控与告警：
  • 监控info replication中的connected_slaves和master_repl_offset
  • 设置全量复制次数阈值告警

5.2 问题2：从节点同步延迟高

现象表现

从节点数据与主节点差距较大，通过info replication查看master_repl_offset与slave_repl_offset差值持续增大，从节点读取到旧数据。在电商秒杀等高并发场景下，可能导致库存超卖等问题。

原因分析

1. 主节点写入压力大：qps过高导致命令传播不及时
2. tcp缓冲延迟：repl-disable-tcp-nodelay设为no(默认)时，tcp会缓冲数据导致延迟
3. 从节点性能瓶颈：
   • cpu资源不足，无法及时处理命令
   • 内存不足，频繁触发swap
   • 磁盘io性能差(rdb加载慢)
4. 从节点数量过多：单个主节点挂载过多从节点(>5个)

优化方案

• 网络传输优化：
  • 从节点配置repl-disable-tcp-nodelay yes
  • 调整tcp内核参数(net.ipv4.tcp_slow_start_after_idle=0)
• 架构优化：
  • 使用redis cluster分散写入压力
  • 实现读写分离，将读请求分散到多个从节点
  • 限制单个主节点的从节点数量(建议≤5)
• 硬件升级：
  • 为从节点配置多核cpu(≥8核)
  • 使用ssd替代hdd
  • 增加内存容量，避免swap
• 监控措施：
  • 实时监控slave_repl_offset差值
  • 设置延迟阈值告警(如>100mb)

5.3 问题3：主从数据不一致

现象表现

主节点执行写命令后，部分从节点未同步该命令，导致主从数据差异。通过redis-cli的diff命令可以检测到不一致的键值，在金融交易等场景可能导致严重问题。

原因分析

1. 异步复制特性：redis默认采用异步复制，主节点宕机可能导致数据丢失
2. 从节点误写入：replica-read-only配置为no(默认yes)时，从节点可能被误写入
3. 网络分区：部分从节点长时间无法连接主节点
4. 命令传播失败：主节点在命令传播过程中崩溃

优化方案

• 一致性配置：

min-replicas-to-write 2
min-replicas-max-lag 10

• 表示至少2个从节点延迟不超过10秒才允许写入
• 从节点保护：
  • 强制所有从节点配置replica-read-only yes
  • 定期检查从节点配置
• 高可用部署：
  • 部署redis sentinel自动故障转移
  • 使用redis cluster分区容错
  • 跨机房部署时考虑网络分区场景
• 数据校验机制：

# 集群模式检查
redis-cli --cluster check <host>:<port>

# 主从数据对比
redis-cli -h master --scan | while read key; do
  diff=$(redis-cli -h master get "$key" | diff - <(redis-cli -h slave get "$key"))
  [ -n "$diff" ] && echo "$key: $diff"
done

• 定期修复：
  • 设置定时任务校验数据一致性
  • 发现不一致时触发从节点resync

5.4 问题4：集群模式哈希槽迁移导致同步中断

现象表现

在redis cluster扩容/缩容时，执行cluster setslot migrating/importing命令迁移哈希槽过程中，部分从节点同步中断，客户端请求返回moved/ask重定向错误。

原因分析

1. 数据变更频繁：迁移过程中大量键被修改，增量复制压力大
2. 网络波动：迁移期间网络不稳定导致连接中断
3. 资源竞争：迁移过程占用大量cpu和网络资源
4. 配置不一致：迁移后集群拓扑信息未及时同步

优化方案

• 迁移时机选择：
  • 选择业务低峰期(如凌晨2-4点)执行迁移
  • 监控qps和系统负载，在负载较低时操作
• 参数调优：
  • 迁移前调大repl-backlog-size(如调整为256mb)
  • 设置cluster-node-timeout(默认15秒)为更合理的值
• 迁移过程控制：

# 分批迁移键空间
redis-cli --cluster rebalance \
  --cluster-weight node1=1 node2=0 \
  --cluster-use-empty-masters

• 监控与恢复：
  • 使用cluster slots实时监控迁移进度
  • 迁移完成后检查所有节点cluster_state状态
  • 对同步中断的从节点执行cluster failover强制重新同步
• 客户端处理：
  • 客户端实现ask/moved重试逻辑
  • 使用redis集群代理屏蔽复杂度

六、redis 同步机制的选型建议

1. 主从复制（replication）

适用场景：

• 单机扩展、读写分离
• 数据备份容灾
• 测试/开发环境

推荐方案： 主从复制 + 读写分离（1主多从）

优势：

• 配置简单（通过replicaof命令即可完成）
• 性能开销低（异步复制）
• 从节点可分担读请求（如qps 10万+的场景）

劣势：

• 主节点宕机需人工切换（需要运维介入）
• 可用性较低（无自动故障转移）
• 数据延迟（异步复制导致）

典型应用： 电商商品详情页缓存、新闻资讯类应用

2. 哨兵模式（sentinel）

适用场景：

• 高可用需求
• 自动故障转移
• 7x24小时服务

推荐方案： 至少3个哨兵节点+1主2从

优势：

• 自动监控和故障转移（30秒内完成切换）
• 支持通知机制（可通过api对接监控系统）
• 配置中心（自动更新客户端连接信息）

劣势：

• 仅支持单主架构（写入瓶颈）
• 无法解决数据分片问题
• 脑裂问题需要特殊处理

配置示例：

sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 5000

3. 集群模式（cluster）

适用场景：

• 大数据量（tb级）
• 高并发写入
• 需要水平扩展

推荐方案： 至少3主3从（官方推荐）

优势：

• 自动数据分片（16384个slot）
• 支持水平扩展（可动态增删节点）
• 高可用（主从自动切换）

劣势：

• 配置复杂（需要规划槽位分配）
• 客户端需要支持集群协议
• 跨slot操作受限（如事务、lua脚本）

性能指标：

• 单节点：8-10万qps
• 集群：线性扩展（如10节点可达80-100万qps）

最终建议：

中小规模业务（数据量 <10gb，读多写少）

方案：主从复制 + 哨兵模式 实施要点：

1. 部署1主2从架构
2. 配置3个哨兵节点
3. 设置合理的down-after-milliseconds（建议5000ms）
4. 客户端实现自动重连机制

大规模业务（数据量 > 10gb，高并发）

方案：集群模式 实施步骤：

1. 使用redis-cli --cluster create初始化集群
2. 确保每个主节点有1-2个从节点
3. 配置cluster-require-full-coverage为no
4. 监控集群状态（cluster nodes/cluster info）

对数据一致性要求极高的业务（如金融支付）

增强方案：

1. 在集群模式基础上：
   • 设置min-replicas-to-write 2
   • 配置min-replicas-max-lag 10
2. 定期校验：
   • 使用redis-check-aof工具
   • 实现crc校验机制
3. 建议搭配：
   • 持久化采用aof+fsync everysec
   • 部署跨机房容灾方案

到此这篇关于redis 同步机制解析的文章就介绍到这了,更多相关redis 同步机制内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网！