3. 云化部署环境规划

Redis 云化部署的第一道工程门槛，不是“能不能装起来”，而是“多个环境能不能互不干扰地长期共存”。开发、测试、预发、生产四类环境如果共用同一套集群、同一网段、同一命名空间，任何一次误操作、压测流量或配置漂移都可能穿透到生产。环境规划的本质，是把隔离边界、网络可达性、资源上限和命名可读性四件事在部署前一次性定义清楚。

一、四类环境的定位与隔离强度

四类环境不是简单的“复制四份”，它们承担的任务不同，隔离强度也应逐级递增。

隔离维度通常分三层：计算隔离（独立实例或独立集群）、网络隔离（VPC/子网/安全组）、权限隔离（账号、ACL、密钥）。开发与测试可以共享一套 Kubernetes 集群但使用不同 Namespace；预发与生产必须使用独立集群或至少独立 VPC，避免节点故障、网络抖动和资源争抢互相传导。

二、网络分区设计

网络分区的目标是：同环境内互通，跨环境默认不通，仅保留受控的放行通道。以一套典型的三层分区为例：

• 接入区：放置网关、代理，仅暴露必要端口，如 Redis 的 6379/16379。
• 应用区：业务服务所在子网，通过安全组仅允许访问本环境 Redis 的端口。
• 数据区：Redis 实例、Sentinel/Cluster 节点所在子网，禁止公网入站，仅接受应用区与运维跳板机的连接。

跨环境访问必须显式放行。例如测试环境需要读取预发脱敏数据时，只开放预发到测试的单向只读通道，而不是把两个网段直接打通。生产环境应关闭公网访问，运维通过跳板机或专线进入。若使用云托管 Redis，则通过白名单和安全组控制来源 IP，避免使用 0.0.0.0/0。

三、资源配额与容量基线

资源配额要回答两个问题：每个环境最多能用多少，以及单实例的容量基线是多少。配额过松会导致测试环境压测拖垮共享节点，过紧则会让预发无法模拟生产负载。

建议按环境设定 CPU、内存、连接数和带宽上限。例如开发环境单实例上限 1 核 2GB、最大连接 200；测试环境 2 核 4GB、最大连接 1000；预发与生产按实际业务量规划，通常预留 30% 以上内存余量，并设置 maxmemory-policy 与告警阈值。Redis 内存规划可参考：

可用内存 = 实例内存 × 0.7
数据内存 = 可用内存 - 复制缓冲区 - 客户端缓冲区 - 碎片开销

例如 8GB 实例，按 0.7 计算可用约 5.6GB，扣除复制缓冲与客户端缓冲约 0.6GB，实际可承载数据约 5GB。若业务数据预计 4GB，则余量约 20%，属于偏紧，应扩容或优化键设计。配额还应包括连接数、QPS 和慢查询阈值，避免单环境异常影响整体。

四、命名规范

命名规范是环境隔离的“可读契约”。推荐采用环境-业务-角色-序号的结构，例如：

redis-prod-order-master-01
redis-prod-order-replica-01
redis-staging-order-master-01
redis-test-order-master-01
redis-dev-order-master-01

Kubernetes 资源可对应为：

Namespace: redis-prod / redis-staging / redis-test / redis-dev
StatefulSet: order-redis
Service: order-redis-svc
ConfigMap: order-redis-config
Secret: order-redis-secret

命名中必须包含环境标识，禁止出现 redis-01 这类无法判断归属的名称。键名同样建议带业务前缀，如 order:detail:{id}，避免不同业务键冲突。命名一旦确定，应写入部署模板和 CI 校验，防止人工创建时绕过规范。

五、环境隔离的整体关系

下图展示四类环境在命名空间、网络分区、资源配额和命名规范上的对应关系，可作为部署前的规划检查视图。

六、落地检查要点

规划完成后，建议在部署前逐项确认：环境标识是否进入所有资源名；跨环境网络是否默认拒绝；生产是否关闭公网；每个环境的内存、连接数、QPS 配额是否明确；预发是否与生产同构；密钥是否按环境独立。把这些检查项写入 CI 或部署流水线，才能让隔离策略从文档变成可执行的约束。