Redis 集群模式优化和备份

原创 于 2025-11-21 10:05:00 发布 · 41 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#redis #数据库 #缓存

现有系统环境

  • 操作系统：Rocky Linux release 9.5
  • 内存：16G
  • CPU：8核心
  • SSD 存储

系统参数调优建议

内存管理

  • vm.swappiness
    将 vm.swappiness 降低，以减少对 swap 的依赖。默认值是较高（通常 60），可以调成 10 或 5，根据你的工作负载决定。较低值能使系统更倾向于使用内存，而不是 swap。
 vm.swappiness=10

永久设置可以写入 /etc/sysctl.d/99-sysctl.conf 或者 /etc/sysctl.conf。

  • vm.dirty_ratio 和 vm.dirty_background_ratio
    控制内核将多少脏页 (dirty pages) 写回磁盘。对于 SSD，可以适当调高，以减少频繁的写回，但也不能太高。
    例如：
vm.dirty_background_ratio = 5
vm.dirty_ratio = 20

这两个值需要结合实际 I/O 压力测试。

  • 关闭或限制 swap（视具体情况）

    • 如果应用对内存需求很大、且对 swap 延迟敏感，可以考虑关闭 swap（swapoff +从 fstab 移除 swap）。
    • 或者使用 zram（压缩内存）来代替 swap。

文件句柄 & 进程数

  • fs.file-max
    提高系统能打开的最大文件描述符数
fs.file-max = 2000000

这个值要根据并发连接数和负载调整。

  • 用户级别的 file descriptors
    修改 /etc/security/limits.d/ 下的配置（例如 99-nofile.conf），对于服务账号 (如应用进程) 提高 nofile 限制。

网络 / TCP 调优

  • net.core.somaxconn
    增加监听 socket 的 backlog 队列长度。
net.core.somaxconn = 1024
  • net.ipv4.tcp_fin_timeout
    调低 TIME_WAIT 状态持续时间（视场景慎用）
net.ipv4.tcp_fin_timeout = 30
  • net.ipv4.tcp_tw_reuse
    允许重用处于 TIME_WAIT 的 TCP socket
net.ipv4.tcp_tw_reuse = 1
  • 接收 / 发送缓冲区
    可以适当调大 rmem 和 wmem：
net.core.rmem_default = 262144
net.core.wmem_default = 262144
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

CPU 调度与频率

  • CPU 调频策略 (governor)
    根据负载选择合适的调频策略 (governor)，例如 performance（高性能） 或 schedutil / ondemand。如果负载是较为稳定且追求响应性，可以设置为 performance。
# 安装 cpupower（如果还没装）
dnf install kernel-tools

# 设置 governor
cpupower frequency-set --governor performance

  • CPU 亲和性 (Affinity)
    对关键服务 (应用进程 /关键线程) 设置 CPU 亲和性 (affinity)，使它们跑在专门的核心上，减少调度开销。

  • 调度器调优 (Scheduler)
    默认 Linux 调度器 (CFS)对大多数场景不错。如果有特殊实时或延迟敏感任务，可以深入调度器参数 (但风险较高)

I/O 子系统 (SSD) 优化

  • I/O 调度器 (Scheduler)
    对于 SSD (尤其是 NVMe)，推荐使用 noop 或 mq-deadline 等轻量调度器或者直接使用 none（如果硬件和内核版本支持）。其实在现代内核中，NVMe 的默认调度器就非常高效。
echo none > /sys/block/nvme0n1/queue/scheduler

（替换为实际使用的设备名）

  • 队列深度 (nr_requests / queue_depth)
    可以调优每个块设备的 I/O 队列深度 (取决于硬件)。

  • 刷盘 (flush) 策略
    根据你的 SSD 特性和写负载，可以调整 dirty_* 参数（见上文）以控制内核何时将缓存写回磁盘。

  • 文件系统选择与挂载选项

    • 如果使用 XFS / EXT4 /其他文件系统，挂载时选择适合 SSD 的 mount 参数 (如 noatime, nodiratime)。
    • 可以考虑启用 discard / fstrim (手动或定时)，但 discard 对性能的影响依设备而异。

日志 & 服务调优

  • 关闭或禁用不必要的 systemd 服务
    用 systemd-analyze blame 查看启动和运行时开销，禁用不必要的服务。

  • 日志轮询 /日志级别
    如果日志非常频繁 (例如大量 rsyslog 或 journal)，考虑减少日志写频率或级别。长期高频日志会对 SSD 写入造成压力。

整理参数

一定要先备份自己系统当前的参数在修改，万一有问题方便回退。

# /etc/sysctl.d/99-performance.conf

# === 内存管理 ===
vm.swappiness = 10
vm.dirty_ratio = 20
vm.dirty_background_ratio = 5
# 可能还加 dirty_expire / writeback，根据具体测试调优
# vm.dirty_expire_centisecs = 500
# vm.dirty_writeback_centisecs = 100

# 可选：如果你知道内存不是特别紧张，可设置 overcommit
# vm.overcommit_memory = 1

# === 文件句柄限制 ===
fs.file-max = 2000000

# === 网络 / TCP 参数 ===
net.core.somaxconn = 8192  # 监听 backlog
net.core.netdev_max_backlog = 50000

# 接收 / 发送缓冲
net.core.rmem_default = 262144
net.core.wmem_default = 262144
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

net.ipv4.tcp_rmem = 4096   87380   16777216
net.ipv4.tcp_wmem = 4096   65536   16777216

# TIME_WAIT 和连接重用
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_tw_reuse = 1

# Keepalive
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 3

# 网络安全相关
kernel.sysrq = 0
net.ipv4.ip_forward = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.all.accept_source_route  =0
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.default.secure_redirects = 0
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.tcp_syncookies = 1
kernel.dmesg_restrict = 1
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0
kernel.threads-max = 655350

# === 其他网络 /系统选项 ===
# 可以根据需要打开更多，但这里是基础

应用这个配置

sysctl --system

参数说明

  • 上面 sysctl 设置中，vm.swappiness=10 是为了让系统尽量少用 swap。
  • Redis 的 maxmemory 设置 (12 GB) 是示例，根据 Redis 实例所在机器上同时运行的其他进程 +操作系统需求来决定。如果 Redis 是主要服务，可以设置得更高，但建议不要占用所有内存。
  • allkeys-lru 淘汰策略是业界常用策略，适合缓存 +热点数据混合类型场景。
  • lazyfree-lazy-eviction 等异步释放设置，可以减少 Redis 主线程因内存回收 (删除大对象) 的阻塞。
  • AOF 重写策略 (auto-aof-rewrite-percentage 和 min-size) 设置，能平衡磁盘写入和文件大小。
  • hz 参数 (心跳 /后台任务频率) 控制周期性后台任务 (如过期检查) 的频率。调高可以更快响应但会增加 CPU 开销。

注意事项

  • 过度调优风险：如果参数设置不当（如非常低的 swappiness 或非常高的 dirty_ratio），可能导致系统内存压力过大或频繁写盘。
  • SSD 写寿命：调高内存中的 “脏页” 写回策略会增加写量，需要权衡。
  • 系统稳定性：部分调优 (如 CPU governor 改为 performance) 会增加功耗和温度，需要监控硬件状态。
  • 版本兼容性：不同内核版本 (RHEL / Rocky) 对某些内核参数的默认值或支持可能不一样，调优前要确认。
  • 监控覆盖盲点：调优后必须有监控和报警机制，以便及时发现调优带来的副作用。

Redis 应用参数调优建议

调优方案

  • 集群模式：Redis Cluster
  • 节点：6 节点 —— 3 主 + 3 从
  • 每节点资源：16 GB 内存，8 核 CPU
  • 业务特性：混合读写，读略多于写；有较大的缓存空间需求；容许偶尔 key 淘汰（cache 模式）
  • 持久化需求：需要 AOF + RDB 混合以兼顾数据持久性和恢复速度

具体配置建议

下面是建议写入 redis.conf

配置建议值 / 设置说明与理由
maxmemory大约 48 GB（64 GB 节点的 ~75%）留出一部分给操作系统 + fork 过程中的开销。
maxmemory-policyallkeys-lru选择 LRU 淘汰策略，以便在满内存时清除最少使用的 key。
maxmemory-samples5控制 LRU 近似采样的样本数，默认是 5，通常够用。
lazyfree-lazy-evictionyes使用后台异步释放内存（异步删除），减少主线程停顿。
lazyfree-lazy-expireyes异步过期 key 的内存释放。
appendonlyyes启用 AOF。保证持久性。
appendfsynceverysec每秒 fsync，一般来说在可靠性与性能之间是一个比较好的折中。
auto-aof-rewrite-percentage100当 AOF 大小增长到 100%（翻倍）时触发重写。这个值可根据实际 AOF 增长速度调整。
auto-aof-rewrite-min-size64mb最小 AOF 重写大小限制（避免过小文件频繁重写）
aof-load-truncatedyes启动时如果 AOF 被截断，可以继续加载（更健壮）。 ([codingnote.cc][3])
lua-time-limit5000（ms）限制 Lua 脚本最大执行时间，防止长脚本阻塞。
集群相关
cluster-enabledyes开启集群。
cluster-config-filenodes.conf（具体路径根据部署）保存集群节点配置。
cluster-node-timeout15000（ms）节点互连超时阈值，较常用值。
cluster-replica-validity-factor10（默认或视情况设）决定从节点是否有资格做 failover（与 node-timeout 和 ping 周期有关）。
cluster-migration-barrier1控制当主节点只有一个从节点时，从节点是否可以迁移到其他主上。
cluster-require-full-coverageno即使某些 slot 没覆盖，也允许读写，提升容错性。
网络 & 性能
timeout3000（秒或 ms，根据版本）客户端连接超时设置（视具体版本配置）
tcp-keepalive60保持空闲连接，避免连接过早关闭。
慢日志slowlog-log-slower-than比如 10000（微秒或微秒级，视版本）记录慢命令，有助于调优。
slowlog-max-len128保存慢日志条数上限。
数据结构内存优化
hash-max-ziplist-entries / hash-max-ziplist-value512 / 64（示例）对小 hash 使用 ziplist 编码节省内存。类似配置常见于实践。 ([CNDBA][4])
list-max-ziplist-entries / list-max-ziplist-value512 / 64同上，对 list 优化。
客户端 & 连接
使用连接池是建议客户端使用连接池（如 JedisPool、Lettuce 等），避免频繁建立连接。
使用 Pipeline（批量命令）是减少往返开销。
命令建模
避免 KEYS *使用 SCANKEYS 是阻塞命令，在大数据量下严重影响性能。
优化 Lua 脚本简短、快速防止脚本阻塞主线程，特别是在集群中。

Redis 配置整理

########################################
# Redis 性能 +集群 配置示例
# 这个配置文件只做参考 不能直接拿来用 Redis 是不允许再参数后买你添加注释的直接使用会报错
########################################

# 内存管理
maxmemory 12gb           # 假设节点内存 16G，为 Redis 留约 12G
maxmemory-policy allkeys-lru   # 使用 LRU 淘汰所有键（适合缓存 + 数据混合场景）
maxmemory-samples 5

# 延迟释放
lazyfree-lazy-eviction yes
lazyfree-lazy-expire yes
lazyfree-lazy-server-del yes

# 持久化 (RDB + AOF)
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-load-truncated yes

# RDB 快照 (可根据需要)
save 900 1
save 300 10
save 60 10000

# 集群配置 (如果是 Redis Cluster)
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 15000
cluster-replica-validity-factor 10
cluster-migration-barrier 1
cluster-require-full-coverage no

# 性能 /调度相关
hz 10
dynamic-hz yes

# Lua 脚本执行限制
lua-time-limit 5000  # 毫秒

# 慢日志 (监控慢命令)
slowlog-log-slower-than 10000   # 微秒 (10 ms) — 根据业务调整
slowlog-max-len 128

# 内存碎片 / 编码优化
hash-max-ziplist-entries 512
hash-max-ziplist-value 64

list-max-ziplist-entries 512
list-max-ziplist-value 64

zset-max-ziplist-entries 128
zset-max-ziplist-value 64

# 安全性 (可选，根据场景启用)
# requirepass yourpassword
# rename-command FLUSHALL ""

# 其他 (可选，根据需求)
notify-keyspace-events ""

注意事项

  • fork 延迟风险：RDB 快照或 AOF 重写时会 fork，如果数据量很大，fork 可能占用大量内存 + 导致延迟波动。
  • 内存碎片：频繁删除 / 写入大对象可能导致内存碎片化。要监控 used_memory_rss vs used_memory。
  • AOF 重写失败：如果磁盘 I/O 不够快，重写可能失败或耗时过长。
  • 误配置淘汰策略：如果设置不当（例如 noeviction），可能写入失败（OOM），或策略太激进导致重要数据被淘汰。
  • 客户端不 cluster-aware：如果客户端不是集群感知 (cluster-aware)，可能频繁 MOVED 重定向，影响性能。
  • 监控盲点：如果没有全面监控，可能看不出调优的负面影响（如重写延迟、failover 异常、内存碎片）。

Redis 备份

优先备份主节点

  • 只对主节点 (master) 做快照 /持久化备份，因为副本 (replica) 节点上只是复制，备份主节点就可以恢复完整数据。

使用 RDB (快照) + AOF 组合

  • RDB 用于周期性冷备 (point-in-time snapshot)。
  • AOF 用于更高的数据持久性 (命令日志)，减少数据丢失窗口。
  • 混合使用可以兼顾恢复速度 (RDB) 和数据完整性 (AOF)

定期触发 BGREWRITEAOF 与 BGSAVE

  • 对 AOF 做重写 (rewrite)，防止日志无限增长。
  • 对 RDB 做快照 (BGSAVE)，用于冷备

备份文件长期保留与版本管理

  • 将 RDB/AOF 备份文件复制 /归档到异地存储 (如 NAS、对象存储)。
  • 为备份文件打时间戳 /版本，方便恢复时回滚。

校验与恢复演练

  • 使用 redis-check-aof / redis-check-rdb 工具校验备份文件健康性
  • 定期做恢复演练 (集群恢复、单节点恢复) 以验证备份策略有效。

操作方法

获取主节点列表

获取所有主节点

/usr/local/redis/bin/redis-cli -h 192.168.1.11 -p 6379 -a ugwFsSNuzgS4e62e CLUSTER NODES|grep master | grep -v "fail" | awk '{print $2}' | cut -d@ -f1

这条命令会列出所有 master 节点的

备份所有主节点 RDB和AOF

注意：此脚本需要现在测试环境中测试没问题 再拿到生产环境中使用。

#!/bin/bash
REDIS_IP="192.168.1.11"         # 任意一个集群节点（用于获取节点列表）
REDIS_PORT="6379"
REDIS_PWD="ugwFsSNuzgS4e62e"
BACKUP_DIR="/root/backup/"
TIMEOUT=300  

mkdir -p "$BACKUP_DIR" || { echo "ERROR: 无法创建备份目录 $BACKUP_DIR"; exit 1; }
# 获取所有 master 节点
nodes=$(redis-cli -c -h "$REDIS_IP" -p "$REDIS_PORT" -a "$REDIS_PWD" CLUSTER NODES | \
  grep master | grep -v fail | awk '{print $2}' | cut -d@ -f1)

for node in $nodes; do
  ip=$(echo "$node" | cut -d: -f1)
  port=$(echo "$node" | cut -d: -f2)
  echo "=== 开始备份：Redis 节点 $ip:$port ==="

  # 触发 BGSAVE (RDB)
  redis-cli -h "$ip" -p "$port" -a "$REDIS_PWD" BGSAVE
  if [ $? -ne 0 ]; then
    echo "WARNING: BGSAVE 在 $ip:$port 执行失败"
  fi

  # 等待 BGSAVE 完成
  start_time=$(date +%s)
  while true; do
    inprog=$(redis-cli -h "$ip" -p "$port" -a "$REDIS_PWD" INFO persistence | \
      grep rdb_bgsave_in_progress | cut -d: -f2 | tr -d '\r')
    if [ "$inprog" = "0" ]; then
      echo "BGSAVE 完成：$ip:$port"
      break
    fi
    now=$(date +%s)
    elapsed=$(( now - start_time ))
    if [ $elapsed -gt $TIMEOUT ]; then
      echo "ERROR: BGSAVE 超时 ($elapsed 秒) 在 $ip:$port" >&2
      break
    fi
    echo "等待 BGSAVE 完成 ($elapsed 秒) ..."
    sleep 5
  done

  # 获取 RDB 文件路径
  DIR=$(redis-cli -h "$ip" -p "$port" -a "$REDIS_PWD" CONFIG GET dir | awk 'NR==2')
  DBFILE=$(redis-cli -h "$ip" -p "$port" -a "$REDIS_PWD" CONFIG GET dbfilename | awk 'NR==2')
  src_rdb="${DIR}/${DBFILE}"
  if [ ! -f "$src_rdb" ]; then
    echo "ERROR: 未找到 RDB 文件: $src_rdb" >&2
  else
    dst_rdb="${BACKUP_DIR}/${ip}_${port}_$(date +%Y%m%d_%H%M%S).rdb"
    cp "$src_rdb" "$dst_rdb" && echo "RDB 备份保存到 $dst_rdb"
  fi
  
  aof_enabled=$(redis-cli -h "$ip" -p "$port" -a "$REDIS_PWD" CONFIG GET appendonly | awk 'NR==2')
  if [ "$aof_enabled" = "yes" ]; then
    AOFDIR=$(redis-cli -h "$ip" -p "$port" -a "$REDIS_PWD" CONFIG GET appenddirname | awk 'NR==2')
    AOFNAME=$(redis-cli -h "$ip" -p "$port" -a "$REDIS_PWD" CONFIG GET appendfilename | awk 'NR==2')

    if [ -z "$AOFDIR" ]; then
      src_aof="${DIR}/${AOFNAME}"
      if [ -f "$src_aof" ]; then
        dst_aof="${BACKUP_DIR}/${ip}_${port}_$(date +%Y%m%d_%H%M%S).aof"
        cp "$src_aof" "$dst_aof" && echo "AOF 备份保存到 $dst_aof"
      else
        echo "ERROR: AOF 文件未找到: $src_aof" >&2
      fi
    else
      # Multi-Part AOF 模式 (Redis 7+)
      aof_dir_full="${DIR}/${AOFDIR}"
      if [ -d "$aof_dir_full" ]; then
        dst_mp_dir="${BACKUP_DIR}/${ip}_${port}_AOF_$(date +%Y%m%d_%H%M%S)"
        mkdir -p "$dst_mp_dir"
        cp "${aof_dir_full}"/* "$dst_mp_dir"/ && echo "MP-AOF 备份到 $dst_mp_dir"
      else
        echo "ERROR: AOF 目录不存在: $aof_dir_full" >&2
      fi
    fi
  else
    echo "AOF 未启用在 $ip:$port，跳过 AOF 备份"
  fi

done

echo "=== 所有节点备份完成 ==="

Redis 集群恢复 (恢复 / 回滚) 操作命令

单节点恢复

  1. 停止要恢复的节点
# 或者停止对应的 Redis 服务 / systemd 单元
redis-cli -h <ip> -p <port> SHUTDOWN
  1. 将备份文件 (RDB / AOF) 放回该节点的数据目录
cp /backup/redis/cluster/<ip>_<port>_YYYYMMDD_HHMMSS.rdb /var/lib/redis/$port/dump.rdb
# 如果是 aof
cp /backup/redis/cluster/<ip>_<port>_YYYYMMDD_HHMMSS.aof /var/lib/redis/$port/appendonly.aof
  1. 设置正确权限
    确保文件所有者和权限与 Redis 进程一致，比如：
chown redis:redis /var/lib/redis/$port/dump.rdb
chown redis:redis /var/lib/redis/$port/appendonly.aof

  1. 启动 Redis 节点
    启动 Redis，查看日志确认是否加载了 RDB / AOF。

    • 如果优先加载 AOF：在 redis.conf 中 appendonly yes，那么 Redis 启动时会优先用 AOF 恢复
    • 如果你先还原 RDB，再开 AOF，可以临时关闭 AOF，加载 RDB 后再打开

具体命令 (如果是 systemd)：

systemctl start redis
  1. （可选）触发 BGREWRITEAOF
redis-cli -h <ip> -p <port> BGREWRITEAOF

集群级恢复 /重新加入集群

恢复一个节点之后，如果这个节点之前属于集群 (有 slot)，你需要让它重新加入 (如果它是孤立恢复)：

  1. 与集群中的一个存活节点做 CLUSTER MEET
redis-cli -h <恢复节点 IP> -p <恢复节点 端口> CLUSTER MEET <任意健康节点 IP> <端口>
  1. 确认节点状态
    在恢复节点上运行：
redis-cli -h <恢复节点 IP> -p <恢复端口> CLUSTER NODES

看它是否成为了集群的一员 (节点状态应该是 slave 或 master 等)。

  1. 如果恢复的是主节点，并且有 slot，需要重新分配 slot

    • 如果是原来的 master，要把 slot 分回去 (如果 slot 被迁移了)。
    • 使用 redis-cli --cluster reshard 进行 slot 重分布 (reshard)：将部分 slot 从其他节点迁移给该节点。
redis-cli --cluster reshard <一个集群节点 IP:端口> --from <其他节点列表，用逗号分隔> --to <恢复节点 id> --slots <slot 数量> --yes

注意事项

  • 恢复时间：如果集群节点很多、数据量大，恢复 (尤其是 AOF 重写) 可能比较慢。
  • 数据一致性：如果只是用 RDB 快照恢复，可能丢失最后一次快照后的写入。AOF 可以减少但也不能保证零丢失 (取决于 appendfsync 策略)。
  • 重写 (rewrite) 期间性能影响：AOF 重写是 fork 子进程，会占用内存和 CPU。
  • 磁盘空间：备份 RDB + AOF 文件可能占用大量磁盘空间，备份存储要规划好。
  • 安全：备份文件 (RDB / AOF) 本身也很敏感，应保证备份存储路径权限、安全传输 (如 SFTP、对象存储加密)。
Redis 由浅入深 (7) - redis集群操作手册
yh4494的博客
03-04 1321
常见的redis集群操作命令总结，以及一些常见的运维命令。
深入Redis集群模式-分布式缓存架构
weixin_45198482的博客
08-02 1116
深入Redis集群模式-分布式缓存架构
Redis 集群
2503_91100205的博客
06-09 3255
在当今互联网高并发、海量数据的场景下，单机 Redis 已无法满足系统对性能、存储和高可用性的需求。Redis 集群作为分布式缓存的终极解决方案，通过巧妙的架构设计实现了数据分片、自动故障转移和动态扩容。本文将从原理出发，深入剖析 Redis 集群的核心机制，并通过完整的实战部署流程，带您掌握这一强大的分布式技术。Redis Cluster 通过哈希槽分片与自动故障转移，完美解决了单机 Redis 的三大痛点：存储限制、写操作瓶颈和手动运维成本。高并发读写：电商秒杀、社交平台 feed 流海量数据存储。
如何完成redis集群部署及性能优化？
梦在硅谷的博客
10-30 1412
Redis集群是一种分布式架构，允许将数据分散存储在多个Redis节点上。数据分片：Redis集群通过哈希槽将数据分散到不同的节点上，每个节点负责一定范围的哈希槽。高可用性：通过主从复制和故障转移机制，Redis集群能够在节点故障时保持服务的可用性。无中心化：Redis集群不依赖于中央管理节点，所有节点都是平等的。Redis集群模式的部署和性能提升是一个复杂而系统的过程。通过合理的架构设计、数据结构选择、持久化策略和监控调优，可以显著提升Redis的性能，满足高并发和大数据量的需求。
Redis集群
YUNYINGXIA的博客
06-09 2115
Redis 提供了三种主要的集群模式：主从模式、哨兵模式和 Cluster 模式。三种模式的发展与 Redis 版本密切相关，解决了不同阶段的分布式需求。模式支持版本核心特性优缺点对比主从模式Redis 2.8 前数据多机备份、读写分离优点：实现简单，解决数据备份；缺点：故障需人工处理，无法动态扩容，写操作无法负载均衡哨兵模式Redis 2.8+基于主从的自动化故障恢复优点：自动故障转移；缺点：从节点故障需额外监控，存储受限于单机，不支持动态扩容Cluster 模式Redis 3.0+
Redis集群模式学习
LeonNo11的博客
04-12 792
主从复制适合简单场景，解决读扩展和备份问题。哨兵模式增加了高可用，适合对自动化故障转移有需求的场景。解决了数据量和扩展性问题，适合大规模分布式场景。每种模式的背后都是对性能、可用性和复杂性的权衡。分片解决存储瓶颈。复制保证数据冗余。故障转移保障服务可用。部署一个小型 Redis Cluster，观察槽分配和数据迁移。模拟节点故障，验证故障转移行为。使用客户端 SDK（如 Jedis）测试跨槽操作的限制。如果有具体问题（例如某个模式的配置或优化），可以进一步探讨！分片。
Redis 集群方式
qq_51678989的博客
08-12 5336
集群，即 Redis cluster， 是 Redis 3.0开始引入的分布式存储方案。集群由多个节点(Node)组成，Redis 的数据分布在这些节点中。集群中的节点分为主节点和从节点;只有主节点负责读写请求和集群信息的维护;从节点只进行主节点数据和状态信息的复制。
Redis 哨兵模式、集群模式
阳光大男孩！！！的博客
06-02 9363
前言 Redis 哨兵模式主要是为Redis主从同步架构服务的，有时候主节点宕机，需要哨兵进行监控、通知，选举。 哨兵是干什么用的？ sentinel，中文名是哨兵。哨兵是 redis 集群机构中非常重要的一个组件，主要有以下功能： 集群监控：负责监控 redis master 和 slave 进程是否正常工作。 消息通知：如果某个 redis 实例有故障，那么哨兵负责发送消息作为报警通知给管理员。 故障转移：如果 master node 挂掉了，会自动转移到 slave node 上。 配置中心：如果
Redis三种集群模式：主从模式、哨兵模式和Cluster模式
09-01 3531
redis主从：可实现高并发(读)，典型部署方案：一主二从redis哨兵：可实现高可用，典型部署方案：一主二从三哨兵redis集群：可同时支持高可用(读与写)、高并发，典型部署方案：三主三从。
白话解析Redis Cluster集群模式
没事学AI的博客
08-19 1316
摘要：Redis Cluster是Redis官方推出的分布式集群解决方案，通过数据分片（16384个槽位）、主从复制和自动故障转移等机制，解决单节点Redis的存储、性能和单点故障问题。本文深入解析Redis Cluster的架构设计、数据分片原理、高可用机制及实战部署，包括槽位分配策略、主从复制流程、故障检测与转移等核心功能，并提供节点配置、扩容迁移等操作示例，帮助开发者掌握大规模高并发场景下的Redis集群技术。
Redis集群部署详解：主从复制、Sentinel哨兵模式与Cluster集群的工作原理与配置
niaonao
01-13 2135
主从复制、哨ientinel哨兵模式与Cluster集群的工作原理与配置
Redis集群：概念和部署示例
变成我......
08-14 1316
讲解了Redis部署集群的3种模式、数据分片、故障转移的相关概念，还有集群部署的示例步骤
PlumeLog 和 Redis 集群：日志管理的梦幻组合
横竖撇折点
04-27 882
想象一下，你正在开发一款应用，每天生成海量的日志数据。如何高效地收集、存储和查询这些日志信息？PlumeLog 加上 Redis 集群就像是为这个问题量身定制的魔法药水。它们联手为你提供了一种既快速又可靠的解决方案。下面，我们就来揭开这组搭档背后的秘密。
redis 集群三种模式以及安装部署
qq_35479765的博客
08-09 2958
文章目录一、redis 集群三种模式简介二、redis 集群三种模式原理2.1 主从复制2.2 哨兵模式2.3 cluster 集群模式三、redis 三种模式的搭建 一、redis 集群三种模式简介 模式一：主从复制，是redis高可用的基础，实现了数据的多机备份，以及对于读操作的负载均衡和简单的故障恢复。 缺陷:故障恢复无法自动化、写操作无法负载均衡、存储能力受到单机的限制。 模式二：哨兵模式，基于主从复制模式，实现了自动化的故障恢复 缺陷：写操作无法负载均衡、存储能力受到单机的限制。 模式三：clus
缓存击穿、雪崩、穿透三大Redis问题总结
akiramenai的博客
11-19 731
当缓存和数据库都没有查询到请求时，就往缓存中存入null，并且设置ttl。热点key一般都会提前写入缓存，所以不用担心缓存穿透的问题。
Celery+fastapi+redis做多任务AI模拟角色进行文件对话
Aainm的博客
11-20 432
本篇章节适用于多任务的服务器模拟操作，通过使用fastapi和celery框架实现分布式请求，关于ai模拟操作则是通过设定AI角色样式来进行模拟真人进行内容的回答。本篇章只会涉及到两个模型，都是国内模型。全模态模型：qwen3-omin-flash聊天模型:qwen3-max可以的话先去申请相关的api-key来获取模型请求，防止项目无法操作。
redis BitMap 用户签到功能实现
m0_53881899的博客
11-20 105
redis BitMap 用户签到功能实现
Redis如何设置密码
最新发布
2509_94006941的博客
11-20 914
为什么redis要设置密码？内网环境可以不设置密码，但是个人服务器，以及线上公网服务器就有必要设置密码了。昨天我查看了一下minio的redis事件通知，查看redis的key时发现多了几个奇怪的key。然后我猜想应该是挖矿病毒。如下面所示：这样就将定时任务和脚本注入到了我们机器当中，就会开始执行 init.sh 脚本backup1 "backup2 "backup3 "backup4 "公网的redis一定要设置密码阿，不要不设置密码，设置密码就一个指令，非常容易，可不要偷懒噢。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值