1. 为什么需要一份 DCS 产品对比
华为云分布式缓存服务（Distributed Cache Service，简称 DCS）是托管式的 Redis / Memcached 兼容缓存服务。随着业务规模增长，很多团队在选型时会遇到同一个问题：DCS 下面到底有几种实例形态？它们之间差在哪里？什么时候该用单机、什么时候必须上集群、什么时候该考虑读写分离？
本文把 DCS 的各个产品形态放在同一张"体检表"里，从功能、性能、可靠性、兼容性、性能监控、告警、日志、迁移方案八个维度逐项对比，帮助你在架构评审时快速给出结论。
说明：本文基于华为云 DCS 公开的产品文档与常见实践整理，具体规格、配额与计费以华为云官网控制台和最新文档为准。
2. DCS 产品形态总览
DCS 目前主流的实例类型可以归纳为以下几类：
| 实例类型 | 底层形态 | 典型定位 |
|---|---|---|
| Redis 单机 | 单节点 Redis | 开发测试、非关键缓存 |
| Redis 主备 | 一主一备（或多备） | 生产环境通用缓存 |
| Redis 集群（Cluster） | 分片 + 副本 | 大容量、高并发场景 |
| Redis 读写分离 | 主节点写 + 只读副本读 | 读多写少、读扩展 |
| Memcached | 多节点无持久化 | 纯 KV 缓存、简单场景 |
从演进路径看，绝大多数业务会走"单机 → 主备 → 集群/读写分离"的路线。下面逐维度展开。
3. 功能对比
| 功能项 | 单机 | 主备 | 集群 | 读写分离 | Memcached |
|---|---|---|---|---|---|
| 数据持久化（RDB/AOF） | 支持 | 支持 | 支持 | 支持 | 不支持 |
| 备份与恢复 | 支持 | 支持 | 支持 | 支持 | 不支持 |
| 主备自动切换 | 不支持 | 支持 | 支持 | 支持 | 不涉及 |
| 水平扩容 | 不支持 | 不支持 | 支持（分片扩容） | 支持（增加只读副本） | 支持（增加节点） |
| 多 DB（database） | 支持 | 支持 | 受限（Cluster 模式仅 db0） | 受限 | 不支持 |
| 事务 / Lua 脚本 | 支持 | 支持 | 支持（需注意跨 slot） | 支持 | 不支持 |
| 发布订阅 | 支持 | 支持 | 支持 | 支持 | 不支持 |
| 慢查询分析 | 支持 | 支持 | 支持 | 支持 | 有限 |
几个容易踩坑的点：
- 集群模式的跨 slot 操作 ：
MGET、MSET、事务、Lua 脚本涉及多个 key 时，必须保证这些 key 落在同一个 slot（可用 hash tag，如user:{1001}:name）。 - 读写分离的读一致性：只读副本存在复制延迟，强一致读场景要显式走主节点。
- Memcached 无持久化：进程重启即数据全失，只适合可重建的纯缓存。
4. 性能对比
性能主要受三件事影响：单节点规格、分片数量、网络与连接模型。
| 维度 | 单机 | 主备 | 集群 | 读写分离 |
|---|---|---|---|---|
| 单分片 QPS | 高 | 高（写走主） | 高 | 写走主，读可横向扩展 |
| 总吞吐上限 | 受单节点限制 | 受单节点限制 | 随分片数线性提升 | 随只读副本数提升读吞吐 |
| 容量上限 | 单机内存上限 | 单机内存上限 | 分片数 × 单分片容量 | 主节点容量 |
| 扩容方式 | 不支持 | 不支持 | 在线增加分片 | 在线增加只读副本 |
| 大 key / 热 key 影响 | 明显 | 明显 | 单分片热点 | 读热点可分散 |
实践建议：
- 先压测再选型。用 redis-benchmark 或业务真实流量回放，重点看 P99 而不是平均值。
- 关注连接数。集群模式下客户端需要维护到每个分片的连接，连接数会随分片数增长。
- 避免大 key。单个 value 建议控制在 10 KB 以内，集合类元素数量控制在千级。
bash
# 简单压测示例：100 并发、10 万请求、value 大小 128 字节
redis-benchmark -h <dcs_endpoint> -p 6379 -a <password> \
-c 100 -n 100000 -d 128 -t set,get -q5. 可靠性对比
| 可靠性能力 | 单机 | 主备 | 集群 | 读写分离 |
|---|---|---|---|---|
| 节点故障自动切换 | 无 | 有（秒级） | 有（分片内切换） | 有 |
| 数据副本数 | 1 | 2 及以上 | 每分片 2 及以上 | 主 + 多只读 |
| 跨 AZ 部署 | 不支持 | 支持 | 支持 | 支持 |
| 备份策略 | 手动/自动 | 手动/自动 | 手动/自动 | 手动/自动 |
| 故障影响面 | 全量不可用 | 秒级抖动 | 单分片抖动 | 读抖动 |
关键结论：
- 生产环境不要用单机。单机没有副本，节点故障即服务中断，且数据可能丢失。
- 主备是性价比最高的可靠性基线，配合跨 AZ 部署可以抵御单可用区故障。
- 集群的可靠性是"分片级"的 ：单个分片故障只影响该分片上的 key，但客户端需要正确处理
MOVED/ASK重定向和重连。
6. 扩容、缩容与故障冗余度评估
选型只是起点，真正决定线上稳定性的，是「容量变化时能不能平滑过渡」以及「坏掉一部分还能剩多少」。这一节把扩容、缩容和故障冗余度单独拎出来评估。
6.1 扩容能力对比
| 扩容维度 | 单机 | 主备 | 集群 | 读写分离 | Memcached |
|---|---|---|---|---|---|
| 是否支持在线扩容 | 不支持 | 不支持 | 支持（增加分片） | 支持（增加只读副本） | 支持（增加节点） |
| 扩容粒度 | --- | --- | 分片级 | 副本级 | 节点级 |
| 扩容期间是否可读写 | --- | --- | 可读写，部分 key 需迁移 | 可读写 | 可读写 |
| 扩容对业务的影响 | 需停机重建 | 需新建实例 + 数据迁移 | slot 迁移期间有短暂重定向 | 新副本追平前读流量不均 | 需客户端重新分片 |
| 扩容耗时主要因素 | 数据量 | 数据量 | 分片数 × 单分片数据量 | 副本全量同步耗时 | 节点数与数据量 |
扩容实践要点：
- 集群扩容的本质是 slot 迁移 。迁移过程中客户端可能收到
MOVED/ASK重定向，务必确认客户端支持重定向（Jedis、Lettuce、go-redis 均支持，但要开启对应配置）。 - 扩容前先清理无效 key。大量过期未删的 key 会让迁移数据量虚高，扩容时间成倍增加。
- 扩容不是无感的 。建议在业务低峰期执行，并提前把
timeout、重试次数调大，避免迁移期间大量超时。 - 主备/单机无法在线扩容，只能新建更大规格实例再迁移数据，这本质上是一次迁移，要按第 10 节的迁移流程走。
6.2 缩容能力对比
| 缩容维度 | 单机 | 主备 | 集群 | 读写分离 |
|---|---|---|---|---|
| 是否支持在线缩容 | 不支持 | 不支持 | 支持（减少分片，需先迁出数据） | 支持（移除只读副本） |
| 缩容前置条件 | --- | --- | 目标分片容量能容纳迁入数据 | 剩余副本能承载读流量 |
| 主要风险 | --- | --- | 数据迁移失败、slot 分布不均 | 读流量集中到主节点 |
| 建议做法 | 新建小规格实例迁移 | 新建小规格实例迁移 | 低峰期分批迁出分片 | 先降读流量再移除副本 |
缩容比扩容更容易出事，几个原则：
- 缩容前必须确认余量。缩容后的内存使用率建议不超过 60%，给突发流量留缓冲。
- 缩容要分批。一次只减一个分片或一个副本，观察 24 小时再继续。
- 缩容不可逆的部分要提前想清楚。分片减少后 slot 重新分布，热点 key 可能集中到某个分片，需要重新评估 key 设计。
- 读写分离缩容要盯住主节点。移除只读副本后读流量全部回到主节点，务必确认主节点 CPU 与连接数能扛住。
6.3 故障冗余度评估
「冗余度」可以理解为：坏掉多少还能正常服务。用 N+1 的思路量化一下：
| 实例类型 | 副本冗余 | 可容忍故障 | 冗余度评价 |
|---|---|---|---|
| 单机 | 0 副本 | 0 个节点 | 无冗余，任一故障即中断 |
| 主备 | 1 主 + 1 备（可多备） | 1 个节点（备节点故障不影响服务） | 基础冗余，可抵御单节点故障 |
| 集群 | 每分片 1 主 + N 备 | 每分片可容忍 N 个副本故障 | 分片级冗余，整体可用性随分片数下降 |
| 读写分离 | 1 主 + N 只读 | 只读副本故障仅影响读能力 | 读侧冗余，写侧仍为单点 |
评估冗余度时建议按下面的公式做一次粗算：
text
整体可用性 ≈ 单分片可用性 ^ 分片数举例：假设单分片可用性为 99.99%，集群有 16 个分片，则整体可用性约为 0.9999^16 ≈ 99.84%，相当于每月多出约 70 分钟不可用时间。这说明分片越多，越要重视单分片的故障率与快速切换能力。
提升冗余度的几个手段：
- 跨 AZ 部署：主备、集群、读写分离均支持，可抵御单可用区整体故障。
- 多副本：主备与集群均可配置多副本，副本数越多，单点故障影响越小，但写入放大也越明显。
- 客户端重试与降级：缓存不可用时要有降级到数据库或本地缓存的兜底逻辑，避免缓存故障直接打穿后端。
- 容量冗余：内存使用率长期控制在 70% 以下，为故障切换后的流量集中预留空间。
6.4 容量规划速查
| 场景 | 扩容策略 | 缩容策略 | 冗余要求 |
|---|---|---|---|
| 业务快速增长 | 集群 + 预留 30% 内存余量，按季度扩容 | 一般不缩容 | 每分片 ≥ 2 副本 + 跨 AZ |
| 流量波峰波谷明显 | 读写分离 + 弹性增加只读副本 | 波谷移除多余副本 | 主节点 + 至少 1 只读副本 |
| 稳定中小业务 | 主备，规格留 1.5 倍余量 | 迁移到小规格实例 | 主备 + 跨 AZ |
| 临时测试 | 单机 | 直接释放 | 无 |
7. 兼容性对比
| 兼容项 | Redis 系实例 | Memcached |
|---|---|---|
| 协议 | RESP2 / RESP3 | Memcached 文本协议 / 二进制协议 |
| 客户端 | Jedis、Lettuce、redis-py、go-redis 等 | spymemcached、xmemcached 等 |
| 版本兼容 | 兼容主流 Redis 版本命令集 | 兼容标准 Memcached 命令 |
| 受限命令 | 部分管理类命令受限（如 KEYS 建议禁用） |
不支持 Redis 特有数据结构 |
| 数据结构 | String/List/Hash/Set/ZSet/Stream 等 | 仅 KV |
迁移到 DCS 时常见的兼容性问题：
- 禁用命令 ：
KEYS、FLUSHALL等高风险命令在托管实例上通常被限制或需要谨慎使用，代码里要提前替换为SCAN。 - Cluster 模式下的多 key 命令：如前所述，需要 hash tag 或改写逻辑。
- Lettuce 连接池配置 ：集群模式下建议开启拓扑刷新（
enablePeriodicRefresh），避免分片变更后路由过期。
8. 性能监控对比
DCS 提供实例级和节点级的监控指标，接入云监控服务（CES）后可统一查看。不同实例形态暴露的指标并不完全一致：单机只有单节点指标，主备/读写分离多了复制类指标，集群多了分片与 slot 类指标，Memcached 则没有 Redis 特有的命令与持久化指标。
8.1 各产品形态支持的监控指标
| 监控类别 | 关键指标 | 单机 | 主备 | 集群 | 读写分离 | Memcached |
|---|---|---|---|---|---|---|
| 基础资源 | CPU 使用率、内存使用率、磁盘/网络 I/O | 支持 | 支持 | 支持（实例级 + 分片级） | 支持 | 支持 |
| 连接 | 当前连接数、新建连接数、拒绝连接数 | 支持 | 支持 | 支持（按分片汇总） | 支持（主 + 只读分别统计） | 支持 |
| 命令 | QPS、命中率、慢查询数 | 支持 | 支持 | 支持（分片级可下钻） | 支持（主/只读分别统计） | 部分支持（QPS、命中率） |
| 时延 | 平均时延、P99 时延 | 支持 | 支持 | 支持（分片级） | 支持（主/只读分别统计） | 支持（平均时延） |
| 复制 | 主备延迟、复制中断次数 | 不涉及 | 支持 | 支持（分片内） | 支持 | 不涉及 |
| 高可用 | 主备切换次数、切换耗时 | 不涉及 | 支持 | 支持（分片级） | 支持 | 不涉及 |
| 集群 | 分片负载、slot 分布、迁移状态 | 不涉及 | 不涉及 | 支持 | 不涉及 | 不涉及 |
| 持久化 | RDB/AOF 状态、最近备份结果 | 支持 | 支持 | 支持 | 支持 | 不涉及 |
| 内存细节 | 已用内存、碎片率、淘汰 key 数 | 支持 | 支持 | 支持（分片级） | 支持 | 支持（已用内存、淘汰数） |
几点说明：
- 集群形态的指标要"先看整体、再看分片"。整体 QPS 正常不代表没有热点分片，建议对分片级 CPU、内存、QPS 单独配置看板。
- 读写分离要区分主节点与只读副本。只读副本的时延、连接数、复制延迟是独立指标，混在一起看会掩盖读侧问题。
- Memcached 指标相对简单，没有持久化、复制、slot 相关指标，重点看内存、连接与命中率。
- 单机形态没有复制与切换类指标，监控重点应放在资源水位与实例存活状态上。
8.2 建议重点盯住的指标
- 内存使用率：超过 80% 就要评估扩容，避免触发淘汰策略导致命中率骤降。
- 缓存命中率：命中率下降往往意味着 key 设计或过期策略有问题。
- P99 时延：平均值好看不代表没问题，P99 才是用户体验的真实体现。
- 主备延迟（主备/集群/读写分离）：延迟持续增大说明复制链路异常，切换时可能丢数据。
- 分片负载均衡度（集群）：分片间 CPU/内存差异过大，说明 slot 或 key 分布不均。
9. 告警配置对比
告警指标建立在监控指标之上，但不同形态需要关注的告警项不同：单机没有切换类告警，主备/读写分离要重点配复制类告警，集群要额外配分片与 slot 类告警，Memcached 则聚焦资源与命中率。
8.1 各产品形态建议的告警指标
| 告警项 | 建议阈值 | 单机 | 主备 | 集群 | 读写分离 | Memcached |
|---|---|---|---|---|---|---|
| CPU 使用率 | > 70% 持续 5 分钟 | 建议 | 建议 | 建议（含分片级） | 建议（主/只读分别） | 建议 |
| 内存使用率 | > 80% | 建议 | 建议 | 建议（含分片级） | 建议 | 建议 |
| 连接数使用率 | > 80% | 建议 | 建议 | 建议 | 建议 | 建议 |
| 缓存命中率 | < 90% | 建议 | 建议 | 建议 | 建议 | 建议 |
| 主备延迟 | > 1 MB 或 > 5 秒 | 不涉及 | 建议 | 建议（分片内） | 建议 | 不涉及 |
| 实例状态 | 非运行中 | 建议 | 建议 | 建议 | 建议 | 建议 |
| 慢查询数 | 突增 | 建议 | 建议 | 建议 | 建议 | 可选 |
| 主备切换事件 | 发生即告警 | 不涉及 | 建议 | 建议 | 建议 | 不涉及 |
| 分片负载不均 | 分片间 CPU 差异 > 30% | 不涉及 | 不涉及 | 建议 | 不涉及 | 不涉及 |
| slot 迁移异常 | 迁移超时或失败 | 不涉及 | 不涉及 | 建议 | 不涉及 | 不涉及 |
| 淘汰 key 数 | 持续 > 0 | 建议 | 建议 | 建议 | 建议 | 建议 |
| 持久化失败 | 备份/RDB 失败 | 建议 | 建议 | 建议 | 建议 | 不涉及 |
8.2 告警落地建议
- 按严重 / 重要 / 次要分级，严重告警直接电话+短信，次要告警走 IM 群。
- 告警要绑定责任人，避免"群里有告警但没人认领"。
- 对扩容类告警设置抑制规则，避免扩容过程中反复告警。
- 切换类告警要单独成组：主备切换、分片切换属于高优先级事件，即使服务已自动恢复，也要通知到人排查根因。
- 集群告警建议按分片维度配置，避免只配实例级阈值导致单分片热点被平均值掩盖。
- 告警阈值要随业务基线调整：大促前临时上调内存与连接数阈值，避免误报淹没真实问题。
9. 日志能力对比
| 日志类型 | 内容 | 获取方式 |
|---|---|---|
| 慢查询日志 | 执行时间超阈值的命令 | 控制台查看 / 参数配置阈值 |
| 运行日志 | 实例运行状态、异常事件 | 控制台 / 云日志服务 LTS |
| 审计日志 | 关键操作记录 | 控制台操作记录 |
| 备份日志 | 备份任务执行结果 | 备份管理页面 |
实践要点：
- 慢查询阈值建议设置为业务可接受时延的 1/2，例如目标 P99 为 10 ms，则阈值设为 5 ms。
- 将运行日志接入 LTS 后可以做关键字告警，例如匹配
OOM、connection refused等。 - 日志保留周期要满足合规要求，一般生产环境建议至少保留 30 天。
10. 迁移方案对比
| 迁移场景 | 推荐方案 | 注意事项 |
|---|---|---|
| 自建 Redis → DCS | DCS 数据迁移工具 / redis-shake | 校验 key 数量与抽样数据 |
| 其他云 Redis → DCS | 在线迁移（公网/专线） | 带宽评估、增量同步 |
| DCS 实例间迁移 | 备份恢复 / 迁移工具 | 大实例优先备份恢复 |
| Memcached → Redis | 应用层改造 | 数据结构需重新设计 |
| 版本升级迁移 | 新建实例 + 双写切换 | 灰度切流、可回滚 |
通用迁移流程：
#mermaid-svg-LjXFt7It9NFAiO58{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-LjXFt7It9NFAiO58 .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-LjXFt7It9NFAiO58 .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-LjXFt7It9NFAiO58 .error-icon{fill:#552222;}#mermaid-svg-LjXFt7It9NFAiO58 .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-LjXFt7It9NFAiO58 .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-LjXFt7It9NFAiO58 .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-LjXFt7It9NFAiO58 .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-LjXFt7It9NFAiO58 .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-LjXFt7It9NFAiO58 .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-LjXFt7It9NFAiO58 .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-LjXFt7It9NFAiO58 .marker{fill:#333333;stroke:#333333;}#mermaid-svg-LjXFt7It9NFAiO58 .marker.cross{stroke:#333333;}#mermaid-svg-LjXFt7It9NFAiO58 svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-LjXFt7It9NFAiO58 p{margin:0;}#mermaid-svg-LjXFt7It9NFAiO58 .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-LjXFt7It9NFAiO58 .cluster-label text{fill:#333;}#mermaid-svg-LjXFt7It9NFAiO58 .cluster-label span{color:#333;}#mermaid-svg-LjXFt7It9NFAiO58 .cluster-label span p{background-color:transparent;}#mermaid-svg-LjXFt7It9NFAiO58 .label text,#mermaid-svg-LjXFt7It9NFAiO58 span{fill:#333;color:#333;}#mermaid-svg-LjXFt7It9NFAiO58 .node rect,#mermaid-svg-LjXFt7It9NFAiO58 .node circle,#mermaid-svg-LjXFt7It9NFAiO58 .node ellipse,#mermaid-svg-LjXFt7It9NFAiO58 .node polygon,#mermaid-svg-LjXFt7It9NFAiO58 .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-LjXFt7It9NFAiO58 .rough-node .label text,#mermaid-svg-LjXFt7It9NFAiO58 .node .label text,#mermaid-svg-LjXFt7It9NFAiO58 .image-shape .label,#mermaid-svg-LjXFt7It9NFAiO58 .icon-shape .label{text-anchor:middle;}#mermaid-svg-LjXFt7It9NFAiO58 .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-LjXFt7It9NFAiO58 .rough-node .label,#mermaid-svg-LjXFt7It9NFAiO58 .node .label,#mermaid-svg-LjXFt7It9NFAiO58 .image-shape .label,#mermaid-svg-LjXFt7It9NFAiO58 .icon-shape .label{text-align:center;}#mermaid-svg-LjXFt7It9NFAiO58 .node.clickable{cursor:pointer;}#mermaid-svg-LjXFt7It9NFAiO58 .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-LjXFt7It9NFAiO58 .arrowheadPath{fill:#333333;}#mermaid-svg-LjXFt7It9NFAiO58 .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-LjXFt7It9NFAiO58 .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-LjXFt7It9NFAiO58 .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-LjXFt7It9NFAiO58 .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-LjXFt7It9NFAiO58 .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-LjXFt7It9NFAiO58 .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-LjXFt7It9NFAiO58 .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-LjXFt7It9NFAiO58 .cluster text{fill:#333;}#mermaid-svg-LjXFt7It9NFAiO58 .cluster span{color:#333;}#mermaid-svg-LjXFt7It9NFAiO58 div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-LjXFt7It9NFAiO58 .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-LjXFt7It9NFAiO58 rect.text{fill:none;stroke-width:0;}#mermaid-svg-LjXFt7It9NFAiO58 .icon-shape,#mermaid-svg-LjXFt7It9NFAiO58 .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-LjXFt7It9NFAiO58 .icon-shape p,#mermaid-svg-LjXFt7It9NFAiO58 .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-LjXFt7It9NFAiO58 .icon-shape .label rect,#mermaid-svg-LjXFt7It9NFAiO58 .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-LjXFt7It9NFAiO58 .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-LjXFt7It9NFAiO58 .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-LjXFt7It9NFAiO58 :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 是
否
评估源实例规格与数据量
创建目标 DCS 实例
全量数据迁移
增量同步与校验
灰度切流 10%
错误率与延迟是否正常
逐步放量至 100%
回滚至源实例
观察稳定后下线源实例
迁移 checklist：
- 源实例 key 数量、内存占用、大 key 清单已盘点
- 目标实例规格留有余量（建议 ≥ 源实例的 1.2 倍）
- 客户端连接串、密码、超时参数已更新
- 双写/灰度期间的数据一致性校验脚本已准备
- 回滚方案与责任人已明确
11. 选型建议速查
| 业务场景 | 推荐实例类型 |
|---|---|
| 开发测试、临时验证 | 单机 |
| 中小型生产业务、会话缓存 | 主备 |
| 大容量、高并发、可分片 | 集群 |
| 读多写少、读扩展需求强 | 读写分离 |
| 纯 KV、无持久化需求 | Memcached |
一句话总结：能用主备就别用单机，容量或并发顶不住就上集群，读压力大就加只读副本，Memcached 只留给最简单的场景。
12. 总结
DCS 的产品矩阵并不复杂，难点在于把"业务特征"映射到"实例形态"。回顾本文的八个维度：
- 功能：集群模式要注意跨 slot 限制，Memcached 无持久化。
- 性能：先压测再选型，关注 P99 与连接数。
- 可靠性：生产环境以主备为基线，跨 AZ 部署。
- 扩容与缩容：集群可在线扩缩分片，主备/单机只能新建实例迁移；缩容前留足余量、分批执行。
- 故障冗余度：分片越多整体可用性越低，需按「单分片可用性 ^ 分片数」粗算，并用多副本、跨 AZ、客户端降级兜底。
- 兼容性：提前排查禁用命令与多 key 操作。
- 监控与告警：盯住内存、命中率、P99 三个核心指标。
- 日志：慢查询阈值按业务时延倒推，日志接入 LTS。
- 迁移：全量 + 增量 + 灰度切流 + 可回滚，四步不能少。