NoSQL 之 Redis 集群

伤不起bb2025-06-11 13:00

目录

[一、Redis 集群方式](#一、Redis 集群方式)

[1. 主从模式](#1. 主从模式)

[2. 哨兵模式](#2. 哨兵模式)

[3. 集群模式](#3. 集群模式)

二、集群模式简介

三、数据分片方式

[1. 客户端分片](#1. 客户端分片)

[2. 代理分片](#2. 代理分片)

（1）概述

[（2）Twemproxy 代理分片机制](#（2）Twemproxy 代理分片机制)

[（3）Codis 代理分片机制](#（3）Codis 代理分片机制)

[3. 服务器端分片](#3. 服务器端分片)

四、负载均衡的实现

五、故障的处理

[1. 故障转移](#1. 故障转移)

[2. 多 slave 选举](#2. 多 slave 选举)

[六、Redis 群集部署](#六、Redis 群集部署)

[1. 部署基础环境](#1. 部署基础环境)

[2. 安装 redis (每个节点都要安装)](#2. 安装 redis (每个节点都要安装))

[3. 修改配置文件](#3. 修改配置文件)

[4. 重启服务并查看状态](#4. 重启服务并查看状态)

[5. 创建 redis 群集](#5. 创建 redis 群集)

[6. 测试群集](#6. 测试群集)

[7. 集群信息查看](#7. 集群信息查看)

[8. 添加节点](#8. 添加节点)

[9. 修改新节点为其他节点的从节点](#9. 修改新节点为其他节点的从节点)

[10. 重新分配槽位](#10. 重新分配槽位)

[11. 删除节点](#11. 删除节点)

一、Redis 集群方式

1. 主从模式

核心概念：

  • 单主节点负责读写，从节点被动复制主节点数据，实现数据备份和读写分离。
  • 基于 replicaof 命令实现主从关系，从节点只读，主节点可读可写。

核心能力：

  • 读写分离：写请求到 Master，读请求到 Slave

  • 数据冗余：Slave 全量复制 Master 数据

  • 手动故障切换：需人工干预主节点故障

局限：

  • 单点写入瓶颈

  • 无自动故障转移

2. 哨兵模式

核心概念：

  • 在主从模式基础上引入 哨兵节点（Sentinel），形成监控集群。
  • 哨兵负责：
    • 监控主从节点状态（心跳检测）。
    • 自动故障转移（主节点宕机时，选举从节点成为新主）。
    • 通知客户端节点拓扑变化。

核心能力：

  • 自动故障转移：Master 宕机时选举新主

  • 配置中心：客户端自动获取拓扑信息

  • 集群监控：实时检测节点健康

局限：

  • 未解决数据分片问题

  • 写性能受单节点限制

3. 集群模式

核心概念：

  • 分布式集群架构，数据通过 分片（Sharding） 分布在多个节点，支持横向扩展。
  • 每个节点既是主节点（负责数据）也是集群成员（通过 Gossip 协议通信）。
  • 引入 哈希槽（Hash Slot） 机制：将数据键映射到 0~16383 共 16384 个槽中，每个主节点负责一部分槽。

核心能力：

  • 数据分片：16384 个槽位分散到多节点

  • 自动路由：客户端直连正确节点

  • 高可用：主从切换 + 多副本存储

适用场景：

  • 数据量 > 单机内存

  • 要求高并发写入

二、集群模式简介

1. 架构设计

  • 节点角色 ：分为 主节点（Master） （处理读写、维护集群元数据）和 从节点（Slave）（备份主节点数据，主故障时可晋升为新主）。
  • 无中心节点：通过 Gossip 协议实现节点间拓扑信息同步，客户端可连接任意节点。

2. 容错与部署

  • 投票容错 ：需 超过半数节点投票 判定某节点故障（如 3 主节点时，2 票即可标记故障），避免 "误判"。
  • 最小部署 ：
    • 主节点至少 3 个（满足投票机制的 "多数决" 条件）；
    • 若为每个主节点搭配 1 个从节点，需 3 主 + 3 从 = 6 节点（提升高可用，应对主节点故障）。所有节点开启集群模式：cluster-enabled yes

3. 核心能力

  • 自动分片 ：通过 哈希槽（16384 个） 分配数据，支持水平扩展（官方理论支持上万节点，实际推荐 ≤1000 节点）。

  • 自主高可用：内置故障转移能力（无需 Sentinel 哨兵），主节点故障时，从节点自动选举新主。

  • 核心特性：

    | 特性 | 说明 |
    | 去中心化 | 无代理层，节点间 Gossip 协议通信 |
    | 数据分片 | 基于哈希槽（Slot）分布数据 |
    | 跨节点操作 | 支持 MGET/MSET 等跨槽命令 |

    迁移透明 槽迁移期间自动重定向请求

4. 适用场景与优势

  • 场景 ：面向 海量数据、高并发、高可用 需求（如电商缓存、社交平台实时数据）。
  • 优势：性能、扩展性和高可用性均优于哨兵模式，且部署配置更简单。

三、数据分片方式

1. 客户端分片

  • 概念 ：
    应用层实现分片逻辑，直接连接不同 Redis 节点，根据键计算目标节点。
  • 实现方式 ：
    • 哈希取模：node = hash(key) % N（N 为节点数）。
    • 一致性哈希：减少节点增减时的数据迁移量。
  • 优缺点 ：
    • ✅ 无中间层，性能高。
    • ❌ 客户端复杂度高（需维护节点列表），动态扩缩容需重启应用。
  • 典型工具 ：Jedis Cluster（Redis 官方客户端）、Redisson。

2. 代理分片

通过中间代理层处理分片逻辑，客户端仅需连接代理。

（1）概述
  • 优点：客户端无感知，适配传统单节点客户端。
  • 缺点：代理可能成为性能瓶颈或单点，需部署多实例（如主从 / 集群）。
（2）Twemproxy 代理分片机制
  • 机制 ：
    • 静态分片：代理启动时通过配置文件指定节点与槽的映射，不支持动态调整。
    • 请求转发：代理解析键，根据配置路由到目标节点。
  • 局限性：扩缩容需重启代理，适合静态架构。
（3）Codis 代理分片机制

优势：

  • 动态扩容：槽迁移无需停机

  • Web 管理界面：可视化操作

  • 多语言 SDK：兼容原生 Redis 协议

机制：

  • 动态分片：通过管理节点（Codis Dashboard）监控节点状态，支持在线添加 / 删除节点。
  • 数据迁移：自动将槽从旧节点迁移到新节点，客户端无感知。

组件：

  • Codis Proxy：负责请求转发和协议转换。
  • Codis Server：基于 Redis 改造的节点，支持动态槽管理。
  • 应用场景：传统架构迁移到分布式 Redis 的过渡方案。

3. 服务器端分片

路由原理 ：

  1. 客户端计算键哈希值：CRC16(key) % 16384

  2. 连接任意节点

  3. 若数据不在该节点，返回 MOVED 重定向

  4. 客户端缓存槽位映射表

机制：

  • 节点自管理：通过 Gossip 协议同步槽分配信息，节点间互相感知拓扑。
  • 客户端重定向：当请求键所在槽不在当前节点时，返回 MOVED 命令，指引客户端连接正确节点。

核心命令：

  • CLUSTER ADDSLOTS <slot...>：分配槽到当前节点。
  • CLUSTER MIGRATE <target-node> <key> 0 <timeout>：迁移数据到目标节点。

四、负载均衡的实现

客户端路由

Redis Cluster 中，客户端依据键名哈希值，通过 哈希槽（hash slot） 定位数据所属节点，将请求发往对应节点，实现负载均衡。哈希槽划分数据并映射到节点，客户端通过键哈希匹配槽对应的节点。

自动迁移

节点加入 / 离开集群时，系统自动重分配 哈希槽 以均衡数据：

  • 节点加入：从其他节点迁移部分哈希槽到新节点；
  • 节点离开 ：将该节点的哈希槽分配给其他节点。
    通过槽迁移，动态调整数据分布，保障负载均衡。
故障检测与恢复
  • 检测：节点间互监健康状态，判定故障节点；
  • 恢复：标记故障节点为下线，重分配其哈希槽；节点恢复后，重新加入集群并迁移数据，保证一致性。

五、故障的处理

1. 故障转移

（1）哨兵模式 vs. 集群模式
维度 哨兵模式 集群模式
触发者 哨兵节点 集群内节点（通过 Gossip 协议）
选举算法 Raft 协议 Raft 协议（用于从节点选举）
数据迁移 无（单分片） 自动迁移槽（扩缩容时）
（2）故障转移流程（以集群模式为例）

  1. 故障检测：

    • 节点通过心跳包（PING/PONG）检测邻居状态，若主节点在 cluster-node-timeout 内未响应，标记为 疑似下线（PFAIL）。
    • 当半数以上主节点认为某主节点 PFAIL 时，标记为 已下线（FAIL），触发故障转移。

  2. 从节点选举：

    • 主节点的从节点竞争成为新主，选举依据：
      • 优先级（slave-priority） ：值越小优先级越高（默认 100，设为 0 则不参与选举）。
      • 复制偏移量：复制进度越新（偏移量越大），数据越完整，优先选举。
      • 运行 ID：优先级和偏移量相同时，取较小的运行 ID（避免脑裂）。

  3. 角色切换：

    • 选举胜出的从节点晋升为主节点，其他从节点改为复制新主。
    • 集群更新槽分配信息，通知客户端新拓扑。

2. 多 slave 选举

  • 配置多个从节点：提高故障转移成功率，避免单从节点故障导致主节点无法恢复。
  • 权重选举 ：通过 slave-priority 为不同从节点设置优先级（如 SSD 节点优先级更高）。
  • 延迟故障转移 ：通过 min-slaves-to-write 和 min-slaves-max-lag 配置，确保主节点至少有 N 个从节点复制延迟低于 M 秒时才允许故障转移，减少数据丢失。

六、Redis 群集部署

1. 部署基础环境

复制代码 
安装gcc
dnf -y install gcc
关闭防火墙
systemctl stop firewalld
systemctl disable firewalld
setenforce 0

2. 安装 redis (每个节点都要安装)

bash 复制代码 
解压redis
tar zxvf redis-5.0.14.tar.gz

make
make PREFIX=/usr/local/redis install
做软链接
ln -s /usr/local/redis/bin* /usr/local/bin

启动
cd /redis/utils
./install_server.sh

3. 修改配置文件

bash 复制代码 
vim /etc/redis/6379.conf
bind 0.0.0.0
appendonly yes
cluster-enabled yes
cluster-config-file nodes-6379.conf
cluster-node-timeout 15000
cluster-require-full-coverage no

参数解释：

"appendonly yes" 表示开启 AOF（Append Only File）持久化模式，Redis 会将写操作追加到 AOF 文件中，用于数据恢复。

"cluster-enabled yes" 意思是启用 Redis 集群模式，使 Redis 支持分布式集群部署。

"cluster-config-file nodes-6379.conf" 指定了集群配置文件为 nodes-6379.conf ，用于存储集群节点的相关配置信息。

"cluster-node-timeout 15000" 设置了集群节点的超时时间为 15000 毫秒，若在该时间内未收到节点的响应，则判定该节点超时。

"cluster-require-full-coverage no" 表示不要求集群必须覆盖所有槽位，即使部分槽位未分配，集群仍可正常运行。

4. 重启服务并查看状态

bash 复制代码 
/etc/init.d/redis_6379 restart
netstat -anpt | grep 6379

5. 创建 redis 群集

bash 复制代码 
--创建集群（3主3从,自动分配主从）
101
redis-cli --cluster create --cluster-replicas 1 192.168.10.101:6379 192.168.10.102:6379 192.168.10.103:6379 192.168.10.104:6379 192.168.10.105:6379 192.168.10.106:6379
  • redis-cli：Redis 命令行界面工具，用于与 Redis 服务器进行交互。
  • --cluster create：表示要创建一个 Redis 集群。
  • --cluster-replicas 1：指定每个主节点配备 1 个从节点，即设置集群的副本数量为 1。

6. 测试群集

bash 复制代码 
#以集群方式登录到
redis-cli -h 192.168.10.105 -p 6379 -c
set name zhangsan

redis-cli -h 192.168.10.103 -p 6379 -c
get centos

7. 集群信息查看

bash 复制代码 
> cluster nodes

8. 添加节点

bash 复制代码 
--添加节点(会成为master，但没有槽，数据不会写入到这里)
1.
redis-cli -c -p 6379 cluster meet 192.168.10.107 6379

2.
另一种方式添加(指定当前集群的任意一个节点，结果和上面一样)
redis-cli --cluster add-node 192.168.10.108:6379 192.168.10.107:6379

9. 修改新节点为其他节点的从节点

bash 复制代码 
redis-cli -h 192.168.10.108 -p 6379
> cluster replicate 107ID

10. 重新分配槽位

bash 复制代码 
redis-cli --cluster rebalance --cluster-threshold 1 --cluster-use-empty-masters 192.168.10.101:6379
命令核心参数解析
参数 作用 示例值 说明
--cluster rebalance 启动集群自动负载均衡 必选 自动重新分配哈希槽，使各节点负载趋于平衡
--cluster-threshold 触发均衡的最小不平衡度 1 当节点间槽数量差异 >=1 时触发迁移（默认值为 1）
--cluster-use-empty-masters 允许使用空主节点接收槽 无参数值 若集群中有新加入的空主节点，会优先分配槽给它们
192.168.10.101:6379 集群中任意节点的地址 集群内节点 IP: 端口 用于连接集群并获取拓

11. 删除节点

bash 复制代码 
清理节点
flushall
cluster reset
删除
redis-cli del-node 192.168.10.108:6379 108ID
相关推荐
眠修22 分钟前
MongoDB 数据库应用
数据库·mongodb
wh_xia_jun1 小时前
mybatis xml 配置中，jdbcType=VARCHAR 的作用
数据库·oracle·tomcat
程序猿小D2 小时前
第24节 Node.js 连接 MongoDB
数据库·mongodb·npm·node.js·编辑器·vim·express
果子⌂3 小时前
PostgreSQL --数据库操作
linux·数据库·postgresql
SeaTunnel4 小时前
如何将SeaTunnel MySQL-CDC与Databend 高效整合？格式与方案全解析
数据库·mysql·开源·数据集成·seatunnel·databend
在肯德基吃麻辣烫4 小时前
《Redis》持久化
数据库·redis·缓存
xiaolyuh1234 小时前
基于binlog恢复误删除MySQL数据
数据库·mysql
Gauss松鼠会4 小时前
GaussDB分布式数据库调优方法总结：从架构到实践的全链路优化指南
数据库·分布式·sql·database·gaussdb
码海漫游者84 小时前
让Python成为你的网站引擎：Django全栈开发初体验！！！
数据库·python·其他·django
热门推荐
01Coze扣子平台完整体验和实践（附国内和国际版对比）02【图像处理与机器视觉】XJTU期末考点03KGG转MP3工具|非KGM文件|解密音频04DeepSeek各版本说明与优缺点分析05从零安装 LLaMA-Factory 微调 Qwen 大模型成功及所有的坑06YOLOv8入门 | 重要性能衡量指标、训练结果评价及分析及影响mAP的因素【发论文关注的指标】07海康Visionmaster-常见问题排查方法-启动阶段08R-tree详解09【SpeedAI科研小助手】2分钟极速解决知网维普重复率、AIGC率过高，一键全文降！文件格式不变，公式都保留的！10零代码入门 | Coze——让大模型接入自己的数据库