Redis集群

最新推荐文章于 2025-09-03 18:50:43 发布
原创 最新推荐文章于 2025-09-03 18:50:43 发布 · 980 阅读 · 17 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#redis #数据库 #集群

Redis集群

一，核心概念

  1. 数据分片（Sharding）
    • Redis 集群采用 哈希槽（Hash Slot）实现数据分片，共有 16384 个槽位。
    • 每个主节点负责一部分槽位，如 3 主节点集群中，每个节点约负责 5461 个槽位（16384/3）。
    • 数据定位公式：slot = CRC16(key) % 16384。
  2. 主从复制
    • 每个主节点至少有一个从节点，主节点故障时，从节点自动升级为新主节点。
    • 复制过程采用异步方式，保证高可用性但不保证强一致性。
  3. 故障转移
    • 通过 Gossip 协议交换节点状态信息（Ping/Pong 消息）。
    • 当半数以上主节点认为某个主节点下线时，触发故障转移。

二，Redis集群方式

1、主从复制（Master-Slave Replication）

基本概念

主从复制是 Redis 最早支持的集群方式，通过将一个 Redis 实例（主节点）的数据复制到一个或多个从节点，实现数据的冗余和读写分离。

核心特点
  • 数据同步：主节点负责写入操作，从节点自动同步主节点数据，支持全量同步（RDB 快照）和增量同步（基于命令日志）。
  • 读写分离：主节点处理写请求，从节点处理读请求，分担读压力。
  • 高可用性基础：从节点可作为备份，但若主节点故障，需手动切换或配合哨兵模式实现自动故障转移。
优缺点
  • 优点
    • 实现简单，配置方便，无需额外组件。
    • 读写分离提升读性能，适合读多写少场景。
  • 缺点
    • 主节点单点故障风险，需人工干预切换。
    • 从节点数量过多可能影响主节点性能（数据同步开销）。
适用场景
  • 读多写少的业务场景（如缓存、排行榜查询）。
  • 对数据备份和容灾有基础需求，但无需自动故障转移的场景。

2、哨兵模式（Sentinel）

基本概念

哨兵模式是在主从复制基础上，引入哨兵节点（Sentinel）组成的监控集群，用于自动监控主从节点状态，并在主节点故障时自动选举新主节点，实现故障转移。

核心组件
  • 哨兵节点：独立的 Redis 实例，负责监控主从节点健康状态，协调故障转移。
  • 主从节点：与主从复制结构相同，但由哨兵管理切换。
核心流程
  1. 哨兵定期向主从节点发送心跳，检测节点存活状态。
  2. 当主节点被多数哨兵判定为 “下线”（主观下线→客观下线），触发故障转移。
  3. 哨兵从从节点中选举新主节点，并通知其他从节点切换到新主。
优缺点
  • 优点
    • 自动故障转移，无需人工干预，提升系统可用性。
    • 支持多哨兵节点，避免哨兵单点故障（需部署奇数个哨兵，如 3 个）。
  • 缺点
    • 数据仍集中在主节点，无法突破单节点内存限制。
    • 故障转移期间存在短暂服务中断（毫秒级到秒级）。
适用场景
  • 对高可用性要求较高的业务（如实时数据服务）。
  • 写操作频率适中，无需水平扩展的场景。

3、集群模式（Redis Cluster）

基本概念

Redis Cluster 是 Redis 3.0 后引入的分布式集群方案，通过将数据分片（Sharding）到多个节点，实现数据的水平扩展和高可用性，是目前官方推荐的分布式方案。

核心原理
  • 数据分片：将键空间（0~16383）划分为 16384 个槽位（Slot），每个节点负责部分槽位，客户端通过计算键的哈希值确定对应槽位和节点。
  • 节点通信：节点间通过 Gossip 协议交换状态信息，维护集群拓扑结构。
  • 高可用性：每个主节点配备从节点，主节点故障时，从节点自动升级为主节点，保证槽位服务不中断。
核心特点
  • 水平扩展：可通过添加节点扩展集群容量和性能，理论上无节点数量上限。
  • 自动分片：无需客户端手动分片，集群自动管理槽位分配和迁移。
  • 去中心化：无中心节点，每个节点都可处理读写请求，避免单点瓶颈。
优缺点
  • 优点
    • 支持大规模数据存储和高并发访问。
    • 自动故障转移和数据均衡，运维成本较低。
  • 缺点
    • 实现较复杂，客户端需支持集群协议（如 Jedis、Redisson）。
    • 跨节点操作（如事务、Lua 脚本）存在限制，需保证键在同一节点。
适用场景
  • 数据量庞大、并发要求高的场景（如电商缓存、社交平台实时数据）。
  • 需要水平扩展和高可用性的分布式系统。

4、集群方式对比与选择建议

集群方式主从复制哨兵模式Redis Cluster
数据分片不支持不支持支持（16384 个槽位）
自动故障转移不支持支持支持
水平扩展不支持不支持支持
高可用性低（需手动切换）中（自动切换）高（多主多从）
适合场景读多写少、简单备份高可用、中等规模数据大规模数据、高并发

三，集群示例

8台主机操作是一样的安装redis 前6台搭建集群环境后2台做集群扩展

3.1先搭建集群环境

[root@localhost redis]# vim 6379.conf 
# 绑定地址：允许所有 IP 访问（生产环境建议绑定具体 IP）
bind 0.0.0.0

# 开启 AOF 持久化，保证数据安全性（默认 RDB 持久化可能丢失部分数据）
appendonly yes

# 启用 Redis Cluster 集群模式
cluster-enabled yes

# 集群配置文件路径，自动生成，记录节点信息（如节点 ID、状态）
cluster-config-file nodes-6379.conf

# 节点超时时间（毫秒）：超过此时间未响应则认为节点故障
cluster-node-timeout 15000

# 集群全量覆盖要求：必须所有槽位（16384 个）都有节点负责才能提供服务
# 若设置为 no，则部分槽位不可用时集群仍可读写（部分服务降级）
cluster-require-full-coverage yes
# 重启 Redis 服务（基于 6379.conf 配置）
[root@localhost bin]# /etc/init.d/redis_6379  restart

# 查看端口监听状态，确认 Redis 服务正常运行
[root@localhost bin]# netstat -anpt | grep 6379

# 输出结果说明：
# 1. 6379 端口：Redis 服务主端口，处理客户端请求
tcp        0      0 0.0.0.0:6379            0.0.0.0:*               LISTEN      13591/redis-server  

# 2. 16379 端口：Redis Cluster 集群总线端口（主端口 + 10000）
#    用于节点间通信（Gossip 协议），交换拓扑信息、故障检测等
tcp        0      0 0.0.0.0:16379           0.0.0.0:*               LISTEN      13591/redis-server  

# 3. TIME_WAIT 状态连接：客户端连接关闭后的临时状态（TCP 四次挥手）
tcp        0      0 127.0.0.1:6379          127.0.0.1:45714         TIME_WAIT   -

3.2创建集群

[root@localhost bin]# 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
>>> Performing hash slots allocation on 6 nodes...
Master[0] -> Slots 0 - 5460
Master[1] -> Slots 5461 - 10922
Master[2] -> Slots 10923 - 16383
Adding replica 192.168.10.105:6379 to 192.168.10.101:6379
Adding replica 192.168.10.106:6379 to 192.168.10.102:6379
Adding replica 192.168.10.104:6379 to 192.168.10.103:6379
M: 189f4095a9c7687ff22b0031848c6740f8b47ca3 192.168.10.101:6379
   slots:[0-5460] (5461 slots) master
M: 54c4cb5770e18a2607195ed8f10599a894def57f 192.168.10.102:6379
   slots:[5461-10922] (5462 slots) master
M: 70d4f069e0bac3c765c5643331537066d8a33c26 192.168.10.103:6379
   slots:[10923-16383] (5461 slots) master
S: c0b5dc5e89a506d482587a6edc52d89ded79b4aa 192.168.10.104:6379
   replicates 70d4f069e0bac3c765c5643331537066d8a33c26
S: c7af1a944061b7a2206edc4c505d50186bfbd86d 192.168.10.105:6379
   replicates 189f4095a9c7687ff22b0031848c6740f8b47ca3
S: bb68e02516c31a4088278acf5d0e905eee1c2fef 192.168.10.106:6379
   replicates 54c4cb5770e18a2607195ed8f10599a894def57f
Can I set the above configuration? (type 'yes' to accept): yes
>>> Nodes configuration updated
>>> Assign a different config epoch to each node
>>> Sending CLUSTER MEET messages to join the cluster
Waiting for the cluster to join
.
>>> Performing Cluster Check (using node 192.168.10.101:6379)
M: 189f4095a9c7687ff22b0031848c6740f8b47ca3 192.168.10.101:6379
   slots:[0-5460] (5461 slots) master
   1 additional replica(s)
S: c7af1a944061b7a2206edc4c505d50186bfbd86d 192.168.10.105:6379
   slots: (0 slots) slave
   replicates 189f4095a9c7687ff22b0031848c6740f8b47ca3
M: 54c4cb5770e18a2607195ed8f10599a894def57f 192.168.10.102:6379
   slots:[5461-10922] (5462 slots) master
   1 additional replica(s)
S: bb68e02516c31a4088278acf5d0e905eee1c2fef 192.168.10.106:6379
   slots: (0 slots) slave
   replicates 54c4cb5770e18a2607195ed8f10599a894def57f
M: 70d4f069e0bac3c765c5643331537066d8a33c26 192.168.10.103:6379
   slots:[10923-16383] (5461 slots) master
   1 additional replica(s)
S: c0b5dc5e89a506d482587a6edc52d89ded79b4aa 192.168.10.104:6379
   slots: (0 slots) slave
   replicates 70d4f069e0bac3c765c5643331537066d8a33c26
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.

以下是 Redis Cluster 创建命令及输出的详细注释：

创建集群命令

redis-cli --cluster create \
--cluster-replicas 1 \  # 每个主节点分配1个从节点（主从比例1:1）
192.168.10.101:6379 \  # 节点1（主节点）
192.168.10.102:6379 \  # 节点2（主节点）
192.168.10.103:6379 \  # 节点3（主节点）
192.168.10.104:6379 \  # 节点4（从节点）
192.168.10.105:6379 \  # 节点5（从节点）
192.168.10.106:6379   # 节点6（从节点）
  • 原理：将 6 个节点自动分配为 3 主 3 从，每个主节点对应一个从节点，实现高可用。

槽位分配结果

Master[0] -> Slots 0 - 5460        # 主节点1负责槽位0~5460（共5461个）
Master[1] -> Slots 5461 - 10922    # 主节点2负责槽位5461~10922（共5462个）
Master[2] -> Slots 10923 - 16383   # 主节点3负责槽位10923~16383（共5461个）
  • 槽位机制：Redis Cluster 将所有数据划分为 16384 个槽位，每个主节点负责一部分槽位。
  • 分配逻辑：自动均匀分配槽位（尽量平均，但因总数无法整除，主节点 2 多 1 个槽位）。

主从关系分配

Adding replica 192.168.10.105:6379 to 192.168.10.101:6379  # 节点5是节点1的从节点
Adding replica 192.168.10.106:6379 to 192.168.10.102:6379  # 节点6是节点2的从节点
Adding replica 192.168.10.104:6379 to 192.168.10.103:6379  # 节点4是节点3的从节点
  • 高可用保障：当主节点故障时，对应的从节点会自动升级为主节点继续服务。

集群拓扑结构（简化版）

主节点1 (101:6379)
└── 从节点5 (105:6379)

主节点2 (102:6379)
└── 从节点6 (106:6379)

主节点3 (103:6379)
└── 从节点4 (104:6379)

集群验证输出

[OK] All nodes agree about slots configuration.  # 所有节点槽位配置一致
[OK] All 16384 slots covered.                   # 所有槽位都有主节点负责（无缺失）
  • 关键点
    • 槽位覆盖完整：所有 16384 个槽位均被分配，集群可正常提供服务。
    • 节点状态一致：通过 Gossip 协议，所有节点达成槽位分配共识。

3.3测试集群

6个随便登录一个都可以

# 连接到集群节点 192.168.10.106:6379，-c 参数启用集群模式（支持自动重定向）
[root@localhost bin]# redis-cli -h 192.168.10.106 -p 6379 -c

# 设置键值对：name=zhangsan
192.168.10.106:6379> set name zhangsan
# 自动重定向到槽位 5798 所在的节点 192.168.10.102:6379
-> Redirected to slot [5798] located at 192.168.10.102:6379
OK

# 从重定向后的节点获取键值
192.168.10.102:6379> get name
"zhangsan"

# 查看集群拓扑结构
192.168.10.102:6379> cluster nodes
# 节点格式：<节点ID> <IP:端口>@<总线端口> <角色> <主节点ID> <最后一次心跳时间> <节点ID> <状态> <槽位范围>

# 从节点 1（106:6379）：复制主节点 102:6379
bb68e02516c31a4088278acf5d0e905eee1c2fef 192.168.10.106:6379@16379 slave 54c4cb5770e18a2607195ed8f10599a894def57f 0 1744018709015 6 connected

# 从节点 2（105:6379）：复制主节点 101:6379
c7af1a944061b7a2206edc4c505d50186bfbd86d 192.168.10.105:6379@16379 slave 189f4095a9c7687ff22b0031848c6740f8b47ca3 0 1744018709859 5 connected

# 从节点 3（104:6379）：复制主节点 103:6379
c0b5dc5e89a506d482587a6edc52d89ded79b4aa 192.168.10.104:6379@16379 slave 70d4f069e0bac3c765c5643331537066d8a33c26 0 1744018710901 4 connected

# 主节点 3（103:6379）：负责槽位 10923-16383
70d4f069e0bac3c765c5643331537066d8a33c26 192.168.10.103:6379@16379 master - 0 1744018705678 3 connected 10923-16383

# 主节点 1（101:6379）：负责槽位 0-5460
189f4095a9c7687ff22b0031848c6740f8b47ca3 192.168.10.101:6379@16379 master - 0 1744018708807 1 connected 0-5460

# 主节点 2（102:6379，当前连接节点）：负责槽位 5461-10922
54c4cb5770e18a2607195ed8f10599a894def57f 192.168.10.102:6379@16379 myself,master - 0 0 2 connected 5461-10922

3.4扩展集群

概念
  • 新加入的节点在初始阶段没有任何数据分片，因为 Redis 集群的数据是通过哈希槽（Hash Slot）分配到各个主节点的。在现有的集群环境下添加新的节点是没有哈希槽的因为哈希槽已经被分完了
  • 新加入的节点状态信息都是master
第一个方式
[root@localhost bin]# redis-cli -c -p 6379 cluster meet 192.168.10.107 6379
OK
[root@localhost bin]# redis-cli 
127.0.0.1:6379> cluster nodes
be80d7bb5b0316220defa9a1dc2c2156b4ff486d 192.168.10.107:6379@16379 master - 0 1744019619971 0 connected
第二个方式
[root@localhost bin]# redis-cli --cluster add-node 192.168.10.108:6379 192.168.10.101:6379
>>> Adding node 192.168.10.108:6379 to cluster 192.168.10.101:6379
>>> Performing Cluster Check (using node 192.168.10.101:6379)
M: 189f4095a9c7687ff22b0031848c6740f8b47ca3 192.168.10.101:6379
   slots:[0-5460] (5461 slots) master
   1 additional replica(s)
M: be80d7bb5b0316220defa9a1dc2c2156b4ff486d 192.168.10.107:6379
   slots: (0 slots) master
S: c7af1a944061b7a2206edc4c505d50186bfbd86d 192.168.10.105:6379
   slots: (0 slots) slave
   replicates 189f4095a9c7687ff22b0031848c6740f8b47ca3
M: 54c4cb5770e18a2607195ed8f10599a894def57f 192.168.10.102:6379
   slots:[5461-10922] (5462 slots) master
   1 additional replica(s)
S: bb68e02516c31a4088278acf5d0e905eee1c2fef 192.168.10.106:6379
   slots: (0 slots) slave
   replicates 54c4cb5770e18a2607195ed8f10599a894def57f
M: 70d4f069e0bac3c765c5643331537066d8a33c26 192.168.10.103:6379
   slots:[10923-16383] (5461 slots) master
   1 additional replica(s)
S: c0b5dc5e89a506d482587a6edc52d89ded79b4aa 192.168.10.104:6379
   slots: (0 slots) slave
   replicates 70d4f069e0bac3c765c5643331537066d8a33c26
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.
>>> Send CLUSTER MEET to node 192.168.10.108:6379 to make it join the cluster.
[OK] New node added correctly.
区别
命令操作对象操作方式适用场景
redis-cli -c -p 6379 cluster meet 192.168.10.107 6379单个节点（客户端视角）通过执行 CLUSTER MEET 命令直接操作手动添加节点，需逐个执行命令
redis-cli --cluster add-node 192.168.10.108:6379 192.168.10.101:6379整个集群（工具视角）使用 redis-cli --cluster 工具批量操作自动化添加节点，工具自动处理集群逻辑
详细区别

1. cluster meet 命令

  • 操作对象：单个 Redis 节点

  • 执行方式：通过客户端连接到现有节点（如 -p 6379），执行 CLUSTER MEET 命令

  • 核心逻辑：

    1. 通知当前连接的节点（如 192.168.10.101:6379）去 “认识” 新节点（192.168.10.107:6379）
    2. 现有节点与新节点建立 Gossip 通信，交换拓扑信息
    3. 需在每个现有节点上都执行一次该命令，才能让整个集群发现新节点

  • 示例流程：

    # 1. 连接到节点101，让它认识新节点107
redis-cli -c -h 192.168.10.101 -p 6379 cluster meet 192.168.10.107 6379

# 2. 重复上述操作，连接到节点102和103，让它们也认识新节点107
redis-cli -c -h 192.168.10.102 -p 6379 cluster meet 192.168.10.107 6379
redis-cli -c -h 192.168.10.103 -p 6379 cluster meet 192.168.10.107 6379

2. redis-cli --cluster add-node 命令

  • 操作对象：整个 Redis 集群

  • 执行方式：通过 redis-cli 的集群管理工具（--cluster 参数）操作

  • 核心逻辑：

    1. 工具自动连接到种子节点（如 192.168.10.101:6379）
    2. 获取集群拓扑信息
    3. 自动向所有现有节点发送 CLUSTER MEET 命令，将新节点（192.168.10.108:6379）加入集群
    4. 自动更新集群配置

  • 示例流程：

    # 仅需一次命令，工具会自动处理所有节点
redis-cli --cluster add-node 192.168.10.108:6379 192.168.10.101:6379
关键差异点总结
维度cluster meetredis-cli --cluster add-node
操作复杂度高（需在每个节点执行一次）低（单命令自动处理）
拓扑感知需手动同步所有节点自动同步整个集群
错误处理需手动处理网络分区等异常工具自动处理常见异常
角色指定默认添加为主节点可通过 --cluster-slave 指定从节点
适用场景调试、手动维护生产环境自动化部署

3.4修改master为slave

刚才我们把107和108加入到集群环境内107和108初始状态都是master这里我将108设置为107的slave

# 连接到 Redis 节点 192.168.10.108:6379（未使用 -c 参数，以单机模式连接）

[root@localhost redis]# redis-cli -h 192.168.10.108 -p 6379

# 在集群模式下，将当前节点（108:6379）设置为指定主节点的从节点
# CLUSTER REPLICATE <主节点ID> 命令用于让当前节点复制另一个主节点的数据
192.168.10.108:6379> cluster replicate be80d7bb5b0316220defa9a1dc2c2156b4ff486d
OK

3.5删除节点

1清空槽位信息

# 连接到 Redis 节点 192.168.10.102:6379（未使用 -c 参数，以单机模式连接）
[root@localhost bin]# redis-cli -h 192.168.10.102 -p 6379

# 清空当前数据库中的所有键值对（危险操作！）
# FLUSHALL 命令会删除当前节点上的所有数据，无论该节点是主节点还是从节点
192.168.10.102:6379> flushall
OK

2删除节点

# 使用 redis-cli 的集群管理工具删除指定节点
# 命令格式：redis-cli --cluster del-node <集群任意节点> <待删除节点ID>
[root@localhost bin]# redis-cli --cluster del-node 192.168.10.102:6379 54c4cb5770e18a2607195ed8f10599a894def57f

3.6重新分配哈希槽

# 使用 redis-cli 的集群管理工具对集群进行自动负载均衡
# 命令格式：redis-cli --cluster rebalance [选项] <集群种子节点>
[root@localhost bin]# redis-cli --cluster rebalance \
  --cluster-threshold 1 \        # 设置平衡阈值为 1，表示节点间槽位数量差异超过 1 时触发平衡
  --cluster-use-empty-masters \  # 允许将槽位迁移到空的主节点（即尚未分配槽位的主节点）
  192.168.10.101:6379           # 指定集群中的任意节点作为入口点，用于获取集群拓扑信息

关键点解析

  1. 负载均衡原理

    • Redis 集群将 16384 个槽位分配给各个主节点
    • 随着节点的添加或移除，槽位分布可能变得不均匀
    • rebalance 命令会自动将槽位从负载高的节点迁移到负载低的节点

  2. 参数详解

    • --cluster-threshold 1
      • 控制平衡的敏感度
      • 值越小，触发平衡的频率越高
      • 例如：当阈值为 1 时，若某个主节点比其他主节点多 2 个槽位，就会触发迁移
    • --cluster-use-empty-masters
      • 特别适用于新添加的空主节点
      • 允许将槽位迁移到这些空节点，充分利用新资源
      • 若不指定该参数，空主节点将不会参与负载均衡

  3. 执行流程

    # 1. 工具连接到指定节点（192.168.10.101:6379）
# 2. 获取集群拓扑信息（节点列表、槽位分配）
# 3. 计算每个节点的负载情况
# 4. 确定需要迁移的槽位及其目标节点
# 5. 执行槽位迁移（每次迁移一个槽位，包含该槽位下的所有键）
redis集群
Late_breeze的博客
09-09 1352
redis集群原理以及实验搭建
Redis集群弱/空密码问题整改
11-15
使用redis安装用户，在命令行连接上redis集群后，执行命令：config set requirepass 【自定义的强密码】，如： config set requirepass mypassword@#75@~ 然后执行 config rewrite 将配置密码持久化到redis配置文件...
Redis 集群
2503_91100205的博客
06-09 2292
在当今互联网高并发、海量数据的场景下，单机 Redis 已无法满足系统对性能、存储和高可用性的需求。Redis 集群作为分布式缓存的终极解决方案，通过巧妙的架构设计实现了数据分片、自动故障转移和动态扩容。本文将从原理出发，深入剖析 Redis 集群的核心机制，并通过完整的实战部署流程，带您掌握这一强大的分布式技术。Redis Cluster 通过哈希槽分片与自动故障转移，完美解决了单机 Redis 的三大痛点：存储限制、写操作瓶颈和手动运维成本。高并发读写：电商秒杀、社交平台 feed 流海量数据存储。
Redis 集群方式
qq_51678989的博客
08-12 5177
集群，即 Redis cluster， 是 Redis 3.0开始引入的分布式存储方案。集群由多个节点(Node)组成，Redis 的数据分布在这些节点中。集群中的节点分为主节点和从节点;只有主节点负责读写请求和集群信息的维护;从节点只进行主节点数据和状态信息的复制。
Redis集群详解
热门推荐
怪咖@的博客
06-26 2万+
在了解Redis集群之前尽量先了解清楚Redis的主从复制和哨兵机制。读写分离，性能扩展，降低主服务器的压力容灾，快速恢复，主机挂掉时，从机变为主机Redis 主从模式不具备自动容错和恢复功能，如果主节点宕机，Redis 集群将无法工作，此时需要人为干预，将从节点提升为主节点。哨兵机制作用主要是监控主从节点，当主节点挂掉，通过内部投票机制，从 从节点当中选出一个主节点，这样可以避免人工成本。虽然主从+哨兵采用了多节点，但是他们存在的目的主要是解决容灾问题，而并非性能问题。
redis集群配置
QAZ412803的博客
10-26 2780
主从复制是将一台Redis服务器的数据复制到其他Redis服务器，前者叫master/leader主节点，后者成为从节点slave/follower，数据库的复制是单项的，只能由主–>从，master以写为主，slave以读为主，利用主从复制实现读写分离，最低配的主从复制也需要一主二从。主从复制中，从节点只能进行读操作，如果在从节点执行写命令则会报错，主节点可以执行读写操作，但我们网网规定主节点只能进行写操作，这样也是符合了读写分离；默认情况下，每个Redis服务器都为主节点，即master。
Redis 集群搭建
菜鸟一枚,对云原生感兴趣
07-23 3218
使用 Redis 集群进行扩展 |文档请注意，按预期工作的小集群必须包含 至少三个主节点。对于部署，我们强烈建议 一个六节点集群，包含三个主节点和三个副本。三台服务器各部署一个主节点、一个从节点，同一台服务器上不是直接主从关系。操作系统Centos 7Centos 7Centos 7内核版本主机名称node-01node-02node-03角色IP地址Redis7.2.57.2.57.2.5。
Redis集群篇
蓝影铁哥的博客
07-08 2182
Redis集群
Redis集群部署
qq_40945306的博客
04-24 2062
redis集群部署（虚拟机三主三从）
redis集群设置
大道至简，持之以恒！
03-25 2755
目录 一、背景 二、集群中的主从复制 三、部署redis集群 1、环境搭建 2、集群结点规划 四、 部署结果验证 五、注意事项 一、背景 1、redis的主从和mysql很像，但是配置很简单。slaveof 192.168.80.126 6379然后启动主从便可以了。 但是如果redis主节点发生故障，不会自动切换，需要借助redis的sentinel或者keepalive来实现主的故障转移。（故而可以使用Sentinel来做redis的集群） 2、redis集群是一个
zabbix监控redis集群
03-25
本文将详细讲解如何使用Zabbix监控Redis集群，包括Zabbix服务器的安装、Redis集群的部署以及监控脚本的编写。 首先，我们要准备Redis服务器。在Linux环境中，通常使用`yum`命令来安装Redis。在遇到`yum install ...
Redis集群数据迁移操作文档
06-29
《Redis集群数据迁移实战指南》 在IT领域，数据迁移是一项关键任务，特别是在使用Redis这样的高性能内存数据库时。本文将详细介绍如何进行Redis集群的数据迁移，包括全量和增量数据迁移，以及离线迁移的方法，主要...
redis集群批量插入
11-23
本文将详细讨论如何在Java环境下连接Redis集群并实现批量插入String类型的数据。 首先，我们需要理解Redis集群的基本概念。Redis集群是通过分片（Sharding）技术来分散数据到多个节点，每个节点存储一部分数据。在...
Redis集群下过期key监听的实现代码
09-09
在讨论Redis集群下过期key监听的实现代码之前，首先需要明确几个核心概念和组件： Redis集群是Redis的一种高可用性解决方案，它通过将数据分布在不同的Redis节点上，并提供一定机制保证数据的复制和高可用性。集群...
【Redis缓存】Mysql分页查询如何使用Redis进行分页缓存优化？
m0_74808313的博客
09-01 221
摘要：文章介绍了一种利用Redis优化MySQL分页查询性能的策略。该方案通过查询数据库获取分页ID列表，再从Redis缓存中获取详情数据，若缓存未命中则异步重建缓存，并使用分布式锁防止缓存击穿。具体实现包括：1)查询分页ID；2)获取缓存详情；3)处理未命中缓存；4)异步重建缓存；5)返回现有数据。案例展示了活动分页查询的实现，通过细粒度缓存和双重检查机制，在保证性能的同时处理短暂不一致，适用于高性能场景。
【面试场景题】不使用redis、zk如何自己开发一个分布式锁
青鱼入云的博客
09-01 933
基于数据库的分布式锁实现简单，无需依赖额外中间件，适合中小规模分布式场景。其核心是通过唯一约束实现互斥过期时间防止死锁持有者校验保证安全。但在高并发场景下，需通过分库分表、本地缓存等方式优化性能，或考虑基于分布式文件系统（如NFS）的实现（原理类似，通过文件独占锁实现互斥）。
Redis 集群模式与高可用机制
最新发布
落地
09-03 186
Redis集群模式通过哈希槽(16384个)实现数据分片，支持多Master节点(建议奇数)和Slave备份。它采用心跳检测和多数投票机制实现高可用，当Master故障时自动切换Slave为Master。适用于写密集型场景，但数据同步会占用带宽，常规场景下哨兵模式可能更合适。集群模式有效解决了单节点瓶颈问题，但节点过多会增加心跳开销(O(N²))。
redis 集群
04-01
### Redis 集群的搭建与配置 #### 一、Redis 集群简介 Redis 是一种高性能的键值存储系统，支持多种数据结构操作。通过集群模式可以实现分布式存储和高可用性。Redis 集群允许多个 Redis 实例协同工作，提供更高的吞吐量和更强的数据持久化能力。 --- #### 二、环境准备 在开始之前，需确认以下条件已满足： - 所有服务器的操作系统版本一致（如 CentOS 7 或 Windows），并安装了相同版本的 Redis 软件。 - 已关闭防火墙或开放必要的端口（默认 Redis 使用 6379 及其衍生端口）。 - 每台服务器上至少有两个 Redis 实例运行，分别作为主节点和从节点[^1]。 --- #### 三、具体步骤 ##### 1. 下载并解压 Redis 文件 下载指定版本的 Redis 压缩包（如 Redis 6.2.5 或更高版本），将其解压到目标路径下。例如，在 Linux 中执行以下命令： ```bash wget http://download.redis.io/releases/redis-6.2.5.tar.gz tar -zxvf redis-6.2.5.tar.gz cd redis-6.2.5 make ``` ##### 2. 创建多个实例目录 为每个 Redis 实例创建独立的工作目录，并复制 `redis.conf` 至对应文件夹中。例如： ```bash mkdir -p /service/redis/{6379,6380} cp redis.conf /service/redis/6379/ cp redis.conf /service/redis/6380/ ``` ##### 3. 修改配置文件 编辑每个实例下的 `redis.conf` 文件，设置不同的监听端口号和其他必要参数。以下是关键配置项： - 设置绑定 IP 地址：`bind 0.0.0.0` - 关闭保护模式：`protected-mode no` - 开启集群功能：`cluster-enabled yes` - 指定集群配置文件位置：`cluster-config-file nodes-{port}.conf` - 设定日志级别：`loglevel notice` ##### 4. 启动 Redis 实例 依次启动各个 Redis 实例。例如： ```bash redis-server /service/redis/6379/redis.conf redis-server /service/redis/6380/redis.conf ``` 如果是在多台物理机上部署，则需要远程登录每台机器重复上述过程[^2]。 ##### 5. 构建集群拓扑 利用 `redis-cli` 的集群管理工具完成初始化操作。假设当前存在六个节点分布在三台主机上，则可输入如下指令构建集群关系： ```bash redis-cli --cluster create \ 192.168.x.y:6379 192.168.x.z:6379 ... \ --replicas 1 ``` 其中 `--replicas` 参数表示每个主节点分配几个副本[^4]。 ##### 6. 验证集群状态 最后可以通过以下方式验证集群是否正常运作： ```bash redis-cli -c -h {任意IP} -p {任一口号} CLUSTER INFO CLUSTER NODES PING SET key value GET key ``` --- #### 四、注意事项 - 如果使用 Docker 容器来部署 Redis 集群，请确保容器间网络互通良好。 - 对于 Windows 平台上的开发测试场景，可通过批处理脚本来简化服务启动流程[^3]。 --- #### 五、示例代码片段 下面展示了一个简单的 Python 程序用于连接至 Redis 集群并向其中写入一条记录： ```python import redis r = redis.StrictRedisCluster(startup_nodes=[{"host": "127.0.0.1", "port": "6379"}], decode_responses=True) r.set('foo', 'bar') print(r.get('foo')) ``` ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值