编程 Valkey 9.1 深度实战：当 Redis 分支进化为开源缓存新霸主——从 BSD 许可证之争到异步 I/O 线程、百万 QPS 与生产级迁移完全指南（2026）

2026-06-18 20:57:03 +0800 CST views 4

Valkey 9.1 深度实战：当 Redis 分支进化为开源缓存新霸主——从 BSD 许可证之争到异步 I/O 线程、百万 QPS 与生产级迁移完全指南（2026）

摘要：2024 年 Redis 许可证变更震动了整个后端缓存生态。一年后，Linux 基金会托管的 Valkey 不仅没有沦为“备胎”，反而以 9.1.0 版本宣告了自己的独立演进路线。本文从许可证背景、核心架构、9.1 新特性、代码实战、性能调优到生产迁移，完整拆解 Valkey 为何值得你把它放进 2026 年的技术栈。

引言：缓存世界的“分家”事件
背景：Redis 许可证之变与 Valkey 的诞生
核心概念：Valkey 是什么，与 Redis 的关系
架构分析：从单线程到多线程 I/O 的演进
Valkey 9.1 新特性深度解析
代码实战：部署、集群、客户端与性能测试
性能优化：从配置到内存再到集群
生产级迁移：从 Redis 到 Valkey
总结与展望

一、引言：缓存世界的“分家”事件

如果你从 2015 年左右就开始写后端，Redis 几乎是你缓存层的默认答案。字符串、哈希、列表、集合、有序集合、Stream、Pub/Sub、Lua 脚本——这套 API 已经成了后端工程师的肌肉记忆。

但 2024 年 3 月，Redis 官方宣布从 BSD 三条款许可证切换到 RSALv2 + SSPLv1 的组合许可。这个决定的直接影响是：Redis 8.0 及以后的版本不再是你传统认知里的“开源软件”。对于云厂商、托管服务提供商以及大量依赖宽松许可证的企业来说，这意味着法律风险、合规审查和潜在的分支锁定。

开源社区的反应非常迅速。Linux 基金会联合 AWS、Google、Oracle、Ericsson、Snap、阿里巴巴、腾讯、字节跳动等巨头，基于 Redis 7.2.4 创建了 Valkey 分支，并承诺：永远开源，BSD 许可证，社区治理。

一年后的 2026 年 5 月 19 日，Valkey 发布了 9.1.0 稳定版。这不是一个简单的 bugfix 版本，而是 Valkey 独立演进路线上的一个重要节点：它开始拥有自己的 CVE 编号体系、自己的性能优化方向、自己的集群指标，甚至在某些场景下表现出了超越 Redis 7.2 的吞吐能力。

本文想回答三个问题：

Valkey 9.1 到底改了什么？值不值得升级？
从架构上看，它和 Redis 有什么本质区别？
如果你的生产环境还在跑 Redis 7.2 或更早版本，迁移到 Valkey 的成本和风险有多大？

二、背景：Redis 许可证之变与 Valkey 的诞生

2.1 许可证变更的时间线

2024 年 3 月：Redis 官方宣布许可证变更，Redis 7.2 成为最后一个宽松开源版本。
2024 年 3 月底：Linux 基金会宣布成立 Valkey 项目，初始代码基于 Redis 7.2.4。
2024 年 4 月：AWS ElastiCache、Google Memorystore、Oracle OCI Cache 等主要云厂商相继宣布支持 Valkey。
2025 年：Valkey 8.x 发布，引入多线程 I/O、异步 I/O 线程等关键性能改进。
2026 年 5 月 19 日：Valkey 9.1.0 发布，成为首个带有完整独立 CVE 体系和集群网络流量指标的稳定版本。

2.2 为什么许可证这件事很重要

很多开发者对许可证不敏感，觉得“不就是个协议吗”。但在企业级场景里，许可证直接决定了：

你能否把软件作为托管服务提供给客户；
你修改后的代码是否需要开源；
你的法务团队会不会在审计时把你拦下来。

RSALv2 和 SSPLv1 的核心限制在于：如果你把 Redis 作为云服务对外提供，就需要遵守额外的条款，甚至需要开放你的服务端代码。而 BSD-3-Clause 许可证几乎没有任何商业限制——你可以改、可以卖、可以闭源。

这就是为什么 Valkey 一出生就获得了几乎所有主流云厂商的支持。它不是“反 Redis”，而是“反锁定”。

2.3 Valkey 的核心承诺

Valkey 项目从第一天开始就定下了三条铁律：

永远开源：BSD-3-Clause，不接受任何 copyleft 或 source-available 协议。
社区治理：Linux 基金会托管，技术决策由社区投票，不受单一公司控制。
完全兼容：优先保持与 Redis 7.2.4 及之前版本的协议和命令兼容，降低迁移成本。

三、核心概念：Valkey 是什么，与 Redis 的关系

3.1 一句话定义

Valkey 是一个开源的、高性能的内存键值数据存储，支持缓存、消息队列、流处理、发布订阅等多种工作负载，并且与 Redis OSS 7.2 及之前版本保持高度兼容。

3.2 与 Redis 的关系

可以把 Valkey 理解为 Redis 7.2 的“开源精神续作”。它们的关系类似于：

MariaDB vs MySQL：MariaDB 是 MySQL 被 Oracle 收购后社区的分支，逐渐走出了自己的路。
LibreOffice vs OpenOffice：LibreOffice 是 OpenOffice.org 的社区分支。

Valkey 的代码库最初来自 Redis 7.2.4，但现在已经分化出了自己的路线图。比如：

Valkey 8.0 引入了 异步 I/O 线程（Async I/O Threads） 和 数据预取（Data Prefetching），单节点性能目标提升到每秒百万级请求。
Valkey 9.1 引入了 集群总线网络流量指标 和 增量页面释放（incremental page release），解决了 Redis 社区长期存在的 rehash 延迟尖刺问题。

3.3 兼容到什么程度

对于绝大多数应用来说，迁移到 Valkey 几乎是“换镜像、重启服务”那么简单：

协议层面：完全兼容 RESP2/RESP3。
客户端层面：所有 Redis 客户端（redis-py、Jedis、Lettuce、go-redis、ioredis 等）都可以直接连接 Valkey。
命令层面：Valkey 9.1 支持 Redis 7.2 的所有命令，并增加了少量自己的扩展。
数据层面：RDB 和 AOF 文件格式兼容，可以直接加载 Redis 的持久化文件。

唯一的例外是：如果你用到了 Redis 8.0 之后新增的命令或模块，那 Valkey 可能不支持。但对于 99% 的存量系统来说，这不构成问题。

四、架构分析：从单线程到多线程 I/O 的演进

4.1 经典 Redis 的单线程模型

Redis 6.0 之前，网络 I/O 和命令执行都在一个线程里完成。这个设计的优点是：

没有锁竞争，代码简单；
单条命令的原子性天然保证；
时序可预测，延迟低。

缺点是：

单核 CPU 成为瓶颈；
网络 I/O 密集场景下，CPU 大量时间花在 read/write 系统调用上；
无法充分利用现代多核服务器。

4.2 Valkey 的多线程 I/O 模型

Valkey 8.0 开始引入的多线程 I/O，思路非常清晰：把网络 I/O 从主线程剥离出去，让主线程专注于命令执行。

┌─────────────────────────────────────────────────────────────┐
│                       Valkey 进程                            │
│  ┌──────────────┐   ┌──────────────┐   ┌──────────────┐    │
│  │ I/O Thread 1 │   │ I/O Thread 2 │   │ I/O Thread N │    │
│  │  read/write  │   │  read/write  │   │  read/write  │    │
│  └──────┬───────┘   └──────┬───────┘   └──────┬───────┘    │
│         │                  │                  │             │
│         └──────────────────┼──────────────────┘             │
│                            ▼                                │
│                  ┌──────────────────┐                      │
│                  │   Main Thread    │                      │
│                  │ command execute  │                      │
│                  └──────────────────┘                      │
└─────────────────────────────────────────────────────────────┘

I/O 线程负责：

从 socket 读取客户端请求；
解析 RESP 协议；
将命令放入队列；
把主线程处理完的响应写回 socket。

主线程负责：

执行命令；
维护数据结构；
处理持久化、过期、复制等后台任务。

这种设计的核心好处是：命令执行仍然保持单线程，因此不会出现多线程并发修改数据结构的问题；同时网络 I/O 可以并行处理，显著提升了吞吐。

4.3 异步 I/O 线程与数据预取

Valkey 8.0 还引入了异步 I/O 线程和预取机制。简单理解：

异步 I/O 线程：在命令执行前，I/O 线程可以并行读取 key 对应的数据，减少主线程等待内存访问的时间。
数据预取：基于访问模式预测，提前把可能用到的 key 加载到 CPU cache 附近，降低内存访问延迟。

这套机制对 latency-sensitive 的场景非常有用，比如高频交易系统、实时推荐、在线游戏中的状态同步。

4.4 集群架构

Valkey 的集群模式和 Redis Cluster 基本一致：

数据分片到 16384 个 slot；
每个 master 可以有多个 replica；
节点间通过 cluster bus 通信；
支持自动故障转移。

Valkey 9.1 新增了一个非常有用的指标：cluster bus 网络流量统计。以前排查集群网络问题时，你只能靠 iftop 或 tcpdump 猜；现在可以直接通过 INFO cluster 看到总线收发了多少字节。

4.5 持久化机制

Valkey 支持两种持久化方式，以及一种混合模式：

RDB（Snapshot）：定时全量快照，恢复速度快，但可能丢数据。
AOF（Append Only File）：记录每条写命令，数据安全性高，但文件大、恢复慢。
RDB + AOF 混合：AOF 重写时把当前数据以 RDB 格式写入，后续增量以命令追加，兼顾速度和安全性。

Valkey 9.1 还改进了混合持久化的稳定性，并修复了若干 RDB 序列化相关的边界 case。对于金融级场景，建议开启 appendonly yes 并配置 appendfsync everysec。

4.6 内存分配器与延迟敏感型优化

Valkey 默认使用 jemalloc 作为内存分配器。jemalloc 相比 glibc 的 ptmalloc 有两大优势：

减少内存碎片：jemalloc 采用按 size-class 分配的策略，长期运行后内存碎片更少；
更好的多核扩展性：每个 CPU 核心有独立的 arena，减少锁竞争。

在 Valkey 的配置中，你可以通过 activedefrag yes 开启主动碎片整理，对于长生命周期的缓存实例非常重要。

另外，Valkey 还提供了 lazyfree-lazy-eviction yes 和 lazyfree-lazy-expire yes 两个选项，让大 key 的淘汰和过期在后台线程异步执行，避免阻塞主线程。如果你的业务里有大哈希、大列表或大字符串，建议打开这两个开关。

最后，关于延迟优化，还有几个容易被忽视的点：

hz 10：控制后台任务执行频率，默认 10 次/秒。对于大 key 较多的场景，可以适当提高到 50~100，但会增加 CPU 占用。
dynamic-hz yes：让 Valkey 根据客户端连接数自动调整 hz，连接多时自动增加后台任务频率。
timeout 0 vs timeout 300：保持长连接可以减少 TCP 握手开销，但要配合 tcp-keepalive 防止僵尸连接。

五、Valkey 9.1 新特性深度解析

2026 年 5 月 19 日发布的 Valkey 9.1.0，是一个“LOW urgency”的稳定版本——意思是升级不紧迫，但值得升级。它的改动集中在三个方向：安全修复、可观测性增强、性能与稳定性优化。

5.1 安全修复：三个 CVE

Valkey 9.1.0 修复了三个高危 CVE，这是 Valkey 开始拥有独立安全编号体系的重要标志：

CVE-2026-23479：unblock client 流程中的 Use-After-Free。
CVE-2026-25243：RESTORE 命令中的非法内存访问。
CVE-2026-23631：全量同步期间与 yield Lua/function 执行并发时的 Use-After-Free。

前两个是客户端交互路径上的内存安全问题，最后一个则是在复制和脚本执行交叉场景下的竞态条件。对于生产环境来说，这三个 CVE 虽然不一定会被远程利用，但都属于“已知风险”，建议尽快修复。

5.2 集群总线网络流量指标

这是 Valkey 9.1 最有“生产感”的新特性之一。新增了 cluster_bus_messages_sent_bytes 和 cluster_bus_messages_received_bytes 两个指标，归属于 INFO cluster 输出。

# INFO cluster
cluster_state:ok
cluster_slots_assigned:16384
cluster_slots_ok:16384
cluster_slots_pfail:0
cluster_slots_fail:0
cluster_known_nodes:6
cluster_size:3
cluster_current_epoch:6
cluster_my_epoch:1
cluster_bus_messages_sent:1234567
cluster_bus_messages_received:1234567
cluster_bus_messages_sent_bytes:98765432
cluster_bus_messages_received_bytes:87654321

这个指标有什么用？

排查“集群抖动”：当某个节点频繁发布配置更新或故障探测时，总线流量会激增。
容量规划：在大规模集群里，cluster bus 本身会占用不少带宽，这个指标能帮你估算交换机规格。
监控告警：可以设置基线，比如“总线发送字节数 5 分钟内增长 300%”就触发告警。

5.3 rehash 增量页面释放

这是 Valkey 9.1 性能改进里最有深度的一个。

Redis/Valkey 的哈希表在 key 数量变化时会进行 rehash（重新哈希），把数据从旧表迁移到新表。rehash 期间，内存使用会暂时增加，旧表占用的内存不会立即释放。在 Redis 的实现里，rehash 完成后，旧表内存会一次性归还给操作系统，这可能导致突发的延迟尖刺。

Valkey 9.1 的改进是：增量页面释放（incremental page release）。完成 rehash 后，系统不是一次性 munmap 整个旧表，而是分小批次逐步释放内存。这样可以把单次内存回收的延迟摊平，避免影响正在处理的请求。

对于需要稳定 P99 延迟的业务，这是一个非常实用的优化。

5.4 其他 bugfix

syncRead 在 EOF 时正确设置 errno 并传播到 conn->last；
GEOSEARCH BYPOLYGON 在非法 COUNT 参数下的内存泄漏修复；
streamTrim listpack delta 计算中的空指针处理；
RDMA benchmark 客户端断开时的崩溃修复；
valkey-benchmark 自身的内存泄漏修复。

这些修复大多发生在边界场景，但生产环境最怕的就是边界场景被触发。

5.5 可观测性全景：从 INFO 到 Prometheus

Valkey 9.1 的 INFO 命令输出非常丰富，主要分为 server、clients、memory、persistence、stats、replication、cpu、cluster、keyspace、commandstats 等模块。生产环境建议至少监控以下指标：

used_memory / used_memory_rss：内存使用与 RSS 比值，如果 RSS 远大于 used_memory，说明存在内存碎片或大量空闲页。
instantaneous_ops_per_sec：实时 QPS，用于容量规划和告警。
latency_tracking_percentiles：配合 CONFIG SET latency-tracking yes 使用，可以查看 P50/P99 延迟分布。
cluster_bus_messages_sent_bytes / cluster_bus_messages_received_bytes：Valkey 9.1 新增，集群网络排查利器。
slowlog：通过 SLOWLOG GET 捕获慢命令，定位性能瓶颈。

对于 Prometheus 监控，可以直接使用 valkey_exporter 或云厂商提供的托管 exporter。一个典型的 Grafana 看板应该包含：

QPS / 连接数 / 内存占用
主从复制延迟（master_repl_offset - slave_repl_offset）
命中率（keyspace_hits / (keyspace_hits + keyspace_misses)）
持久化状态（rdb_last_save_time、aof_last_write_status）
集群分片健康状态（cluster_slots_ok / cluster_slots_assigned）

这些指标 combined，才能构成一个完整的 Valkey 可观测体系，而不是只看 "QPS 高不高"。

六、代码实战：部署、集群、客户端与性能测试

6.1 单节点 Docker 部署

最简单的方式是用官方镜像：

docker run --rm -p 6379:6379 valkey/valkey:9.1.0

生产环境建议用 Docker Compose：

version: '3.8'

services:
  valkey:
    image: valkey/valkey:9.1.0-alpine
    container_name: valkey-single
    ports:
      - "6379:6379"
    volumes:
      - ./valkey.conf:/usr/local/etc/valkey/valkey.conf
      - valkey-data:/data
    command: ["valkey-server", "/usr/local/etc/valkey/valkey.conf"]
    restart: unless-stopped

volumes:
  valkey-data:

对应的 valkey.conf：

bind 0.0.0.0
port 6379
protected-mode no
appendonly yes
appendfsync everysec
tcp-keepalive 300
maxmemory 2gb
maxmemory-policy allkeys-lru

启动：

docker compose up -d

6.2 基本命令测试

# 连接
valkey-cli -h localhost -p 6379

# 字符串
SET user:1001 "{"name":"三哥","level":42}" EX 3600
GET user:1001
TTL user:1001

# 哈希
HSET product:2001 name "机械键盘" price 899 stock 120
HGETALL product:2001
HINCRBY product:2001 stock -1

# 列表（用作队列）
LPUSH queue:orders "order_001"
LPUSH queue:orders "order_002"
BRPOP queue:orders 5

# 流
XADD events:clicks * url /home user_id 1001
XREAD COUNT 1 STREAMS events:clicks $

6.3 使用 Python 客户端

redis-py 可以直接连 Valkey：

import redis
import json

r = redis.Redis(
    host='localhost',
    port=6379,
    db=0,
    decode_responses=True,
    socket_keepalive=True,
)

# 字符串 + JSON
r.setex('user:1001', 3600, json.dumps({'name': '三哥', 'level': 42}))
data = json.loads(r.get('user:1001'))
print(data)

# 哈希
r.hset('product:2001', mapping={
    'name': '机械键盘',
    'price': 899,
    'stock': 120
})
print(r.hgetall('product:2001'))

# 列表（生产者）
r.lpush('queue:orders', 'order_003')

# 流
r.xadd('events:clicks', {'url': '/product/2001', 'user_id': 1001})

6.4 使用 Go 客户端

package main

import (
    "context"
    "fmt"
    "time"

    "github.com/redis/go-redis/v9"
)

func main() {
    ctx := context.Background()
    rdb := redis.NewClient(&redis.Options{
        Addr:         "localhost:6379",
        PoolSize:     20,
        MinIdleConns: 5,
        MaxRetries:   3,
        DialTimeout:  2 * time.Second,
        ReadTimeout:  1 * time.Second,
        WriteTimeout: 1 * time.Second,
    })

    err := rdb.Set(ctx, "go:key:1", "hello valkey", time.Hour).Err()
    if err != nil {
        panic(err)
    }

    val, err := rdb.Get(ctx, "go:key:1").Result()
    if err != nil {
        panic(err)
    }
    fmt.Println("val:", val)

    // 管道批量写入
    pipe := rdb.Pipeline()
    for i := 0; i < 1000; i++ {
        pipe.Set(ctx, fmt.Sprintf("batch:%d", i), i, time.Hour)
    }
    _, err = pipe.Exec(ctx)
    if err != nil {
        panic(err)
    }
}

6.5 三主三从集群搭建

# 创建 6 个节点
for i in {7000..7005}; do
  docker run -d --name valkey-$i \
    --net host \
    -v /data/valkey/$i:/data \
    valkey/valkey:9.1.0-alpine \
    valkey-server --port $i --cluster-enabled yes \
      --cluster-config-file nodes.conf \
      --cluster-node-timeout 5000 \
      --appendonly yes
 done

# 创建集群
valkey-cli --cluster create \
  127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 \
  127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 \
  --cluster-replicas 1

集群创建后，可以通过 valkey-cli -c -p 7000 连接，-c 参数会自动处理 MOVED 重定向。

6.6 性能基准测试

Valkey 自带 valkey-benchmark，用法和 redis-benchmark 完全一致：

# 单线程基准
valkey-benchmark -h localhost -p 6379 -t get,set -n 100000

# 多线程压测，模拟 50 并发
valkey-benchmark -h localhost -p 6379 -t get,set -n 1000000 -c 50 -P 16 --threads 4

# 只测 pipeline
valkey-benchmark -h localhost -p 6379 -t set -n 1000000 -c 100 -P 100

在本地笔记本上，单节点 Valkey 9.1 配合 io-threads 4 通常能跑到 50 万 ~ 80 万 QPS；在服务器上，开启异步 I/O 和数据预取后，百万 QPS 并不罕见。

七、性能优化：从配置到内存再到集群

7.1 多线程 I/O 配置

# 开启 4 个 I/O 线程
io-threads 4
# 让 I/O 线程也处理写请求
io-threads-do-reads yes

注意：

I/O 线程数不要超过 CPU 核心数；
对于短命令高并发场景，多线程收益最大；
如果命令本身很重（比如大型 HGETALL、复杂的 Lua），多线程收益会下降。

7.2 内存优化

# 设置最大内存
maxmemory 8gb
# 淘汰策略
maxmemory-policy allkeys-lru

# 对大型字符串开启 ziplist/listpack 压缩（默认已启用）
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
zset-max-ziplist-entries 128
zset-max-ziplist-value 64

7.3 持久化优化

如果允许少量数据丢失，可以关闭 AOF 或只使用 RDB：

appendonly no
save 900 1
save 300 10
save 60 10000

如果需要强一致：

appendonly yes
appendfsync always
# 注意：always 会显著降低写入吞吐

7.4 集群优化

合理规划 key：避免跨 slot 的批量操作（MGET/MSET），尽量用 hash tag 把相关 key 放在同一节点。
控制 cluster-node-timeout：默认 15 秒太长，生产建议 3~5 秒。
监控 cluster bus 流量：Valkey 9.1 新增的 cluster_bus_messages_sent_bytes 指标要重点看。
避免大规模集群：单个 Valkey 集群建议不超过 100 个节点，节点过多会导致 cluster bus 广播风暴。

7.5 慢查询优化

slowlog-log-slower-than 10000
slowlog-max-len 128

配合 SLOWLOG GET 分析慢命令，常见问题包括：

对超大 key 执行 HGETALL、LRANGE 0 -1；
未使用 pipeline 的循环单条写入；
复杂的 Lua 脚本阻塞主线程。

7.6 客户端连接池与网络优化

Valkey 服务端再快，客户端乱用也会把性能拖垮。几个关键原则：

连接池大小：不要每个请求新建连接。对于 redis-py，建议 max_connections=50，min_connections=10；go-redis 建议 PoolSize=20 起步。
Pipeline：批量写入必须用 pipeline，不要把 1000 次 SET 拆成 1000 个 RTT。
Pipeline 长度：单条 pipeline 不要太长，一般 100~1000 条命令为宜。太长会阻塞服务端，太短无法摊平 RTT。
TCP 参数：开启 TCP_NODELAY 和 TCP_KEEPALIVE，避免 Nagle 算法导致的延迟。
连接复用：长连接优于短连接。对于 Node.js 的 ioredis，设置 keepAlive: 30000。

一个典型的 go-redis 优化配置：

rdb := redis.NewClient(&redis.Options{
    Addr:         "valkey.internal:6379",
    PoolSize:     50,
    MinIdleConns: 10,
    MaxRetries:   3,
    DialTimeout:  2 * time.Second,
    ReadTimeout:  1 * time.Second,
    WriteTimeout: 1 * time.Second,
    PoolTimeout:  1 * time.Second,
})

7.7 基准测试的方法论

很多人跑 valkey-benchmark 只看一个数字，但真正的性能测试应该分层：

单命令测试：GET/SET 单独跑，确认硬件基础吞吐。
混合负载测试：按业务真实比例混合 GET/SET/HGET/HSET/LPUSH/BRPOP 等。
大 key 测试：模拟 1MB 级别的 value，确认内存和网络瓶颈。
长尾延迟测试：跑 10 分钟以上，观察 P99 和最大延迟。
持久化测试：开启 AOF always 再跑一遍，看写入性能下降多少。
故障测试：kill 掉一个主节点，观察故障转移时间和客户端重连行为。

只有经过这种分层测试，你才能说“我们的 Valkey 集群能扛住 X 万 QPS”。

八、生产级迁移：从 Redis 到 Valkey

8.1 迁移前的检查清单

确认 Redis 版本：Valkey 9.1 兼容 Redis 7.2 及之前的命令和数据格式。
检查模块：如果你用了 Redis Modules（RediSearch、RedisJSON、RedisGraph 等），需要确认 Valkey 是否有替代方案。
检查客户端：主流客户端都兼容，但老旧客户端可能需要升级。
检查持久化文件：RDB/AOF 可以直接被 Valkey 加载。
制定回滚方案：保留旧集群一段时间，出问题随时切回。

8.2 三种迁移方案

方案 A：停机迁移（最简单）

适用于可以接受分钟级停机的业务：

停止 Redis 写入；
执行 BGSAVE 生成 RDB；
把 RDB 复制到 Valkey 节点；
启动 Valkey 并加载 RDB；
切换应用连接到 Valkey。

方案 B：双写迁移（零停机）

适用于不能停机的业务：

部署 Valkey 集群作为新缓存层；
修改应用，对 Redis 和 Valkey 同时写入，读仍然走 Redis；
运行一段时间（比如 24 小时），让热数据自然填充 Valkey；
逐步把读流量切到 Valkey；
确认稳定后，停掉 Redis 写入，下线 Redis。

方案 C：基于主从复制的迁移

Redis 7.2 是最后一个开源版本，Valkey 可以作为它的 replica 同步数据：

# 在 Valkey 节点上执行
valkey-cli --cluster replicate <redis-master-node-id>

注意：因为 Valkey 9.1 和 Redis 后续版本在复制协议上可能有差异，这种方案只建议从 Redis 7.2 迁移时使用。

8.3 迁移后的验证

# 检查节点信息
valkey-cli INFO server
valkey-cli INFO replication
valkey-cli INFO cluster

# 检查 key 数量
valkey-cli DBSIZE

# 检查延迟
valkey-cli --latency -h localhost -p 6379

# 跑一轮基准测试
valkey-benchmark -h localhost -p 6379 -n 100000 -c 50

8.4 常见坑

MODULE 命令缺失：Valkey 默认不带 RediSearch/JSON，需要找替代或自行评估。
CLIENT ID / CLIENT INFO 输出差异：部分监控脚本依赖的字段可能有变化。
集群模式下的 slot 迁移：确保迁移工具支持 Valkey 的集群协议。
AOF 文件兼容：虽然格式兼容，但如果 Redis 用了特殊的重写格式，建议先转成 RDB 再导入。

8.5 一个可落地的迁移脚本模板

下面是一个基于 RDB 的停机迁移脚本模板，适合中小规模业务：

#!/bin/bash
set -euo pipefail

OLD_REDIS_HOST=${OLD_REDIS_HOST:-redis.old.internal}
NEW_VALKEY_HOST=${NEW_VALKEY_HOST:-valkey.new.internal}
RDB_PATH=/backup/redis_to_valkey.rdb

echo "[1/5] 停止应用写入..."
# 这里可以调用你的应用开关，或者把应用切到只读模式
# curl -X POST http://app.internal/maintenance-on

echo "[2/5] 在旧 Redis 上执行 BGSAVE..."
redis-cli -h $OLD_REDIS_HOST BGSAVE
# 等待 RDB 生成完成
while [ ! -f /var/lib/redis/dump.rdb ]; do
  sleep 1
done

echo "[3/5] 复制 RDB 到新 Valkey 节点..."
scp /var/lib/redis/dump.rdb root@$NEW_VALKEY_HOST:$RDB_PATH

echo "[4/5] 启动 Valkey 并加载 RDB..."
ssh root@$NEW_VALKEY_HOST <<'REMOTE'
  docker stop valkey-new || true
  rm -f /data/valkey/dump.rdb
  cp $RDB_PATH /data/valkey/dump.rdb
  docker start valkey-new
  sleep 3
  docker exec valkey-new valkey-cli INFO server
REMOTE

echo "[5/5] 切换应用连接串到 Valkey..."
# 更新配置中心或环境变量，然后重启应用
# kubectl set env deployment/app VALKEY_HOST=valkey.new.internal

echo "迁移完成，请观察 30 分钟业务指标。"

这个脚本只是一个起点，真正上线前一定要：

在 staging 环境完整演练；
准备回滚脚本，能在 5 分钟内切回旧 Redis；
对 RDB 文件做 checksum 校验，防止传输损坏。

8.6 迁移后的监控清单

迁移不是把数据搬过去就完事了。上线后的前 7 天，建议每天检查：

连接数是否异常：应用连接池配置是否正确，有没有泄漏。
命中率变化：如果命中率下降，可能是双写阶段数据未充分预热。
延迟分布：对比迁移前后 P50/P99 延迟，确认没有退化。
持久化状态：AOF 重写是否按时完成，RDB 是否生成成功。
集群健康：如果是集群模式，检查 cluster_state 是否为 ok，slot 是否全部分配。
总线流量：Valkey 9.1 新增的 cluster bus 字节指标，观察是否有异常广播。

建议把以上指标做成 Grafana 看板，并设置合理的告警阈值。迁移后第一周不要放松警惕，这是问题最容易暴露的窗口期。

九、总结与展望

Valkey 9.1 的发布，标志着这个 Redis 分支已经走出了“备胎”阶段，开始形成自己的技术节奏。

它的核心优势可以总结为：

许可证安全：BSD-3-Clause，永远不会被单一公司锁定。
性能持续提升：多线程 I/O、异步 I/O、数据预取、增量页面释放，让单节点吞吐和延迟表现越来越好。
生态广泛支持：AWS、Google Cloud、Azure、阿里云、腾讯云、字节跳动等大厂都在支持或提供托管服务。
迁移成本低：协议、客户端、命令、持久化文件都兼容，几乎可以做到“无缝替换”。

但 Valkey 也面临挑战：

生态追赶：Redis Modules 生态（搜索、JSON、时序、向量）仍需要时间建立 Valkey 原生替代。
品牌认知：很多开发者 still 把 Redis 当作默认选项，Valkey 需要更多时间和成功案例。
路线图不确定性：作为一个社区项目，它的长期演进速度取决于贡献者和赞助商投入。

2026 年的建议

如果你是以下场景，强烈建议把 Valkey 纳入选型：

正在新建缓存/消息队列/实时状态服务；
正在使用 Redis 7.2 或更早版本，且对许可证变更感到不安；
希望避免被单一云厂商的 Redis 托管服务锁定；
对性能有极致追求，愿意尝试多线程 I/O 和预取机制。

如果你重度依赖 Redis Modules（比如 RediSearch、RedisJSON、RedisTimeSeries、RedisGraph），那迁移前需要先做 PoC，确认功能覆盖度。

总的来说，Valkey 不是 Redis 的“复制品”，而是 Redis 精神在开源社区里的延续。2026 年的后端工程师，应该对 Valkey 有基本了解，并在合适的场景下把它作为首选缓存方案。

参考链接

Valkey 官网：https://valkey.io/
Valkey GitHub：https://github.com/valkey-io/valkey
Valkey 9.1.0 Release Notes：https://github.com/valkey-io/valkey/releases/tag/9.1.0
Linux Foundation 公告：https://www.linuxfoundation.org/press/valkey

本文基于 Valkey 9.1.0 稳定版撰写，部分配置和性能数据在不同硬件环境下会有差异，生产环境请以实测为准。

复制全文生成海报 Valkey Redis 缓存开源 BSD Linux基金会数据库后端性能优化云原生