Guides Platform

Appearance

Docker 部署 Redis：持久化、性能调优与高可用拓扑 ​

Redis 是内存优先的数据结构服务器，常见用途包括缓存、会话、队列、排行榜和限流。Redis 的低延迟来自内存数据结构与事件循环；持久化、复制、故障转移和分片会改变资源消耗与客户端行为，不能只把 redis-server 放进容器就当成高可用部署。

本文使用 Redis 8.10.2 官方镜像和 Docker Compose，先完成一套单节点、带密码和持久化的长期运行基线，再根据业务目标选择 Sentinel 或 Cluster。单节点路径适合同一台主机上的应用和开发环境；Sentinel 提供主从自动切换但不分片；Cluster 提供分片和节点级故障转移，但要求应用使用 Cluster-aware 客户端。

Redis 8 的大版本升级需要单独进行兼容性验证。升级前要保留可恢复的 RDB/AOF、当前配置和客户端版本，先在隔离环境导入数据，再按拓扑逐节点升级。不要把 Redis 大版本升级、数据迁移和拓扑改造放在同一次变更中。

部署结论 ​

项目本文采用的值
项目地址redis/redis
官方镜像redis:8.10.2-bookworm
项目版本Redis 8.10.2
主部署方法官方镜像 Docker Compose 单节点持久化
备选方法Sentinel 主从故障转移，或 Cluster 分片与节点故障转移
适用范围单机长期运行基线；跨主机高可用需要独立故障域
主机架构linux/amd64、linux/arm64（以目标 tag 的 manifest 为准）
最低资源官方未给出统一最低值；按数据集、并发和持久化开销压测
对外端口默认 127.0.0.1:6379:6379，不直接暴露公网
持久化位置redis_data:/data，备份文件写入宿主机 backups/
依赖服务无；Sentinel 和 Cluster 需要额外 Redis 节点
部署日期2026-09-28

单节点 Compose 是本文唯一完整展开的主路径，因为单节点路径能先把版本、认证、持久化、验收和升级边界闭合。Sentinel 与 Cluster 的配置示例放在后文，用来做拓扑决策和扩展实施；两种拓扑都需要多个独立故障域、客户端改造和真实故障演练，不能通过增加几个 Compose service 就自动获得生产级高可用。

架构说明 ​

Mermaid 流程图
查看源码
flowchart LR
  App[应用或 redis-cli] -->|127.0.0.1:6379| Redis[Redis 8.10.2]
  Redis -->|RDB/AOF| Volume[(redis_data:/data)]
  Redis -.->|备份导出| Backup[宿主机 backups/]
  Sentinel[3 个 Sentinel] -.->|主从探测与故障转移| RedisHA[Redis 主节点与副本]
  Cluster[Cluster 节点] -.->|16384 hash slots| ClusterNodes[分片与副本]

单节点实例只负责数据服务和本地持久化，应用不应该依赖容器 IP。Compose 网络内使用服务名 redis，宿主机客户端使用绑定的回环地址；跨主机客户端应通过受控内网或代理访问，而不是把 6379 直接暴露到公网。

Sentinel 是控制面和服务发现层。三个 Sentinel 需要分布在相互独立的主机或虚拟机中，客户端连接 Sentinel 并查询名为 mymaster 的当前主节点。Sentinel 的 quorum 只用于判断主节点是否失联，真正的 failover 还需要 Sentinel 多数派；异步复制意味着故障切换可能丢失最近尚未复制或尚未落盘的写入。

Cluster 把 16384 个 hash slot 分配到多个 master，replica 负责副本和故障转移。Cluster 客户端必须处理 MOVED、ASK 和重定向；多 key 操作只有在 key 使用相同 hash tag（例如 {user:42}:profile 和 {user:42}:orders）时才会落在同一个 slot。Cluster bus 默认是数据端口加 10000，例如 6379 对应 16379，客户端不应连接 cluster bus 端口。

前置条件 ​

主路径需要 Docker Engine 或 Docker Desktop、Compose v2、一个未被占用的宿主机端口，以及能保存 Redis 数据和备份的磁盘。Linux 主机建议先检查内核内存策略和透明大页状态；不要在没有评估其他服务的情况下直接修改全局 sysctl。

bash
docker --version
docker compose version
sysctl vm.overcommit_memory 2>/dev/null || true
cat /sys/kernel/mm/transparent_hugepage/enabled 2>/dev/null || true

如果 Redis 与应用不在同一台主机，先确定内网地址、访问控制、TLS 或受信任的反向代理方案。Redis 的管理端口、Sentinel 端口 26379、Cluster 数据端口和 cluster bus 端口都必须只对需要的网络开放。

Docker Compose 正式部署 ​

准备目录和密码 ​

下面的目录只作为示例。生产主机应选择专用磁盘，并限制工作目录和备份目录的访问权限。

bash
sudo mkdir -p /opt/redis/backups
sudo chown -R "$USER":"$USER" /opt/redis
cd /opt/redis
umask 077

REDIS_PASSWORD="$(openssl rand -hex 32)"
cat > .env <<EOF
REDIS_IMAGE=redis:8.10.2-bookworm
REDIS_PASSWORD=${REDIS_PASSWORD}
REDIS_HOST_PORT=6379
REDIS_MAXMEMORY=2gb
REDIS_MAXMEMORY_POLICY=noeviction
REDIS_IO_THREADS=1
EOF
chmod 600 .env
unset REDIS_PASSWORD

.env 由 Compose 用于变量展开和容器环境。文件权限应保持为 600，不要把真实 .env 提交到 Git、粘贴到工单或写入镜像层。这里使用 noeviction 保护 Redis 作为数据存储的写入语义；如果 Redis 只保存可重建缓存，应在压测和业务确认后改用 allkeys-lfu 或其他合适的淘汰策略。

写入 Compose 配置 ​

创建 compose.yaml：

yaml
services:
  redis:
    image: ${REDIS_IMAGE:?REDIS_IMAGE is required}
    restart: unless-stopped
    command:
      - redis-server
      - --appendonly
      - "yes"
      - --appendfsync
      - everysec
      - --save
      - "900 1"
      - --save
      - "300 10"
      - --maxmemory
      - ${REDIS_MAXMEMORY:-2gb}
      - --maxmemory-policy
      - ${REDIS_MAXMEMORY_POLICY:-noeviction}
      - --requirepass
      - ${REDIS_PASSWORD:?REDIS_PASSWORD is required}
      - --masterauth
      - ${REDIS_PASSWORD:?REDIS_PASSWORD is required}
      - --protected-mode
      - "yes"
      - --tcp-keepalive
      - "300"
      - --io-threads
      - ${REDIS_IO_THREADS:-1}
    environment:
      REDIS_PASSWORD: ${REDIS_PASSWORD:?REDIS_PASSWORD is required}
    ports:
      - "127.0.0.1:${REDIS_HOST_PORT:-6379}:6379"
    volumes:
      - redis_data:/data
    healthcheck:
      test:
        - CMD-SHELL
        - redis-cli --no-auth-warning -a "$${REDIS_PASSWORD}" ping | grep -q PONG
      interval: 10s
      timeout: 5s
      retries: 6
      start_period: 10s
    stop_grace_period: 30s

volumes:
  redis_data:

这份配置同时启用 RDB 快照和 AOF。appendfsync everysec 通常在吞吐、延迟和崩溃后的数据窗口之间取得平衡，但不能承诺零数据丢失；对可重建缓存可以降低持久化强度，对不可替代数据则应配合业务级导出和异地备份。--masterauth 在单节点上暂时没有作用，但保留该参数可以让同一份配置扩展为副本节点时不忘记复制认证。

命令行参数会出现在 Compose 渲染结果和容器检查信息中。更高安全等级的环境应使用受控 Secret 或在容器启动前生成权限为 600 的 Redis 配置文件，并限制能读取 Docker API 的用户；无论采用哪种方式，都不能把密码写进 Git。

检查配置并启动 ​

先检查变量展开和 Compose 结构，再启动服务：

bash
docker compose --env-file .env config --quiet
docker compose --env-file .env config --images
docker compose --env-file .env up -d
docker compose --env-file .env ps

config --quiet 返回状态码 0 表示 Compose 配置能够解析；config --images 应只列出 redis:8.10.2-bookworm。启动后，docker compose ps 中 Redis 应为 healthy，如果持续 restarting，先查看有限日志，不要立即删除数据卷：

bash
docker compose --env-file .env logs --tail=120 redis

验证部署结果 ​

在执行下面的验证命令前，从当前目录的 .env 临时加载 Compose 变量。set -a 只负责让变量对子进程可见，命令不会主动打印密码；验证结束后可以执行 unset REDIS_PASSWORD 清理当前 Shell。

bash
cd /opt/redis
set -a
. ./.env
set +a

配置层 ​

bash
docker compose --env-file .env config --quiet
docker compose --env-file .env exec -T redis redis-cli --no-auth-warning -a "$REDIS_PASSWORD" INFO server | sed -n '1,12p'

如果当前 Shell 没有 REDIS_PASSWORD，从 .env 读取时不要把值打印到终端或命令历史；可以直接进入容器执行受控的 redis-cli 检查。配置层需要确认镜像 tag、密码变量、卷和回环端口都来自预期文件。

进程层和协议层 ​

bash
docker compose --env-file .env ps
docker compose --env-file .env exec -T redis redis-cli --no-auth-warning -a "$REDIS_PASSWORD" PING
docker compose --env-file .env exec -T redis redis-cli --no-auth-warning -a "$REDIS_PASSWORD" ROLE

成功信号是 PONG、Redis 服务状态为 healthy，以及 ROLE 报告 master。如果使用宿主机客户端，应通过回环端口连接并显式提供密码；不要为了方便把 6379 绑定到 0.0.0.0。

数据层和重建验收 ​

用临时 key 验证写入、读取和容器重建：

bash
docker compose --env-file .env exec -T redis \
  redis-cli --no-auth-warning -a "$REDIS_PASSWORD" SET deployment-check "$(date -u +%FT%TZ)" EX 3600
docker compose --env-file .env exec -T redis \
  redis-cli --no-auth-warning -a "$REDIS_PASSWORD" GET deployment-check
docker compose --env-file .env up -d --force-recreate redis
docker compose --env-file .env exec -T redis \
  redis-cli --no-auth-warning -a "$REDIS_PASSWORD" GET deployment-check

重建后仍能读取临时 key，说明当前容器复用的是 redis_data 卷。这个检查只证明卷挂载与基础读写，不证明 RDB/AOF 在断电、磁盘损坏、跨主机迁移或大版本升级时可恢复。

性能配置与使用 ​

内存和淘汰策略 ​

maxmemory 应低于主机可用内存，为 Redis fork、AOF 重写、RDB 快照、内核页缓存和其他容器保留余量。不要把容器限制值直接当成 Redis 可用内存；先测量峰值数据集、复制缓冲和重写峰值，再设置 REDIS_MAXMEMORY。

淘汰策略取决于数据能否重建：

场景建议方向重要边界
订单、锁状态、任务状态等不可随意丢失的数据noeviction内存不足时写入失败，调用方必须处理错误并扩容
纯缓存allkeys-lfu 或按 key 过期策略选择被淘汰的数据必须能够从源系统重建
只给带 TTL 的缓存设置淘汰volatile-lru、volatile-ttl 等没有 TTL 的 key 可能持续占满内存

使用 INFO memory、MEMORY USAGE 和业务指标观察内存增长；不要仅根据 used_memory 判断是否可以把上限调到接近容器限制。

请求和命令路径 ​

  • 批量读写优先使用 pipeline、MGET、MSET 或合适的集合命令，减少网络往返。
  • 线上排障不要使用 KEYS *；用 SCAN 分批遍历，并限制每批数量。
  • 大 value、无界 list、频繁 HGETALL 和同步执行的 Lua 脚本都会放大单线程事件循环的阻塞时间。
  • 使用 SLOWLOG GET、LATENCY DOCTOR、INFO commandstats 和客户端延迟指标定位瓶颈；redis-benchmark 只能代表合成负载，不能替代业务压测。

I/O 线程和宿主机 ​

Redis 的命令执行仍受单线程数据结构语义约束。io-threads 只并行化部分网络读写，线程数越多不一定越快；本文默认 REDIS_IO_THREADS=1，只有在真实连接数和 pipeline 负载下压测确认有收益后再调整，并比较 P95/P99 延迟和 CPU 消耗。

高并发主机还应观察透明大页、vm.overcommit_memory、文件描述符、网络 backlog、容器 CPU 限制和磁盘 fsync 延迟。宿主机调优必须以当前系统基线为准，不能把一组 sysctl 命令复制到所有 Linux 发行版。

数据与恢复边界 ​

单节点 Redis 的恢复单元包括 redis_data 卷中的 RDB/AOF、Compose 文件、.env 中的密码和内存策略，以及任何业务侧的 key 命名和过期约定。RDB/AOF 只覆盖 Redis 数据，不会替代应用数据库、密钥管理或业务级导出。

Redis 数据写入期间直接复制 /data 目录可能得到不一致的文件。优先使用 Redis 生成的 RDB/AOF 快照或在短暂停写后复制，再把备份放到宿主机 backups/ 或外部对象存储；恢复后必须执行 PING、关键 key 读取和应用业务验收。标准卷和绑定目录的归档命令见 Docker 数据备份与恢复教程。

恢复时不要把备份文件直接覆盖正在运行的 /data：

  1. 停止写入 Redis 的应用，记录当前镜像和配置；
  2. 停止 Redis 容器并保留原卷，创建隔离恢复卷；
  3. 将选定的 RDB/AOF 恢复到恢复卷，检查文件属主和权限；
  4. 用同一 Redis 大版本在隔离端口启动，执行 PING、关键 key 和 TTL 检查；
  5. 应用完成读写验收后，再切换正式卷或服务入口。

如果只保存可重建缓存，可以接受清空 Redis 后冷启动；如果 Redis 保存会话、队列、锁或业务状态，必须把恢复演练和重复消费、锁丢失、过期时间变化纳入验收。

Redis 大版本升级 ​

升级前决策 ​

Redis 8.10.2 不是可以随意替换的字符串。大版本可能改变默认配置、命令行为、持久化实现、模块接口或客户端兼容性；具体变更以 Redis 8.10.2 Release 和官方升级资料为准。升级前固定以下清单：

  • 当前镜像 tag、配置文件和 Compose 渲染结果；
  • RDB/AOF 备份及其校验值；
  • 客户端库版本、连接方式和是否支持 Sentinel/Cluster；
  • 关键命令、Lua/Functions、模块和过期策略；
  • 数据集大小、AOF 重写时间、RDB 加载时间和恢复目标；
  • 旧版本回滚镜像与回滚后业务验收步骤。

单节点升级 ​

先在隔离目录用目标镜像导入备份，跑完协议、关键 key、TTL 和性能回归，再处理正式实例：

bash
cd /opt/redis
set -a
. ./.env
set +a
docker compose --env-file .env exec -T redis redis-cli --no-auth-warning -a "$REDIS_PASSWORD" BGSAVE
docker compose --env-file .env cp redis:/data/dump.rdb backups/pre-upgrade-dump.rdb
cp compose.yaml compose.yaml.before-redis-upgrade
sed -i 's/redis:8.10.2-bookworm/redis:目标版本-bookworm/' .env
docker compose --env-file .env config --quiet
docker compose --env-file .env pull redis
docker compose --env-file .env up -d redis
docker compose --env-file .env ps

目标版本-bookworm 只表示经过预发布验证的具体 tag，不能原样执行。升级后重新检查 PONG、INFO server、关键数据、TTL、AOF/RDB 状态和应用延迟。不要使用 latest，也不要在没有备份和恢复演练的情况下删除旧卷。

Sentinel 和 Cluster 升级边界 ​

Sentinel 拓扑应先升级副本并确认复制正常，再按维护窗口切换主节点，最后升级原主节点和 Sentinel；每个节点完成 INFO replication、客户端连接和故障转移检查后再继续。Cluster 拓扑要逐个节点执行兼容性检查，保持 slot 覆盖完整，先处理副本，再在受控窗口切换 master；每个阶段都要执行 redis-cli --cluster check 和业务读写验证。

如果目标版本需要不可逆数据迁移，优先新建隔离拓扑并使用逻辑导出/导入或官方迁移工具，保留旧拓扑直到业务验收完成。Redis 大版本升级失败时，回滚镜像并不等于回滚已经写入的新数据格式；必须依据目标版本兼容说明和已验证的备份恢复路径决定是否回退。

Sentinel 主从高可用 ​

什么时候选择 Sentinel ​

Sentinel 适合单主写入、读副本和自动故障转移，不提供数据分片。应用只需要一个逻辑主服务名，但客户端必须支持 Sentinel 协议；把应用固定连到某个 Redis IP 会绕过故障转移。

生产部署至少使用 3 个 Sentinel，并放在相互独立的主机或故障域。单台 Docker 主机上启动 3 个 Sentinel 只能演练进程故障，主机宕机仍会全部丢失；quorum 2 表示至少两个 Sentinel 认为主节点不可达，3 个 Sentinel 中仍需多数派才能授权 failover。

Sentinel 配置骨架 ​

每个 Redis 副本使用相同的认证、AOF/RDB 和网络策略，副本额外声明主节点：

conf
port 6379
bind 0.0.0.0
protected-mode yes
requirepass ${REDIS_PASSWORD}
masterauth ${REDIS_PASSWORD}
appendonly yes
appendfsync everysec
replicaof redis-master 6379

每个 Sentinel 使用自己的 sentinel.conf 和持久化目录。下面是模板，${REDIS_PASSWORD} 必须在生成最终文件时替换为受控 Secret，不能把这个模板直接当成 Redis 配置提交：

conf
port 26379
sentinel monitor mymaster redis-master 6379 2
sentinel auth-pass mymaster ${REDIS_PASSWORD}
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1

Sentinel 的 26379 端口需要让应用客户端和其他 Sentinel 互通；Redis 数据端口和副本端口只对应用、复制链路和运维网络开放。跨 NAT 或端口映射时必须显式配置 sentinel announce-ip、sentinel announce-port，否则 Sentinel 可能向客户端传播容器内部地址。

Sentinel 验收 ​

bash
redis-cli -h sentinel-1 -p 26379 SENTINEL get-master-addr-by-name mymaster
redis-cli -h sentinel-1 -p 26379 SENTINEL masters
redis-cli -h redis-master -a "$REDIS_PASSWORD" INFO replication

验收应确认三个 Sentinel 都能看到同一个 master、至少一个 replica 已连接、客户端使用 mymaster 而不是固定 IP。故障演练需要在维护窗口停止 master，观察 Sentinel 选主、复制恢复和应用重连；不要在没有备份和回滚计划的生产环境直接 kill 主节点。

Redis Cluster 分片高可用 ​

什么时候选择 Cluster ​

Cluster 适合数据量或吞吐已经超过单主实例，且应用能够使用 Cluster-aware 客户端的场景。生产基线通常是 3 个 master 加 3 个 replica；少于 3 个 master 无法形成完整的分片与副本冗余。Cluster 自带节点故障转移，不需要再为同一组 master 配置 Sentinel。

Cluster 的每个节点同时需要客户端数据端口和 cluster bus 端口。Redis 官方文档指出 Docker NAT 环境需要特别处理，最简单的生产路径通常是每个节点使用独立主机端口并让节点对其他节点公布可达的 cluster-announce-ip、cluster-announce-port 和 cluster-announce-bus-port；跨主机部署时优先使用直接可达的内网地址或 host networking。

节点配置骨架 ​

每个节点使用独立的 nodes.conf 和 /data 卷。下面以节点 7000 为例，其他节点替换端口和目录：

conf
port 7000
bind 0.0.0.0
protected-mode yes
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
cluster-announce-ip 192.0.2.10
cluster-announce-port 7000
cluster-announce-bus-port 17000
requirepass ${REDIS_PASSWORD}
masterauth ${REDIS_PASSWORD}
appendonly yes
appendfsync everysec

示例中的 192.0.2.10 是文档保留地址，正式配置必须替换为节点之间实际可达的内网地址。不要把 cluster bus 端口发布给公网，也不要把容器 IP 当成跨主机稳定地址。

六个节点启动后，用 redis-cli --cluster create 分配 slot 和 replica：

bash
redis-cli --cluster create \
  192.0.2.10:7000 192.0.2.10:7001 192.0.2.10:7002 \
  192.0.2.10:7003 192.0.2.10:7004 192.0.2.10:7005 \
  --cluster-replicas 1 \
  -a "$REDIS_PASSWORD"
redis-cli --cluster check 192.0.2.10:7000 -a "$REDIS_PASSWORD"
redis-cli -c -h 192.0.2.10 -p 7000 -a "$REDIS_PASSWORD" SET '{user:42}:profile' active

成功信号是 cluster check 报告所有 slot 覆盖、每个 master 有 replica，Cluster 客户端能够跟随 MOVED 重定向。故障演练时停止一个 master，确认 replica 被提升、slot 仍可访问，再检查应用连接池是否能刷新节点拓扑。Cluster 不能保证少数派分区继续安全写入；多数 master 失联、slot 覆盖不完整或节点公告地址不可达时，集群会拒绝部分请求。

日常运维 ​

bash
cd /opt/redis
set -a
. ./.env
set +a
docker compose --env-file .env ps
docker compose --env-file .env logs --tail=120 redis
docker compose --env-file .env exec -T redis redis-cli --no-auth-warning -a "$REDIS_PASSWORD" INFO persistence
docker compose --env-file .env exec -T redis redis-cli --no-auth-warning -a "$REDIS_PASSWORD" INFO replication
docker compose --env-file .env restart redis

维护期间记录镜像 tag、配置哈希、数据卷、备份时间和客户端版本。重启 Redis 不等于验证了恢复；每次更改持久化、内存上限、淘汰策略或认证配置后，都应重复协议层和数据层验收。

生产环境安全加固 ​

  • Redis 端口默认只绑定回环地址；跨机访问通过专用内网、防火墙和最小来源列表控制。
  • requirepass 只提供默认用户密码保护，不等于完整的多用户授权；需要租户或最小权限时使用 Redis ACL，并为应用、运维和 Sentinel 分配不同身份。
  • 不要把 Redis 端口、Sentinel 26379 或 Cluster bus 端口暴露到公网；TLS、认证代理和网络策略必须与客户端能力一起验证。
  • Docker Socket、特权模式和 host network 会扩大故障影响面；Cluster 为避免 NAT 使用 host network 时，应把节点主机当作高信任边界并限制管理面。
  • 备份中的 RDB/AOF、.env、ACL 文件和业务 key 可能包含敏感数据，应加密、限权并定期做恢复演练。
  • 通用容器端口、凭据、日志和镜像供应链基线见 Docker Compose 生产安全加固教程。

常见问题 ​

容器显示 healthy，但应用连接被拒绝 ​

先确认应用连接的是宿主机回环端口还是 Compose 网络服务名 redis:6379。容器间连接不应使用宿主机映射端口；跨主机连接需要检查防火墙和绑定范围。随后用同一密码执行 PING，再检查 Redis 日志中的认证失败和连接上限。

修改 .env 后密码或内存策略没有变化 ​

.env 只在 Compose 渲染和容器创建时注入。执行 docker compose config 检查展开值后，用 docker compose up -d --force-recreate redis 重建容器；不要删除 redis_data 卷。修改密码前先安排应用连接池切换、旧密码兼容窗口和恢复验证。

AOF 重写导致延迟抖动 ​

检查 INFO persistence 的 aof_rewrite_in_progress、磁盘 fsync 延迟、容器 CPU/内存限制和数据集增长。降低写放大、保证磁盘余量、错峰执行备份；不要仅靠增加 io-threads 解决磁盘瓶颈。

Sentinel 已经发现 master 故障但没有切换 ​

检查三个 Sentinel 是否互相可达、quorum 是否满足、是否仍有多数派、Sentinel 是否传播了错误的 announce 地址，以及副本是否完成认证和复制。quorum 满足不代表一定能 failover；多数派缺失时 Sentinel 会阻止切换以避免脑裂。

Cluster 客户端持续收到 MOVED 或 CLUSTERDOWN ​

确认客户端启用了 Cluster 模式，节点公告地址和两个端口都可达，所有 16384 slot 都已覆盖，并且没有把 cluster bus 端口当成客户端端口。多 key 操作检查 hash tag；扩缩容和 slot 迁移期间不要用不支持重定向的单节点客户端。

大版本升级后无法加载数据 ​

停止继续写入，保留旧卷和旧镜像，查看目标版本的 release notes 与启动日志。优先在隔离目录用备份做导入测试；如果涉及不兼容配置、模块或数据格式，不要直接反复重启正式卷，应改用经过验证的迁移路径。

总结 ​

本文用 Redis 8.10.2 官方镜像和 Compose 建立了带认证、RDB/AOF、命名卷、健康检查和性能参数的单节点基线。性能优化应从内存上限、淘汰策略、pipeline、命令延迟和磁盘 fsync 观测开始；Sentinel 解决主从自动故障转移但不分片，Cluster 解决分片和节点故障转移但要求六节点生产基线、可达的双端口和 Cluster-aware 客户端。任何大版本或拓扑变更都必须先备份、隔离验证、分阶段升级，并完成真实恢复和业务验收。

参考资料 ​

全部公开文章由同一个站点构建和发布。

Guides Platform