#最佳实践指南

#Overview

作为云原生架构中缓存和键值存储的事实标准，Redis 负责满足高并发读写和低延迟的核心需求。在 Kubernetes 容器化环境中运行有状态的 Redis 服务，面临与传统物理机环境不同的挑战，包括持久化稳定性、动态网络拓扑变化以及资源隔离与调度。

本最佳实践文档旨在为 Redis 生产环境部署提供标准化参考，涵盖从架构选择、资源规划、客户端接入到可观测性与运维的全生命周期管理。遵循本指南，用户可构建具备高可用（HA）、高性能和易维护的企业级 Redis 数据服务。

#Architecture Selection

全栈云原生开放平台基于客户业务规模和 SLA 要求，提供两种标准 Redis 管理架构：

#Sentinel Mode

定位：经典高可用架构，适合中小规模业务。

Sentinel 模式基于 Redis 原生主从复制机制，通过部署独立的 Sentinel 进程组监控主从节点状态，主节点故障时自动执行 Failover 并通知客户端。

• 优点：架构简单，运维成熟，对客户端协议要求低。
• 缺点：写能力受限于单节点，存储容量无法横向扩展。

#Cluster Mode

定位：分布式分片架构，适合大规模高并发业务。

Cluster 模式通过 Hash Slot 自动将数据分片到多个节点，实现存储容量和读写性能的横向扩展（Scale-out）。

• 优点：真正高可用的分布式存储，支持动态重分片。
• 缺点：客户端协议复杂，部分多键命令（如 MGET）受 Slot 分布限制。

#选择指南

选择 Redis 架构时需综合考虑业务的可用性、扩展性和复杂度需求。

建议：

• 数据量较小（单节点内存可容纳），且优先考虑简单稳定，推荐使用 Sentinel Mode。
• 数据量庞大或写压力极高，单节点无法支撑，选择 Cluster Mode。

#Version Selection

Alauda Cache Service for Redis OSS 目前支持 5.0、6.0 和 7.2 三个稳定版本，均经过完整自动化测试和生产验证。

新部署强烈推荐选择 Redis 7.2：

1. 生命周期

   • 5.0 / 6.0：社区版本已进入生命周期终止（EOL），不再提供新功能和安全补丁，仅建议兼容旧应用时使用。
   • 7.2：当前长期支持（LTS）版本，生命周期最长，保障多年稳定运营和安全更新。

2. 兼容性

   • Redis 7.2 与 5.0、6.0 的数据命令高度兼容，大部分业务代码可平滑迁移无须修改。
   • 注意：RDB 持久化文件格式（v11）不向下兼容（即 7.2 生成的 RDB 无法被 6.0 加载），但不影响新服务部署。

3. 关键特性

   • ACL v2：提供细粒度访问控制（基于 Key 的权限选择器），显著提升多租户环境安全性。
   • Redis Functions：引入服务端脚本标准，解决 Lua 脚本丢失和复制问题，逻辑更贴近数据。
   • 分片 Pub/Sub：解决 Cluster 模式下 Pub/Sub 广播引发的网络风暴，通过分片显著提升消息扩展性。
   • 性能优化：对数据结构（尤其是 Sorted Sets）和内存管理深度优化，提升吞吐和降低延迟。

更多 Redis 7.2 特性详情，请参考官方 Redis 7.2 Release Notes。

#Resource Planning

#Kernel Tuning

为保障生产环境稳定高效，建议在 Kubernetes 节点层面进行如下内核参数优化：

1. 内存分配（vm.overcommit_memory）

   • 推荐值：1
   • 说明：设置为 1（Always）确保内核允许 Redis Fork 操作（RDB 快照/AOF 重写）时分配内存，即使物理内存看似不足，有效避免持久化因分配失败而中断。

2. 连接队列（net.core.somaxconn）

   • 推荐值：2048 或更高
   • 说明：Redis 默认 tcp-backlog 为 511，高并发场景下需提升系统 net.core.somaxconn 以避免客户端连接请求丢失。

3. 透明大页（THP）

   • 操作：禁用（never）
   • 说明：THP 会导致 Redis 内存分配时（尤其 Fork 后的 Copy-on-Write）出现显著延迟抖动，建议在宿主机或启动脚本中禁用。

#Memory Specifications

Redis 采用快照机制异步将内存数据持久化到磁盘，保证高性能的同时存在快照间数据丢失风险。

在 Kubernetes 容器化环境中，推荐分层内存管理策略：

• ✅ 标准规格（< 8GB）：强烈推荐。确保极低 Fork 延迟和快速故障恢复（RTO < 60s），是最稳健的生产选择。
• ⚠️ 高性能规格（8GB - 16GB）：可接受。需高性能宿主机且必须禁用 THP。Fork 可控但高负载下可能出现约 100ms 抖动。
• ❌ 高风险规格（> 16GB）：不推荐。单点故障影响过大，全量同步易饱和网络带宽，建议横向拆分为 Cluster 模式。

#为什么限制 8GB？

物理机单实例常见 32GB+，云原生环境 8GB 限制基于以下核心技术“黄金法则”：

1. Fork 阻塞与页表复制

   • Redis RDB/AOF 重写时调用 fork()，虽然内存页为 Copy-on-Write，但进程页表必须完整复制，阻塞主线程。
   • 估算：10GB 内存约 20MB 页表，阻塞 10~50ms（视虚拟化开销）。超过 8GB 阻塞风险指数级上升，影响 SLA。

2. 故障恢复效率（RTO）

   • 容器重启加载 RDB 为单线程 CPU 密集型任务（对象反序列化）。测试 8GB 数据加载耗时 30-50s（SSD 环境）。32GB 可能导致多分钟启动，违背 K8s “快速自愈”理念。

#内存配置最佳实践

为避免持久化时因内存膨胀导致 OOM Kill，需严格遵守：

1. 设置 MaxMemory：不要将 maxmemory 设为容器内存限制的 100%，建议设置为70%~80%。
2. 预留 CoW 空间：RDB/AOF 重写时 Redis Fork 子进程，写入操作多时 OS Copy-on-Write 会复制内存页，极端情况下内存使用可从 8GB 翻倍至 16GB。
3. Overcommit 配置：确保宿主机 vm.overcommit_memory=1，允许内核 Fork 时不请求等量物理内存（依赖 CoW），避免 Fork 失败。

#CPU Resources

Redis 核心命令执行为单线程，但持久化（Fork）和其他操作需子进程支持。建议每个 Redis 实例分配至少 2 核：

• 核 1：处理主线程请求和命令。
• 核 2：处理持久化 Fork、后台任务及系统开销。

#多线程

Redis 6.0+ 引入多线程 I/O（默认关闭），缓解单线程网络 I/O 瓶颈。

• 何时启用？

  • 瓶颈分析：当 Redis CPU 使用率接近 100%，且分析显示系统 CPU 时间多用于内核态网络 I/O，而非用户态命令执行。
  • 流量特征：单实例 QPS > 8 万或网络流量巨大（> 1GB/s）时较有益。
  • 资源条件：节点需具备充足 CPU 核数（至少 4 核）。

• 配置最佳实践：

  • 线程数：推荐 4~8 个 I/O 线程，超过 8 线程收益有限。
  • 配置示例：

    io-threads 4
    io-threads-do-reads yes
  • 注意：多线程 I/O 仅提升网络吞吐，不提升单条复杂命令（如 SORT、KEYS）执行速度。

#Storage Planning

#Capacity Planning

持久化模式直接决定磁盘配额需求，参考下表计算公式：

#Performance Requirements

• 启用 AOF：磁盘性能关键，IOPS 不足或 fsync 延迟高会直接阻塞主线程（appendfsync everysec）。
• 介质：生产环境强烈建议使用 SSD/NVMe 本地盘或高性能云盘。

#Parameter Configuration

Alauda Cache Service for Redis OSS 通过 Custom Resource（CR）字段指定参数。

#内置模板

提供多种参数模板，适配不同业务场景，选择依据持久化方式（Diskless/AOF/RDB）与性能权衡。

<version> 表示 Redis 版本，如 6.0、7.2。

关键参数差异：

#持久化选择建议

1. 纯缓存：选择 Diskless 模板，数据可重建，无额外开销，性能最佳。
2. 通用业务：选择 RDB 模板，周期快照提供分钟级 RPO，资源消耗适中。
3. 金融/高可靠：选择带 appendfsync everysec 的 AOF 模板，保障秒级数据安全。

#参数更新

Redis 参数按应用方式分类：

#修改示例

更新数据节点参数：通过 spec.customConfig 配置。

# 示例：修改 save 策略（热更新）
kubectl -n <namespace> patch redis <instance-name> --type=merge --patch='{"spec": {"customConfig": {"save":"600 1"}}}'

更新 Sentinel 节点参数：通过 spec.sentinel.monitorConfig 配置。

当前支持 down-after-milliseconds、failover-timeout、parallel-syncs。

# 示例：修改故障转移超时
kubectl -n <namespace> patch redis <instance-name> --type=merge --patch='{"spec": {"sentinel": {"monitorConfig": {"down-after-milliseconds":"30000"}}}}'

#Resource Specs

根据实际业务场景部署资源。

#Sentinel Mode 规格

#Cluster Mode 规格

<version> 表示 Redis 版本，如 6.0、7.2。

#Scheduling

Alauda Cache Service for Redis OSS 提供灵活调度策略，支持节点选择、污点容忍及多种反亲和配置，满足不同资源环境下的高可用需求。

#Node Selection

可通过 spec.nodeSelector 字段指定 Redis Pod 调度节点，通常结合 Kubernetes 节点标签使用，实现数据库工作负载隔离到专用节点池。

#Taint Toleration

使用 spec.tolerations 允许 Redis Pod 容忍节点污点，支持在带有特定污点（如 key=redis:NoSchedule）的专用节点上部署 Redis，避免其他非关键工作负载抢占资源。

#Anti-Affinity

为避免单点故障，Alauda Cache Service for Redis OSS 提供反亲和配置，配置方式因架构模式而异。

#Cluster Mode

Cluster 模式下，系统优先使用 spec.affinityPolicy。Alauda Cache Service for Redis OSS 通过该枚举抽象复杂拓扑规则，自动为每个分片 StatefulSet 生成亲和规则。

• 优先级：spec.affinityPolicy > spec.affinity。
• 若未设置 affinityPolicy：平台检查 spec.affinity。如需自定义枚举外的拓扑规则，留空 affinityPolicy 并配置原生 spec.affinity。

#Sentinel Mode

重要 Sentinel 模式不支持 spec.affinityPolicy。

Sentinel 模式下，Redis 数据节点和 Sentinel 节点需分别配置 Kubernetes 原生 Affinity 规则：

• Redis 数据节点：通过 spec.affinity 配置。
• Sentinel 节点：通过 spec.sentinel.affinity 配置。

需手动编写完整的 Affinity 规则。示例：强制数据节点和 Sentinel 节点反亲和：

spec:
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app.kubernetes.io/component
            operator: In
            values:
            - redis
          - key: redisfailovers.databases.spotahome.com/name
            operator: In
            values:
            - <instance name>
        topologyKey: kubernetes.io/hostname
  sentinel:
    affinity:
      podAntiAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
            - key: app.kubernetes.io/component
              operator: In
              values:
              - sentinel
            - key: redissentinels.databases.spotahome.com/name
              operator: In
              values:
              - <instance name>
          topologyKey: kubernetes.io/hostname

若需强制所有节点（数据 + Sentinel）反亲和，参考：

spec:
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: middleware.instance/type
            operator: In
            values:
            - redis-failover
          - key: middleware.instance/name
            operator: In
            values:
            - <instance name>
        topologyKey: kubernetes.io/hostname
  sentinel:
    affinity:
      podAntiAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
            - key: middleware.instance/type
              operator: In
              values:
              - redis-failover
            - key: middleware.instance/name
              operator: In
              values:
              - <instance name>
          topologyKey: kubernetes.io/hostname

#User Management

Alauda Cache Service for Redis OSS（v6.0+）通过 RedisUser CRD 提供声明式用户管理，支持 ACL。

#Permission Profiles

平台预定义常用权限模板：

自定义 ACL 详情见 Redis ACL 文档。

#Security Mechanisms

1. ACL 强制撤销：所有 RedisUser 创建/更新均通过 Webhook 校验，强制移除 acl 权限，防止权限提升。
2. 集群命令注入：Cluster 模式自动注入拓扑命令：cluster|slots、cluster|nodes、cluster|info、cluster|keyslot、cluster|getkeysinslot、cluster|countkeysinslot，确保客户端感知集群状态。
3. 6.0 -> 7.2 升级兼容：升级时自动添加 &*（Pub/Sub Channel）权限，保证与 7.x 新 Channel ACL 一致。

#System Account

每个 Redis 实例自动生成名为 operator 的系统账户，职责包括：

1. 集群初始化：槽位分配、节点加入。
2. 配置简化：统一系统账户降低用户配置复杂度。
3. 运维操作：健康检查、故障转移、扩缩容。
4. 避免重启：业务用户密码更新不影响该账户，避免重启。

#Production Best Practices

1. 应用隔离：为每个应用/微服务创建独立用户账户，避免共享账户，便于审计和隔离。
2. 最小权限原则：
   • 只读应用：使用 ReadOnly。
   • 读写应用：使用 ReadWrite。
   • 运维工具：使用 NotDangerous 或自定义权限。
   • 避免使用 Administrator，除非绝对必要。
3. Key 命名空间隔离：结合 ACL Key 模式（如 ~app1:*）限制应用访问特定前缀。
4. 密码轮换：建立机制定期轮换应用密码。

操作步骤见 用户管理文档。

#Client Access

#Topology Discovery

Sentinel 和 Cluster 模式均依赖客户端主动发现并连接数据节点，区别于传统 LB 代理模式：

#Sentinel Mode

1. 客户端连接 Sentinel 节点。
2. 发送 SENTINEL get-master-addr-by-name mymaster 获取主节点 IP/端口。
3. 客户端直接连接主节点。
4. 故障转移时，Sentinel 通知客户端（或客户端轮询）切换到新主节点。

#Cluster Mode

1. 客户端连接任意 Cluster 节点。
2. 发送 CLUSTER SLOTS / CLUSTER NODES 获取 槽分布。
3. 计算 Key 的哈希槽，直接连接目标节点。
4. 若槽迁移，节点返回 MOVED/ASK，客户端需刷新拓扑。

两种协议均返回真实节点 IP。若使用反向代理（HAProxy/Nginx），客户端仍获取后端真实 IP，可能无法从集群外访问。 因此，每个 Redis Pod 需独立外部地址（NodePort/LoadBalancer），不能使用单一代理地址。

#Network Access Strategies

Alauda Cache Service for Redis OSS 支持多种访问方式：

#Sentinel Mode

#Cluster Mode

#Code Examples

提供 go-redis、Jedis、Lettuce 和 Redisson 的最佳实践示例：

• Sentinel 访问：如何访问 Sentinel 实例
• Cluster 访问：如何访问 Cluster 实例

#Client Reliability Best Practices

1. 超时设置

   • 连接超时：区别于读写超时，建议 1-3 秒。
   • 读写超时：根据 SLA，通常为数百毫秒。

2. 重试策略

   • 指数退避：失败时不立即重试，采用退避（100ms、200ms…）避免重试风暴。

3. 连接池

   • 复用：始终使用连接池（JedisPool、go-redis Pool）节省握手开销。
   • 最大连接数：合理设置 MaxTotal，避免触及 Redis maxclients 限制。

4. 拓扑刷新（Cluster）

   • 自动刷新：确保客户端启用 MOVED/ASK 处理。
   • 定期刷新：不稳定或扩缩容环境下，配置周期刷新（如 60 秒）主动感知变化。

#Observability & Operations

#Backup & Security

平台备份中心提供便捷数据管理，支持实例备份、集中管理及 S3 异地存储，支持历史版本恢复到指定实例。

详见 备份与恢复。

#Upgrade & Scaling

#升级

详见 升级。

#扩缩容注意事项

变更规格（CPU/内存）或扩容时：

1. 评估资源：确保集群容量充足。
2. 渐进执行：滚动更新，减少中断。
3. 低峰期操作：避免高峰流量时执行。

#Monitoring

Alauda Cache Service for Redis OSS 集成 Prometheus 提供内置指标。

#内置指标

变量 {{.namespace}} 和 {{.name}} 替换为实际值。

#Key 命中率

• 说明：缓存命中率。
• 单位：%
• 表达式：

  1/(1+(avg(irate(redis_keyspace_misses_total{namespace=~"{{.namespace}}", pod=~"(drc|rfr)-({{.name}})-.*"}[5m])) by(namespace,service) / (avg(irate(redis_keyspace_hits_total{namespace=~"{{.namespace}}", pod=~"(drc|rfr)-({{.name}})-.*"}[5m])) by(namespace,service)+1)))

#平均响应时间

• 说明：平均命令延迟，高值表示查询慢或瓶颈。
• 单位：秒
• 表达式：

  avg((redis_commands_duration_seconds_total{namespace=~"{{.namespace}}", pod=~"(drc|rfr)-({{.name}})-.*"} / redis_commands_total{namespace=~"{{.namespace}}", pod=~"(drc|rfr)-({{.name}})-.*"})) by (namespace,service)

#角色切换次数

• 说明：5 分钟内主从切换次数，非零表示发生故障转移。
• 单位：次数
• 表达式：

  sum by(namespace,service) (changes((sum by(namespace,service,pod)(redis_instance_info{namespace=~"{{.namespace}}",pod=~"(drc|rfr)-({{.name}})-.*",role="master"}) OR (sum by(namespace,service,pod)(redis_instance_info{namespace=~"{{.namespace}}",pod=~"(drc|rfr)-({{.name}})-.*",}) * 0))[5m:10s]))

#实例状态

• 说明：健康状态，0 表示异常。
• 表达式：

  ((count by(namespace,service)(redis_instance_info{namespace=~"{{.namespace}}",service=~"{{.name}}",redisarch="cluster"}) % count by(namespace,service)(redis_instance_info{namespace=~"{{.namespace}}",service=~"{{.name}}",redisarch="cluster",role="master"})) == bool 0 and count by(namespace,service)(redis_instance_info{namespace=~"{{.namespace}}",service=~"{{.name}}",redisarch="cluster",role="master"}) >= bool 3) or (count by(namespace,service)(redis_instance_info{namespace=~"{{.namespace}}",service=~"rfr-({{.name}})",redisarch="sentinel",role="master"})) > bool 0

#节点输入带宽

• 说明：峰值入站流量。
• 单位：字节/秒
• 表达式：

  max by(namespace,service)(irate(redis_net_input_bytes_total{namespace=~"{{.namespace}}", pod=~"(drc|rfr)-({{.name}})-.*"}[5m]))

#节点输出带宽

• 说明：峰值出站流量。
• 单位：字节/秒
• 表达式：

  max by(namespace,service)(irate(redis_net_output_bytes_total{namespace=~"{{.namespace}}", pod=~"(drc|rfr)-({{.name}})-.*"}[5m]))

#节点连接数

• 说明：峰值客户端连接数，接近 maxclients 需关注。
• 单位：数量
• 表达式：

  max by(namespace,service)(redis_connected_clients{namespace=~"{{.namespace}}",pod=~"(drc|rfr)-({{.name}})-.*"})

#CPU 使用率

• 说明：节点 CPU 使用率，持续高负载影响性能。
• 单位：%
• 表达式：

  avg by(namespace,pod_name)(irate(container_cpu_usage_seconds_total{namespace=~"{{.namespace}}",pod_name=~"(drc|rfr)-({{.name}})-.*",container_name="redis"}[5m]))/avg by(namespace,pod_name)(container_spec_cpu_quota{namespace=~"{{.namespace}}",pod_name=~"(drc|rfr)-({{.name}})-.*",container_name="redis"})*100000

#内存使用率

• 说明：节点内存使用率，超过 80% 建议扩容。
• 单位：%
• 表达式：

  avg by(namespace,pod_name)(container_memory_usage_bytes{namespace=~"{{.namespace}}", pod_name=~"(drc|rfr)-({{.name}})-.*",container_name="redis"} - container_memory_cache{namespace=~"{{.namespace}}", pod_name=~"(drc|rfr)-({{.name}})-.*",container_name="redis"}) / avg by(namespace,pod_name)(container_spec_memory_limit_bytes{namespace=~"{{.namespace}}", pod_name=~"(drc|rfr)-({{.name}})-.*",container_name="redis"})

#存储使用率

• 说明：PVC 使用率，满载可能导致持久化失败。
• 单位：%
• 表达式：

  avg(kubelet_volume_stats_used_bytes{namespace=~"{{.namespace}}",persistentvolumeclaim=~"redis-data-(drc|rfr)-({{.name}})-.*"}) by(namespace,persistentvolumeclaim) / avg(kubelet_volume_stats_capacity_bytes{namespace=~"{{.namespace}}",persistentvolumeclaim=~"redis-data-(drc|rfr)-({{.name}})-.*"}) by(namespace,persistentvolumeclaim)

#关键指标及告警建议

生产环境推荐告警：

#Troubleshooting

具体问题请搜索 Customer Portal。

#References

• High availability with Redis Sentinel
• Redis cluster specification
• Redis persistence
• Scale with Redis Cluster
• Optimizing Redis