运行状态下如何高效更新Redis数据库且不中断查询服务

这类要求更新全程不中断查询、最终数据与新数据集完全一致的全量更新场景，有多个生产验证过的成熟实现，完全不需要在服务内存加载全量键做比对，内存开销极低。

方案1：版本前缀双写+原子切换（通用性最强，集群/单机都能用） #

这是最推荐的方案，逻辑简单、一致性有保障：

• 给所有业务键增加可切换的版本前缀，比如初始上线时所有键格式为v1:{业务键名}，单独存一个固定keysys:current_version记录当前生效的版本号，初始值为1。消费端查询时先读取当前版本号，拼接前缀后再查实际业务键，版本号可以在消费端本地做秒级缓存降低开销。
• 触发全量更新时，先把新版本号递增为2，将新字典的所有键值对全部写入v2:{业务键名}前缀的键空间，写入过程完全不影响v1前缀的线上读请求，消费端无感知。写入时可以用pipeline、MSET等批量命令提升效率，写完后抽样校验数据完整性，确认新数据集全部写入成功。
• 校验完成后，原子修改sys:current_version的值为2，所有消费端后续查询会自动读取v2前缀的新数据，切换过程无中间不一致状态。如果消费端有版本号本地缓存，可以在切换后主动发一次缓存失效通知，把切版本的感知时间降到毫秒级。
• 切换完成后，后台异步用SCAN命令增量遍历所有v1前缀的旧键，控制删除速率（比如每次扫1000个键，间隔几毫秒删一批），避免打满Redis CPU/带宽，全部删完后本次更新结束。

方案2：SWAPDB原子切库（适合单实例部署场景） #

如果是单Redis实例部署、不想改造键的前缀逻辑，可以用Redis原生的多DB+原子切库能力，逻辑和版本前缀方案一致：

• 线上业务默认读0号DB，触发更新时，找一个空闲的DB（比如1号DB），先确认DB为空，再把新字典的全量数据批量写入1号DB，写入过程完全不影响0号DB的线上查询。
• 写完校验完新数据完整性后，执行SWAPDB 0 1命令，这个命令是Redis原生原子执行的，执行瞬间0号DB和1号DB的数据会互换，之后业务读0号DB拿到的就是全新数据集，无任何中间状态，消费端完全无感知。
• 切换完成后，执行FLUSHDB ASYNC（Redis 4.0+支持，异步清空不堵主线程）清空现在存着旧数据的1号DB即可，全程不需要做新旧键比对。

• 注意：Redis集群模式不支持多逻辑DB，这个方案只能在单实例、主从、哨兵架构下用，同时要确认业务代码没有硬编码DB编号。

方案3：SCAN增量遍历删旧键（适合无改造空间的存量场景） #

如果现有业务已经上线、没法改键前缀也没法用多DB，可以直接在原键空间操作，不需要加载全量旧键到内存：

• 更新开始前，先把新字典的所有键写入一个临时Redis集合tmp:new_keys，用SADD批量写入即可，这个集合存在Redis侧，不占用业务服务内存。
• 直接把新字典的所有键值对批量写入原线上键空间，已存在的键会被覆盖为新值，不存在的键会直接新增，这个过程中消费端查询要么拿到旧值要么拿到新值，不会出现查询空的情况。
• 写入完成后，用SCAN命令以游标增量遍历整个键空间，每扫出一批键，就用SISMEMBER判断这个键是否存在于tmp:new_keys集合中，不存在就直接删除。遍历过程设置合理的count值（比如每次取1000个键），控制删除速率，避免影响线上请求。
• 全量遍历删除完成后，删掉临时集合tmp:new_keys，更新结束。

• 注意：这个方案适合更新期间业务侧只有查询、没有写入的场景，如果更新过程中业务会主动写键，可能出现误删，优先选择前两个原子切换方案。

三个方案都不需要在服务内存中留存全量新旧键集合做比对，内存开销可以忽略，前两个原子切换的方案RTO几乎为0，是行业内这类全量更新场景的标准实现。

内容的提问来源于stack exchange，提问作者Golden