先说结论Redis集群做“三节点到三节点”的迁移难点从来不在数据拷贝而在于怎么让业务无感知、数据不丢失、回滚有退路。我上个月刚做完一个线上生产环境的同构集群迁移旧集群三台物理机新集群三台容器化部署从方案选型到最终切换花了整整一周。这期间踩了不少坑也把几条常规迁移路线都过了一遍最后形成的这套流程在流量高峰期完成了无缝过渡写下来做个完整复盘。如果你也遇到机房搬迁、云厂商切换、或者纯粹想把自建集群挪进容器平台这类需求这篇应该能帮你少走很多弯路。文章会覆盖方案对比、工具选型、参数调优、切换细节、以及几个只有真跑过迁移才会遇到的故障点。1. 为什么会有“三迁三”这种需求场景决定方案1.1 同构集群迁移比异构迁移更考验细节很多人一听“三节点到三节点”第一反应是节点数都一样直接在新机器上搭好集群把数据导过去不就行了但实际生产环境里“同构”指的只是节点数量相同不等于环境相同。我这次迁移的背景是一个自建的物理机Redis Cluster三个master节点版本是5.0.14。新集群是容器平台上的三个节点同样跑Redis Cluster但版本升级到了6.2.7而且新集群提前配置了三从架构每个master带一个slave。看起来都是三主节点但底层环境、版本、部署方式全变了。同构迁移的迷惑性就在这里因为你不需要重新设计拓扑所以容易低估工作量直接想拿RDB文件搬过去。但一旦涉及到版本跨代、部署形态变化、客户端连接方式调整光靠RDB文件恢复是远远不够的。1.2 无缝过渡的两个核心指标数据零丢失与业务零感知在定方案之前我和团队先明确了两个硬指标数据零丢失迁移过程中写入Redis的数据不能丢也就是说不能用“停服备份再恢复”这种简单粗暴的方式。业务零感知客户端连接不需要改代码、不需要重启应用切换过程中接口不能出现明显超时或报错。这两个指标看着容易实际上已经把“停机迁移”这条路堵死了。剩下的方案只有两条路线一条是增量同步 快速切换准无缝另一条是业务双写 最终切换真无缝。两条路线我都仔细梳理了下文会逐一说清取舍。还有一个隐性问题值得提前强调Redis Cluster的客户端是有拓扑感知的切换集群后如果客户端还连着旧节点的IP会出现大量MOVED重定向这个问题会在切换阶段专门处理后面详细讲。2. 四条常规迁移路线为什么最后选了同步工具2.1 临时主从挂载哨兵架构很顺cluster架构别扭最常见的无感迁移思路是“新旧搭主从”。如果是Redis Sentinel架构一主一从一哨兵之类在旧master上执行REPLICAOF指向新master同步完成后把哨兵指向新集群然后执行REPLICAOF NO ONE整个过程非常顺滑。但Redis Cluster架构下这套玩法会碰壁。Cluster模式下每个节点有固定的slot分配新节点的master身份、slot归属都要通过集群协议协商。如果你让新集群某个master执行replicaof指向旧集群的master在cluster-enabled状态下它会尝试在集群拓扑中重新协商身份很容易出现“自己把自己搞成孤儿节点”的诡异状态或者数据能复制过来但集群状态一直是cluster_state:fail。我实际测试了一下新节点执行replicaof指向旧集群节点后数据确实开始同步了但新集群因为某些slot归属跟旧集群的配置信息不一致集群状态直接变成fail。排查起来很费劲而且就算解决切换时的一连串cluster指令操作也远不如工具链成熟。所以这个方案直接放弃了——不是说完全不行而是坑太密性价比太低。2.2 MIGRATE逐key搬迁只适合小数据量Redis自带的MIGRATE命令可以把key从一个节点原子迁移到另一个节点Cluster模式下还能指定slot迁移。但它是逐key操作的每迁移一个key都要建立一次到目标节点的连接可以开pipeline优化但本质上还是一个key一个key搬。我这边旧集群有差不多800万key最大单key有几十MB用MIGRATE搬一轮算下来大概要跑十几个小时而且中间如果业务还在写新写入的key还得扫第二遍。更关键的是MIGRATE只搬数据和TTL不搬集群配置、不搬slot归属迁移完成后你还得手动做客户端拓扑切换。这个方案只适合那种总共几十万key、业务量很小的内部系统生产核心链路完全不适合。2.3 新节点入旧集群再reshard集群重构不等于迁移还有一条路是“让新节点加入旧集群用redis-cli --cluster reshard把slot迁过去最后把旧节点摘掉”。这个方案在技术上是可行的本质是集群扩容再缩容。但这里有个很现实的问题大规模reshard过程中Redis Cluster的slot迁移会触发大量的ASK重定向请求对客户端有一定兼容性要求而且迁移期间旧节点的内存和CPU都会飙升如果集群负载本来就高会直接影响线上延迟。再加上这个方案要求新旧节点网络能够互通双向在跨机房、跨云场景下基本不具备条件。我这次新旧集群不在同一网段虽然网络策略可以做双向打通但运维和安全那边流程很长最终还是放弃了这条需要网络深通的路线。如果你新旧集群在一个二层网络里这个方案倒是可以考虑但要严格在低峰期做。2.4 redis-shake全量增量可控性最强的组合最后我把目光落在redis-shake上。它是阿里云开源现在由tair团队维护的Redis数据同步工具支持standalone、cluster、proxy等多种形态之间互相同步核心能力就是全量同步基于RDB解析加增量同步基于PSYNC命令订阅后续写入。为什么选它而不是自己写脚本三个理由全量阶段它会把源RDB文件解析后按命令格式灌入目标端天然避开了RDB版本兼容问题而且会保留TTL。增量阶段它用PSYNC协议持续抓取源实例的新写入我可以在切换前让增量一直跑着把数据差距压到几百毫秒以内。它支持配置文件启动多个同步任务我可以为每个源master单独起一个同步进程做到“一对一”精确映射。这套组合让我能在新集群不停机的情况下先同步一个“和历史数据基本一致、且持续追平增量”的数据副本然后再挑一个业务低峰窗口做快速切换。这就是我要的“准无缝”方案。3. redis-shake迁移的落地过程与参数实证3.1 新集群的初始化细节新集群的部署我不过多展开但有几个前置条件必须做对否则后面同步过程会出幺蛾子新集群不要预先写任何业务数据保持三个master节点的数据都是空的。新集群的每个master都要提前配好对应的slave因为redis-shake同步的是master节点流量切换后如果新master没有从节点保护一旦宕机整个集群不可写。新集群的密码认证、AOF持久化都要先配置好。特别提醒开启AOF后再接收全量同步会比只靠RDB更稳但落地时要注意磁盘空间和fsync策略避免同步高峰期把磁盘IO打满。我这边新集群三个master的IP规划是10.0.8.11:6379、10.0.8.12:6379、10.0.8.13:6379旧集群是192.168.5.21:6379、192.168.5.22:6379、192.168.5.23:6379。redis-shake部署在旧的物理机上走内网连接新集群。3.2 全量同步阶段的参数调优redis-shake的配置文件是redis-shake.conf我用的是sync模式跑“全量增量”链路。核心配置如下source.type cluster source.address 192.168.5.21:6379;192.168.5.22:6379;192.168.5.23:6379 source.password old_password source.auth-type auth target.type cluster target.address 10.0.8.11:6379;10.0.8.12:6379;10.0.8.13:6379 target.password new_password target.auth-type auth sync.mode sync # 大key自动拆分阈值 advanced.big-key-threshold 104857600 # 单个pipeline的批量大小 advanced.pipeline-count-limit 8 # 日志级别 log.level info几个参数我在实际压测后调整过这里说说为什么advanced.big-key-threshold默认是102400字节约100KB。我这边有不少session缓存key比较大如果按默认阈值大量key都会走拆分路径线程调度会频繁切换干脆调大到100MB只有真正的大key才做拆分批处理。这里的教训是不要迷信默认值要根据你的key大小分布来设。advanced.pipeline-count-limit控制单次pipeline处理命令的数量。改小会让单批传输更快完成但总吞吐下降改大吞吐高但风险缓冲区变大。我摩擦了三四轮最终稳定在8比较合适。另外建议关闭advanced.resolve做DNS预解析在容器网络环境下的一些隐性问题直接走IP最稳。三个同步任务我是分三个进程跑的每个进程同步一个旧master到对应的新master。这里有个关键点三个进程的顺序性没有严格要求但最好错开启动时间避免三个全量同步任务同时冲进新集群导致新集群的内存和带宽被同时打满。全量同步阶段会持续多久我这边的数据量大概5GB左右800万key三个任务并行同步真实耗时大约10分钟。同步期间我盯着Redis的master_repl_offset和redis-shake日志里的sync进度数据确认三个源master的RDB快照都已经传输完成。3.3 增量追平如何判断可以切换全量同步完成后redis-shake会进入持续增量同步的状态此时判断“能不能切”的核心指标是增量延迟。在旧集群每个master上执行redis-cli -h 192.168.5.21 -p 6379 -a old_password INFO replication看slave_repl_offset或者直接在redis-shake日志里看rdb和offset的差距。我当时定的标准是增量延迟持续稳定在10秒以内才允许执行切换而且要在切换前连续观察5分钟。为什么会盯这个指标因为切换动作本身要花费一定时间改客户端配置、生效、重启连接池如果增量延迟已经数十秒甚至更大你切换期间新写入的数据其实还没到新集群一切过去就丢数据。增量的吞吐在低峰期基本追平我观察到的延迟范围在200ms到3秒之间浮动符合切换条件。3.4 一致性校验的三层方法增量追平后别急着切换。我在切换前做了一轮比较严格的数据一致性校验分三层第一层对比key数量redis-cli -h 192.168.5.21 -p 6379 -a old_password DBSIZE redis-cli -h 10.0.8.11 -p 6379 -a new_password DBSIZE这里要注意Cluster模式dbsize只统计单个节点所以三个master要分别对比。差异在100个key以内且主要是过期key的抖动属于正常范围。第二层抽样对比value我写了一个小脚本随机抽1万个key分别从新旧集群取value做hash对比。抽样范围我刻意覆盖了每个slot的key。这里推荐你用redis-cli的--bigkeys先梳理一下key的分布然后每个节点取top关键字段抽样比纯随机更有效。第三层检查TTL偏差Redis的key迁移后TTL字段必须保持和源key大致一致。redis-shake在同步时会把剩余TTL一起迁移但增量同步中客户端如果对某个key执行了EXPIRE这个更新也会同步过去。我抽了1000个带TTL的key对比偏差都在1秒以内符合预期。校验通过后我才开始设计切换流程。4. 切换窗口的设计从“准无缝”到“真无缝”4.1 双写方案真无缝的成本与收益严格来说“准无缝”方案在切换瞬间还是需要业务做一次极短时间的停止写入秒级。如果业务对“零写停止”有硬性要求那就得上双写方案在应用层把每次写操作同时发到旧集群和新集群等增量追平然后逐步把旧集群剥离。双写方案的收益是显而易见的写流量始终在新集群上打着切换瞬间完全没有写空洞。但成本也高得多应用层需要改数据访问层代码做双写逻辑这是一个上线后需要长期维护的额外复杂度。双写期间每一次写操作最慢的那个集群决定链路时延如果新集群比旧集群慢几毫秒整体RT就会被拉高。双写期间的分布式锁、事务、Lua脚本这类Redis特性实现起来非常痛苦。我这边业务对写入连续性的容忍度还好自动化任务在切换前做了暂停核心交易链路在低峰期本身写量不大所以我选择的是“增量追平短窗口暂停写”的准无缝方案。如果你需要的是“连日志里都看不出切换痕迹”那还是老老实实上双写。4.2 先切读后切写风险最小化的切换顺序我的切换动作分成了三步严格按“读→写→全量”的顺序来第一步切读流量。把读请求通过配置中心我这里用的是Nacos动态切到新集群观察新集群的读RT、命中率、错误率。因为Redis Cluster的读请求在master上处理新集群的数据已经和旧集群一致了读切换几乎是零风险的。第二步切写流量。写流量切换前我先在旧集群上执行CLUSTER READONLY不对写切换的关键是让应用连接串指向新集群地址。这里我分了两批先切20%的写流量观察5分钟再切剩余80%。整个过程没有遇到报错。第三步停增量同步。确认新集群数据稳定后停掉redis-shake的增量同步。因为此时所有读写都已经指向新集群旧集群已经没有新数据产生了增量同步留着反而可能引入异常。4.3 客户端重连与集群拓扑感知问题这是整个切换过程中最容易翻车的点单独拿出来说。Redis Cluster的客户端尤其是Jedis和Lettuce启动时会通过CLUSTER SLOTS或CLUSTER NODES获取集群拓扑信息。如果你的应用连的旧集群地址切走业务流量后新集群虽然数据一样但客户端本地缓存的节点映射表还是旧集群的IP端口。之前操作的时候我直接把应用配置里的Redis地址改成新集群地址然后重启应用。结果发现有一部分应用实例在切换后的一段时间内还在往旧集群节点发送请求连接池里还保持着旧连接导致出现了大量连接超时。解决办法是切换前、切换中、切换后各做一次确认切换前确认应用侧Redis客户端版本支持动态刷新拓扑Lettuce的topologyRefresh配置或Jedis的cluster模式自动更新如果不支持切换后必须重启应用。切换中在配置中心改地址后旧的连接池会慢慢被淘汰但你可以提前把连接池的空闲超时缩短加快旧连接回收。切换后观察监控里是否还有到旧集群IP的请求。我这边切换完成后大概持续了30秒还有零星请求打在旧集群上30秒后全部消失。4.4 流量切换后的三大验证点切片切完后不能直接宣布成功我按照以下三个维度做了验证业务指标核心接口的P99、平均RT、错误率、Redis操作耗时对比切换前后各一小时的数据。如果有明显劣化立即回滚。数据写读验证起一个临时脚本对新集群做一轮“写-读-对比”测试确认新集群写入读取全链路OK。集群状态确认CLUSTER INFO返回的cluster_state:ok三个master的slot全部正常分配从节点都在connected状态。5. 迁移中踩过的坑复盘5.1 版本差异导致的RDB同步失败第一次跑redis-shake全量同步时任务启动几秒就报错日志里指向RDB解析失败。排查后发现旧集群RDB里有一个PROTO_VERSION字段跟新版本解析器不兼容的位具体来说是旧RDB中某个内部编码的字符串类型在新版本RDB解析逻辑里被当作未知类型处理了。解决方式是升级redis-shake到最新版本它内部会做RDB格式的兼容性处理把旧版RDB解析成命令再逐条写入目标端而不是直接搬运RDB文件。这里特别提醒如果新旧集群的Redis版本差距大于一个大版本优先升级redis-shake和redis-cli到最新版而不是降级你们的生产Redis。5.2 大key拖垮增量同步延迟全量同步完成后增量同步阶段我观察到延迟突然从秒级升高到分钟级。查redis-shake日志发现有一个大list key一直在被业务高频地push数据单条增量命令处理时间特别长。这个问题的根因是redis-shake的增量同步是逐命令回放的RPUSH一次推几千个元素处理这条命令就要花很长时间。我的缓解措施是让业务方临时调整了这个key的写入频率把一批几千个元素拆成多次小批量写入延迟立刻降回秒级。如果这种大key在你们业务里无法调整写入模式可以考虑在切换前对这类key加白名单先不完全同步等切换完成后做一次补偿同步。5.3 过期键与淘汰策略的玄学迁移后我发现一个新集群某个master的expired_keys指标涨得很快一开始以为是redis-shake同步过程导致的bug后来排查发现新集群的maxmemory-policy默认是noeviction而旧集群配置的是allkeys-lru。迁移后所有key带着各自的TTL进了新集群但内存淘汰策略不一样导致新集群在接近内存上限时某些在旧集群里本来会被LRU淘汰掉的key在新集群没有配置淘汰策略的情况下只能靠空间硬扛。这个坑的教训是集群迁移不只是迁数据Redis服务端配置也是“数据”的一部分。新集群所有跟内存、持久化、淘汰相关的配置必须和旧集群对齐后再开启流量。5.4 回滚方案里最容易被忽略的连接池问题我把回滚预案写好后模拟了一次“切换后3分钟内发现问题并回滚”的演练。回滚到旧集群地址时发现有几个应用实例的连接池已经彻底切到新集群了改回配置后没有触发连接重建还是连着新集群。后来在应用的Redis客户端配置里增加了连接池重启的接口调用回滚时通过运维平台的发命令通道强制所有实例刷新连接池才算彻底解决。这里实际的经验是回滚方案必须包含“强制客户端刷新连接”这一步不然你改了配置中心也没用。6. 收尾不止“下线旧集群”验证与监控重建6.1 下线前必须确认的三件事切换到新集群稳定运行三天后才开始考虑旧集群下线。下线前我确认了三件事旧集群确实没有读流量和写流量了。这个不但要看应用监控还要在旧集群上用MONITOR命令蹲10分钟确认没有任何业务命令进来。redis-shake的所有同步进程已经停止避免进程残留对旧集群做多余操作。旧集群的持久化数据做了一次完整备份RDB AOF手动触发存到冷备盘。虽然大概率用不上但万一新集群出问题至少还能把旧集群重新拉起来。6.2 监控指标对比与基线修正迁移完成后我把新集群的监控拉出来和旧集群的历史数据做了一次基线对比。重点看三类指标慢查询日志新集群的slowlog有没有出现旧集群没出现过的慢命令。内存碎片率和redis内存占用容器化部署带来的内存分配行为变化会影响mem_fragmentation_ratio需要重新调maxmemory和碎片整理参数。网络流量和连接数容器网络和物理网卡的吞吐上限不同要把告警阈值调低一些避免真正出问题时没触发告警。这三个指标让我发现了新集群一个比较严重的问题连接数比旧集群高出40%原因是容器平台默认给Redis实例配置了更短的空闲连接超时导致应用反复重连。最后我在容器侧调大了tcp-keepalive和timeout参数连接数才回归正常。写在最后的经验这次迁移完成之后一个很直观的收获是三节点Redis集群看起来规模不大但迁移方案设计的复杂度一点不比大规模集群低。所有方案都要围绕“数据不丢、业务不停”这两个目标来选而不是哪个工具名气大用哪个。redis-shake这套路线在我当时的条件下是最稳妥的。如果你下次也要做类似迁移我建议按这个顺序来走先理清新旧集群的版本和配置差异再定同步工具和同步模式切换前把校验脚本先跑起来最后把回滚方案当成主方案的一部分来准备。尤其是回滚方案很多迁移事故不是迁移过程翻车而是出了问题上不去旧集群最后变成两边都不落的僵局。希望大家都能平稳完成迁移少踩我踩过的这些坑。
先说结论Redis集群做“三节点到三节点”的迁移难点从来不在数据拷贝而在于怎么让业务无感知、数据不丢失、回滚有退路。我上个月刚做完一个线上生产环境的同构集群迁移旧集群三台物理机新集群三台容器化部署从方案选型到最终切换花了整整一周。这期间踩了不少坑也把几条常规迁移路线都过了一遍最后形成的这套流程在流量高峰期完成了无缝过渡写下来做个完整复盘。如果你也遇到机房搬迁、云厂商切换、或者纯粹想把自建集群挪进容器平台这类需求这篇应该能帮你少走很多弯路。文章会覆盖方案对比、工具选型、参数调优、切换细节、以及几个只有真跑过迁移才会遇到的故障点。1. 为什么会有“三迁三”这种需求场景决定方案1.1 同构集群迁移比异构迁移更考验细节很多人一听“三节点到三节点”第一反应是节点数都一样直接在新机器上搭好集群把数据导过去不就行了但实际生产环境里“同构”指的只是节点数量相同不等于环境相同。我这次迁移的背景是一个自建的物理机Redis Cluster三个master节点版本是5.0.14。新集群是容器平台上的三个节点同样跑Redis Cluster但版本升级到了6.2.7而且新集群提前配置了三从架构每个master带一个slave。看起来都是三主节点但底层环境、版本、部署方式全变了。同构迁移的迷惑性就在这里因为你不需要重新设计拓扑所以容易低估工作量直接想拿RDB文件搬过去。但一旦涉及到版本跨代、部署形态变化、客户端连接方式调整光靠RDB文件恢复是远远不够的。1.2 无缝过渡的两个核心指标数据零丢失与业务零感知在定方案之前我和团队先明确了两个硬指标数据零丢失迁移过程中写入Redis的数据不能丢也就是说不能用“停服备份再恢复”这种简单粗暴的方式。业务零感知客户端连接不需要改代码、不需要重启应用切换过程中接口不能出现明显超时或报错。这两个指标看着容易实际上已经把“停机迁移”这条路堵死了。剩下的方案只有两条路线一条是增量同步 快速切换准无缝另一条是业务双写 最终切换真无缝。两条路线我都仔细梳理了下文会逐一说清取舍。还有一个隐性问题值得提前强调Redis Cluster的客户端是有拓扑感知的切换集群后如果客户端还连着旧节点的IP会出现大量MOVED重定向这个问题会在切换阶段专门处理后面详细讲。2. 四条常规迁移路线为什么最后选了同步工具2.1 临时主从挂载哨兵架构很顺cluster架构别扭最常见的无感迁移思路是“新旧搭主从”。如果是Redis Sentinel架构一主一从一哨兵之类在旧master上执行REPLICAOF指向新master同步完成后把哨兵指向新集群然后执行REPLICAOF NO ONE整个过程非常顺滑。但Redis Cluster架构下这套玩法会碰壁。Cluster模式下每个节点有固定的slot分配新节点的master身份、slot归属都要通过集群协议协商。如果你让新集群某个master执行replicaof指向旧集群的master在cluster-enabled状态下它会尝试在集群拓扑中重新协商身份很容易出现“自己把自己搞成孤儿节点”的诡异状态或者数据能复制过来但集群状态一直是cluster_state:fail。我实际测试了一下新节点执行replicaof指向旧集群节点后数据确实开始同步了但新集群因为某些slot归属跟旧集群的配置信息不一致集群状态直接变成fail。排查起来很费劲而且就算解决切换时的一连串cluster指令操作也远不如工具链成熟。所以这个方案直接放弃了——不是说完全不行而是坑太密性价比太低。2.2 MIGRATE逐key搬迁只适合小数据量Redis自带的MIGRATE命令可以把key从一个节点原子迁移到另一个节点Cluster模式下还能指定slot迁移。但它是逐key操作的每迁移一个key都要建立一次到目标节点的连接可以开pipeline优化但本质上还是一个key一个key搬。我这边旧集群有差不多800万key最大单key有几十MB用MIGRATE搬一轮算下来大概要跑十几个小时而且中间如果业务还在写新写入的key还得扫第二遍。更关键的是MIGRATE只搬数据和TTL不搬集群配置、不搬slot归属迁移完成后你还得手动做客户端拓扑切换。这个方案只适合那种总共几十万key、业务量很小的内部系统生产核心链路完全不适合。2.3 新节点入旧集群再reshard集群重构不等于迁移还有一条路是“让新节点加入旧集群用redis-cli --cluster reshard把slot迁过去最后把旧节点摘掉”。这个方案在技术上是可行的本质是集群扩容再缩容。但这里有个很现实的问题大规模reshard过程中Redis Cluster的slot迁移会触发大量的ASK重定向请求对客户端有一定兼容性要求而且迁移期间旧节点的内存和CPU都会飙升如果集群负载本来就高会直接影响线上延迟。再加上这个方案要求新旧节点网络能够互通双向在跨机房、跨云场景下基本不具备条件。我这次新旧集群不在同一网段虽然网络策略可以做双向打通但运维和安全那边流程很长最终还是放弃了这条需要网络深通的路线。如果你新旧集群在一个二层网络里这个方案倒是可以考虑但要严格在低峰期做。2.4 redis-shake全量增量可控性最强的组合最后我把目光落在redis-shake上。它是阿里云开源现在由tair团队维护的Redis数据同步工具支持standalone、cluster、proxy等多种形态之间互相同步核心能力就是全量同步基于RDB解析加增量同步基于PSYNC命令订阅后续写入。为什么选它而不是自己写脚本三个理由全量阶段它会把源RDB文件解析后按命令格式灌入目标端天然避开了RDB版本兼容问题而且会保留TTL。增量阶段它用PSYNC协议持续抓取源实例的新写入我可以在切换前让增量一直跑着把数据差距压到几百毫秒以内。它支持配置文件启动多个同步任务我可以为每个源master单独起一个同步进程做到“一对一”精确映射。这套组合让我能在新集群不停机的情况下先同步一个“和历史数据基本一致、且持续追平增量”的数据副本然后再挑一个业务低峰窗口做快速切换。这就是我要的“准无缝”方案。3. redis-shake迁移的落地过程与参数实证3.1 新集群的初始化细节新集群的部署我不过多展开但有几个前置条件必须做对否则后面同步过程会出幺蛾子新集群不要预先写任何业务数据保持三个master节点的数据都是空的。新集群的每个master都要提前配好对应的slave因为redis-shake同步的是master节点流量切换后如果新master没有从节点保护一旦宕机整个集群不可写。新集群的密码认证、AOF持久化都要先配置好。特别提醒开启AOF后再接收全量同步会比只靠RDB更稳但落地时要注意磁盘空间和fsync策略避免同步高峰期把磁盘IO打满。我这边新集群三个master的IP规划是10.0.8.11:6379、10.0.8.12:6379、10.0.8.13:6379旧集群是192.168.5.21:6379、192.168.5.22:6379、192.168.5.23:6379。redis-shake部署在旧的物理机上走内网连接新集群。3.2 全量同步阶段的参数调优redis-shake的配置文件是redis-shake.conf我用的是sync模式跑“全量增量”链路。核心配置如下source.type cluster source.address 192.168.5.21:6379;192.168.5.22:6379;192.168.5.23:6379 source.password old_password source.auth-type auth target.type cluster target.address 10.0.8.11:6379;10.0.8.12:6379;10.0.8.13:6379 target.password new_password target.auth-type auth sync.mode sync # 大key自动拆分阈值 advanced.big-key-threshold 104857600 # 单个pipeline的批量大小 advanced.pipeline-count-limit 8 # 日志级别 log.level info几个参数我在实际压测后调整过这里说说为什么advanced.big-key-threshold默认是102400字节约100KB。我这边有不少session缓存key比较大如果按默认阈值大量key都会走拆分路径线程调度会频繁切换干脆调大到100MB只有真正的大key才做拆分批处理。这里的教训是不要迷信默认值要根据你的key大小分布来设。advanced.pipeline-count-limit控制单次pipeline处理命令的数量。改小会让单批传输更快完成但总吞吐下降改大吞吐高但风险缓冲区变大。我摩擦了三四轮最终稳定在8比较合适。另外建议关闭advanced.resolve做DNS预解析在容器网络环境下的一些隐性问题直接走IP最稳。三个同步任务我是分三个进程跑的每个进程同步一个旧master到对应的新master。这里有个关键点三个进程的顺序性没有严格要求但最好错开启动时间避免三个全量同步任务同时冲进新集群导致新集群的内存和带宽被同时打满。全量同步阶段会持续多久我这边的数据量大概5GB左右800万key三个任务并行同步真实耗时大约10分钟。同步期间我盯着Redis的master_repl_offset和redis-shake日志里的sync进度数据确认三个源master的RDB快照都已经传输完成。3.3 增量追平如何判断可以切换全量同步完成后redis-shake会进入持续增量同步的状态此时判断“能不能切”的核心指标是增量延迟。在旧集群每个master上执行redis-cli -h 192.168.5.21 -p 6379 -a old_password INFO replication看slave_repl_offset或者直接在redis-shake日志里看rdb和offset的差距。我当时定的标准是增量延迟持续稳定在10秒以内才允许执行切换而且要在切换前连续观察5分钟。为什么会盯这个指标因为切换动作本身要花费一定时间改客户端配置、生效、重启连接池如果增量延迟已经数十秒甚至更大你切换期间新写入的数据其实还没到新集群一切过去就丢数据。增量的吞吐在低峰期基本追平我观察到的延迟范围在200ms到3秒之间浮动符合切换条件。3.4 一致性校验的三层方法增量追平后别急着切换。我在切换前做了一轮比较严格的数据一致性校验分三层第一层对比key数量redis-cli -h 192.168.5.21 -p 6379 -a old_password DBSIZE redis-cli -h 10.0.8.11 -p 6379 -a new_password DBSIZE这里要注意Cluster模式dbsize只统计单个节点所以三个master要分别对比。差异在100个key以内且主要是过期key的抖动属于正常范围。第二层抽样对比value我写了一个小脚本随机抽1万个key分别从新旧集群取value做hash对比。抽样范围我刻意覆盖了每个slot的key。这里推荐你用redis-cli的--bigkeys先梳理一下key的分布然后每个节点取top关键字段抽样比纯随机更有效。第三层检查TTL偏差Redis的key迁移后TTL字段必须保持和源key大致一致。redis-shake在同步时会把剩余TTL一起迁移但增量同步中客户端如果对某个key执行了EXPIRE这个更新也会同步过去。我抽了1000个带TTL的key对比偏差都在1秒以内符合预期。校验通过后我才开始设计切换流程。4. 切换窗口的设计从“准无缝”到“真无缝”4.1 双写方案真无缝的成本与收益严格来说“准无缝”方案在切换瞬间还是需要业务做一次极短时间的停止写入秒级。如果业务对“零写停止”有硬性要求那就得上双写方案在应用层把每次写操作同时发到旧集群和新集群等增量追平然后逐步把旧集群剥离。双写方案的收益是显而易见的写流量始终在新集群上打着切换瞬间完全没有写空洞。但成本也高得多应用层需要改数据访问层代码做双写逻辑这是一个上线后需要长期维护的额外复杂度。双写期间每一次写操作最慢的那个集群决定链路时延如果新集群比旧集群慢几毫秒整体RT就会被拉高。双写期间的分布式锁、事务、Lua脚本这类Redis特性实现起来非常痛苦。我这边业务对写入连续性的容忍度还好自动化任务在切换前做了暂停核心交易链路在低峰期本身写量不大所以我选择的是“增量追平短窗口暂停写”的准无缝方案。如果你需要的是“连日志里都看不出切换痕迹”那还是老老实实上双写。4.2 先切读后切写风险最小化的切换顺序我的切换动作分成了三步严格按“读→写→全量”的顺序来第一步切读流量。把读请求通过配置中心我这里用的是Nacos动态切到新集群观察新集群的读RT、命中率、错误率。因为Redis Cluster的读请求在master上处理新集群的数据已经和旧集群一致了读切换几乎是零风险的。第二步切写流量。写流量切换前我先在旧集群上执行CLUSTER READONLY不对写切换的关键是让应用连接串指向新集群地址。这里我分了两批先切20%的写流量观察5分钟再切剩余80%。整个过程没有遇到报错。第三步停增量同步。确认新集群数据稳定后停掉redis-shake的增量同步。因为此时所有读写都已经指向新集群旧集群已经没有新数据产生了增量同步留着反而可能引入异常。4.3 客户端重连与集群拓扑感知问题这是整个切换过程中最容易翻车的点单独拿出来说。Redis Cluster的客户端尤其是Jedis和Lettuce启动时会通过CLUSTER SLOTS或CLUSTER NODES获取集群拓扑信息。如果你的应用连的旧集群地址切走业务流量后新集群虽然数据一样但客户端本地缓存的节点映射表还是旧集群的IP端口。之前操作的时候我直接把应用配置里的Redis地址改成新集群地址然后重启应用。结果发现有一部分应用实例在切换后的一段时间内还在往旧集群节点发送请求连接池里还保持着旧连接导致出现了大量连接超时。解决办法是切换前、切换中、切换后各做一次确认切换前确认应用侧Redis客户端版本支持动态刷新拓扑Lettuce的topologyRefresh配置或Jedis的cluster模式自动更新如果不支持切换后必须重启应用。切换中在配置中心改地址后旧的连接池会慢慢被淘汰但你可以提前把连接池的空闲超时缩短加快旧连接回收。切换后观察监控里是否还有到旧集群IP的请求。我这边切换完成后大概持续了30秒还有零星请求打在旧集群上30秒后全部消失。4.4 流量切换后的三大验证点切片切完后不能直接宣布成功我按照以下三个维度做了验证业务指标核心接口的P99、平均RT、错误率、Redis操作耗时对比切换前后各一小时的数据。如果有明显劣化立即回滚。数据写读验证起一个临时脚本对新集群做一轮“写-读-对比”测试确认新集群写入读取全链路OK。集群状态确认CLUSTER INFO返回的cluster_state:ok三个master的slot全部正常分配从节点都在connected状态。5. 迁移中踩过的坑复盘5.1 版本差异导致的RDB同步失败第一次跑redis-shake全量同步时任务启动几秒就报错日志里指向RDB解析失败。排查后发现旧集群RDB里有一个PROTO_VERSION字段跟新版本解析器不兼容的位具体来说是旧RDB中某个内部编码的字符串类型在新版本RDB解析逻辑里被当作未知类型处理了。解决方式是升级redis-shake到最新版本它内部会做RDB格式的兼容性处理把旧版RDB解析成命令再逐条写入目标端而不是直接搬运RDB文件。这里特别提醒如果新旧集群的Redis版本差距大于一个大版本优先升级redis-shake和redis-cli到最新版而不是降级你们的生产Redis。5.2 大key拖垮增量同步延迟全量同步完成后增量同步阶段我观察到延迟突然从秒级升高到分钟级。查redis-shake日志发现有一个大list key一直在被业务高频地push数据单条增量命令处理时间特别长。这个问题的根因是redis-shake的增量同步是逐命令回放的RPUSH一次推几千个元素处理这条命令就要花很长时间。我的缓解措施是让业务方临时调整了这个key的写入频率把一批几千个元素拆成多次小批量写入延迟立刻降回秒级。如果这种大key在你们业务里无法调整写入模式可以考虑在切换前对这类key加白名单先不完全同步等切换完成后做一次补偿同步。5.3 过期键与淘汰策略的玄学迁移后我发现一个新集群某个master的expired_keys指标涨得很快一开始以为是redis-shake同步过程导致的bug后来排查发现新集群的maxmemory-policy默认是noeviction而旧集群配置的是allkeys-lru。迁移后所有key带着各自的TTL进了新集群但内存淘汰策略不一样导致新集群在接近内存上限时某些在旧集群里本来会被LRU淘汰掉的key在新集群没有配置淘汰策略的情况下只能靠空间硬扛。这个坑的教训是集群迁移不只是迁数据Redis服务端配置也是“数据”的一部分。新集群所有跟内存、持久化、淘汰相关的配置必须和旧集群对齐后再开启流量。5.4 回滚方案里最容易被忽略的连接池问题我把回滚预案写好后模拟了一次“切换后3分钟内发现问题并回滚”的演练。回滚到旧集群地址时发现有几个应用实例的连接池已经彻底切到新集群了改回配置后没有触发连接重建还是连着新集群。后来在应用的Redis客户端配置里增加了连接池重启的接口调用回滚时通过运维平台的发命令通道强制所有实例刷新连接池才算彻底解决。这里实际的经验是回滚方案必须包含“强制客户端刷新连接”这一步不然你改了配置中心也没用。6. 收尾不止“下线旧集群”验证与监控重建6.1 下线前必须确认的三件事切换到新集群稳定运行三天后才开始考虑旧集群下线。下线前我确认了三件事旧集群确实没有读流量和写流量了。这个不但要看应用监控还要在旧集群上用MONITOR命令蹲10分钟确认没有任何业务命令进来。redis-shake的所有同步进程已经停止避免进程残留对旧集群做多余操作。旧集群的持久化数据做了一次完整备份RDB AOF手动触发存到冷备盘。虽然大概率用不上但万一新集群出问题至少还能把旧集群重新拉起来。6.2 监控指标对比与基线修正迁移完成后我把新集群的监控拉出来和旧集群的历史数据做了一次基线对比。重点看三类指标慢查询日志新集群的slowlog有没有出现旧集群没出现过的慢命令。内存碎片率和redis内存占用容器化部署带来的内存分配行为变化会影响mem_fragmentation_ratio需要重新调maxmemory和碎片整理参数。网络流量和连接数容器网络和物理网卡的吞吐上限不同要把告警阈值调低一些避免真正出问题时没触发告警。这三个指标让我发现了新集群一个比较严重的问题连接数比旧集群高出40%原因是容器平台默认给Redis实例配置了更短的空闲连接超时导致应用反复重连。最后我在容器侧调大了tcp-keepalive和timeout参数连接数才回归正常。写在最后的经验这次迁移完成之后一个很直观的收获是三节点Redis集群看起来规模不大但迁移方案设计的复杂度一点不比大规模集群低。所有方案都要围绕“数据不丢、业务不停”这两个目标来选而不是哪个工具名气大用哪个。redis-shake这套路线在我当时的条件下是最稳妥的。如果你下次也要做类似迁移我建议按这个顺序来走先理清新旧集群的版本和配置差异再定同步工具和同步模式切换前把校验脚本先跑起来最后把回滚方案当成主方案的一部分来准备。尤其是回滚方案很多迁移事故不是迁移过程翻车而是出了问题上不去旧集群最后变成两边都不落的僵局。希望大家都能平稳完成迁移少踩我踩过的这些坑。
