迁移到 Engula · 总览
Engula 与 Redis 7.2 可视为平替：协议、命令集与复制行为一致，可互为主从，现有客户端代码、SDK 与运维工具基本无需改造。因此把线上 Redis / Valkey 迁移到 Engula，可以复用大家熟悉的 Redis 滚动升级（副本 + 计划性切主） 流程，一路平滑切换，并保留可回退路径（两步的回退口径不同，见下）。
本文只给方法与要点；具体命令、参数因部署形态（单实例主从 / Cluster）与环境而异，落地可结合 Engula 支持团队细化。
迁移思路：一次只引入一个变量
从较老的 Redis（如 6.x）迁移到 Engula，通常同时跨越两件事：Redis 版本差异与引擎差异。两个变量叠加会让出问题时难以定位。推荐两步走，每步只引入一个变量、都可回退（但两步的回退口径不同）：
Redis 6.x ──①版本升级──▶ Redis 7.2 ──②引擎迁移──▶ Engula
(纯版本升级) 观察期 (纯引擎迁移)
- 第一步：Redis 6.x → 7.2 —— 纯版本升级，走 Redis 官方滚动升级实践。回退口径是"回到切主点"：旧 6.x 无法加载 7.2 的 RDB，切回后、切主之后写入 7.2 的增量不会回到 6.x。见 Redis 6.x → 7.2 升级。
- 稳定观察期 —— 建议覆盖至少一个完整业务周期（含周末 / 大促 / 结算等峰值），时长由业务定。
- 第二步：Redis 7.2 → Engula —— 纯引擎迁移。因 Engula 与 7.2 平替、可互为主从，Redis 可作 Engula 的热备从持续跟随，回退更干净。见 Redis 7.2 → Engula 迁移。
两步都能回退，但含义不同：第一步是"回到切主点"（非无损，会丢切主后写入 7.2 的增量）；第二步 Redis 作 Engula 的热备从、回退更干净。若业务简单（如纯缓存、可从数据库重建），也可评估直接迁移；两步走是更稳健的默认建议。
推荐方式：滚动切主（副本 + Failover）
由于 Engula 与 Redis 7.2 互为主从，两步都用同一套成熟机制：
加新节点为从 ──▶ 追平复制 ──▶ 计划性切主 ──▶ 观察期(保留旧节点) ──▶ 下线旧节点
- 不需要双写、不依赖特殊接入层，链路短、成本低。
- 蓝绿变体：切主后保留旧版本 / 旧引擎节点作为从，进入观察期；无问题再移除，有问题可快速切回。
- 适用于单实例主从与 Redis Cluster 两种形态（Cluster 用
CLUSTER FAILOVER 逐 shard 切主；Cluster 建议单独演练验证，见执行文档）。
另一种思路：代理双写 + 灰度切读
当无法依赖复制切主、或需要按比例灰度读、跨机房强可控迁移时，业界还有一种"代理双写"思路：
同步(全量+增量) ──▶ 接入层双写(源+目标) ──▶ 按比例灰度切读 ──▶ 观察 ──▶ 关双写、下线源
它把迁移拆成可观测、可灰度、可秒级回滚的过程，但通常无法零开发落地——需要在接入层 / Proxy 上具备或自建下列能力。下表列出开发需求点及其在迁移中的目的：
| 开发需求点 |
在迁移中的目的 |
| 双写：写同时打到源与目标 |
目标端在切读前持续接住增量写、与源保持同步，为灰度切读做准备 |
| 双写失败处理：区分"源写失败 / 目标写失败" |
源写失败即返回失败以保主链路正确性；目标写失败不影响返回但记录 |
| 熔断：目标写失败率 / 超时超阈值自动停目标写并告警 |
目标端异常时一键降级、保住主链路 |
| 按比例切读：读 10%→30%→…→100% 可调、可秒级切回 |
读流量分档灰度，每档验证后再推进，异常立即回退 |
| 幂等 / 重试控制：针对 INCR、LPUSH 等非幂等命令 |
双写 + 重试下防止重复写导致计数 / 列表偏差 |
| 旁路校验：抽样比对 Key + Value + TTL |
持续发现两端不一致并告警，覆盖热点 / 核心 Key |
| 命令审计 / 可观测指标 |
提供灰度各档的量化验收依据与问题定位手段 |
该方式需结合具体接入层做定制开发，本指南不作为标准执行步骤给出。有此类需求可联系我们评估。
迁移前检查清单
由运维 / DBA 与业务方逐项确认（高层，阈值由业务定）：
- 命令与兼容性：用真实命令日志盘点线上实际用到的命令 / 用法（Lua、Streams、阻塞命令、Module 等重点）；用 shadow 影子模式镜像生产流量做一致性验证。
- 业务特征：命令模式（简单 KV / 复杂结构）；Redis 定位（纯缓存可重建 / 主存储不可丢）；客户端超时与连接池。
- 稳定性要求：是否允许秒级写入闪断；对非幂等命令少量偏差的容忍度；可接受的 P99 上涨倍数。
- 资源与窗口：可同时运行的节点数量（新旧并存 + 观察期保留）；业务低峰 / 变更冻结窗口。
通用风险控制原则
- 先建立一致点，再切主：切主前短暂停写，等目标从追平到旧主的最终复制 offset，再提主。
- 回退口径分两步：第一步（6.x→7.2）是"回到切主点"、非无损；第二步（7.2→Engula）Redis 作 Engula 热备从、可较干净回切。切换完成前旧节点始终保有其数据，观察期内不要重启 / 重建旧节点。
- 计划性优于自动：主动择时切主优于等故障自动切。
- 每步即时校验：一次只动一个节点，操作后立即验证复制与集群状态再继续。
- 持续校验：抽样比对 Key + Value + TTL，不一致即告警；热点 / 核心 Key 专项校验。
需要特别留意
- 跨大版本快照不向后兼容：跨大版本升级后旧版本通常无法加载新版本快照。回滚依赖保留旧节点，观察期内不要重启 / 重建旧节点。
- 非幂等命令：切换 / 重试期间 INCR、LPUSH 等可能重复写，需业务容忍或幂等封装。
上线前必须确认
- 二进制平台与构建匹配（操作系统、CPU 架构、glibc、SHA256 校验）。
- 备份与恢复演练完成。
- 监控、告警与日志已接入。
- 回滚命令与责任人明确。
版本与授权
- Engula Developer Edition —— 最多 6 个 Engula 节点。
- Engula Enterprise —— 用于更大规模或生产用途，授权与支持由商务合同约定。
商业或生产迁移请使用 Engula Enterprise，版本差异与 EULA 见下载页与 EULA。
迁移后：验证收益
- 实时验证 —— 兼容性 / 性能 / RDB / 内存效率实测结果。
如需迁移评估或方案细化，欢迎联系我们。