redis分布式设计的实现示例

Redis 的分布式设计主要通过三种模式实现，每种模式解决不同的问题：

一、三种分布式模式对比

二、主从复制（Replication）

核心机制

┌─────────┐         全量/增量复制          ┌─────────┐
│  Master │  ───────────────────────────►  │  Slave  │
│  (写)   │                              │  (读)   │
└─────────┘                              └─────────┘

复制流程

1. Slave 发送 SYNC/PSYNC 命令
2. Master 执行 BGSAVE，生成 RDB 文件
3. Master 将 RDB 发送给 Slave
4. Slave 加载 RDB
5. 后续写命令实时同步（增量复制）

关键配置

# slave 配置
replicaof 192.168.1.10 6379
masterauth <password>
# 只读（默认）
replica-read-only yes

问题

• 无法自动故障转移：Master 挂了需要手动切换
• 写压力集中在 Master
• 复制延迟：Slave 数据可能落后

三、哨兵模式（Sentinel）

在主从基础上增加自动监控和故障转移。

架构

        ┌─────────┐
        │ Client  │
        └────┬────┘
             │
    ┌────────┼────────┐
    ▼        ▼        ▼
┌───────┐ ┌───────┐ ┌───────┐
│Sentinel│ │Sentinel│ │Sentinel│  (至少3个，投票决策)
│  1    │ │  2    │ │  3    │
└────┬───┘ └────┬───┘ └────┬───┘
     │          │          │
     └──────────┼──────────┘
                ▼
        ┌─────────────┐
        │   Master    │
        └──────┬──────┘
               │
        ┌──────┴──────┐
        ▼             ▼
    ┌───────┐     ┌───────┐
    │ Slave1│     │ Slave2│
    └───────┘     └───────┘

哨兵的核心功能

故障转移流程

1. 主观下线（SDOWN）：某个 Sentinel 发现 Master 无响应
2. 客观下线（ODOWN）：多个 Sentinel 投票确认 Master 故障
3. 选举 Leader Sentinel：Raft 算法投票
4. 选择最优 Slave（优先级高、复制偏移量大、RunID小）
5. 提升为 Master，其他 Slave 重新配置
6. 通知客户端更新 Master 地址

客户端连接方式

# Python 示例：Sentinel 自动发现 Master
from redis.sentinel import Sentinel
sentinel = Sentinel([
    ('sentinel1', 26379),
    ('sentinel2', 26379),
    ('sentinel3', 26379)
])
# 自动获取当前 Master
master = sentinel.master_for('mymaster', password='xxx')
slave = sentinel.slave_for('mymaster', password='xxx')
master.set('key', 'value')
value = slave.get('key')

缺点

• 只有一个 Master 写，无法水平扩展写性能
• 数据量受限于单节点内存

四、Cluster 集群（最核心）

Redis 真正的分布式方案，通过数据分片实现水平扩展。

架构

┌─────────────────────────────────────────────┐
│              Redis Cluster                   │
│                                              │
│   ┌─────────┐  ┌─────────┐  ┌─────────┐     │
│   │ Node 1  │  │ Node 2  │  │ Node 3  │     │
│   │ [0-5460]│  │[5461-10922]│[10923-16383] │
│   │ Master A│  │ Master B│  │ Master C│     │
│   └───┬─────┘  └────┬────┘  └────┬────┘     │
│       │             │            │          │
│   ┌───┴───┐    ┌───┴───┐   ┌───┴───┐      │
│   │Slave A1│    │Slave B1│   │Slave C1│     │
│   └────────┘    └────────┘   └────────┘      │
│                                              │
│   16384 个哈希槽（Slot）均匀分配到各 Master    │
└─────────────────────────────────────────────┘

核心概念：哈希槽（Hash Slot）

Slot = CRC16(key) % 16384
key "user:1000" → CRC16 = 12345 → 12345 % 16384 = 12345 → 属于 Node 3

为什么用 16384 个槽？

• CRC16 输出范围 0~65535
• 16384 = 2^14，平衡了元数据大小和分片粒度
• 集群节点配置中传播的是槽位映射，不是具体 key

节点通信：Gossip 协议

每个节点每秒随机向几个其他节点发送 PING
携带：自身状态 + 已知其他节点的状态

通过"谣言传播"方式，最终整个集群状态一致

客户端路由

┌─────────┐
│ Client  │
└────┬────┘
     │  SET key value
     ▼
┌─────────┐  计算 key 的 Slot
│ Node 1  │  发现 Slot 不在本地
└────┬────┘
     │ 返回 MOVED 错误，告知正确节点
     ▼
┌─────────┐
│ Client  │  重定向到正确节点
└────┬────┘
     ▼
┌─────────┐
│ Node 3  │  执行命令
└─────────┘

Smart Client（如 redis-py-cluster）会缓存槽位映射，减少重定向。

数据迁移（扩容/缩容）

1. 新节点加入集群
2. 分配部分 Slot 给新节点（如从 Node1 迁 1000 个 Slot）
3. 迁移过程中：
   - 源节点：迁出的 Slot 标记为 IMPORTING
   - 目标节点：标记为 MIGRATING
   - 迁移中的 key：先查源节点，没有则查目标节点
4. 迁移完成后更新槽位映射

Cluster 配置示例

# redis.conf
cluster-enabled yes
cluster-config-file nodes-6379.conf
cluster-node-timeout 5000
cluster-require-full-coverage no  # 部分槽不可用时不拒绝所有请求

# 创建集群（6 节点，3 主 3 从）
redis-cli --cluster create \
  192.168.1.11:6379 192.168.1.12:6379 192.168.1.13:6379 \
  192.168.1.14:6379 192.168.1.15:6379 192.168.1.16:6379 \
  --cluster-replicas 1

五、三种模式对比总结

六、生产环境建议

七、常见问题

1. Cluster 的 key 限制

# 默认不支持跨 Slot 的多 key 操作
MGET key1 key2  # 如果 key1 和 key2 在不同 Slot，报错

# 解决方案：Hash Tag
MGET {user:1000}:name {user:1000}:age  
# {} 内内容用于计算 Slot，确保同一用户数据在同一节点

2. 脑裂问题

网络分区时，原 Master 和 Sentinel 隔离
Sentinel 选举新 Master → 出现两个 Master
解决方案：min-slaves-to-write 配置，确保有足够 Slave 才接受写

3. 数据倾斜

Big Key 或 Hash Tag 使用不当导致某些 Slot 数据量过大
解决方案：监控 Slot 大小，避免 Big Key，合理设计 key

到此这篇关于redis分布式设计的实现示例的文章就介绍到这了,更多相关redis分布式设计内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

最新评论