Valkey 9.1.0 深度实战：当开源社区接管 Redis 的遗产——从许可证风暴到 Linux 基金会治理、从无锁 IO 线程到 SIMD 哈希优化的生产级完全指南（2026）

写在前面

2024 年 3 月，一条消息震动了整个开源数据库社区：Redis Ltd. 宣布将 Redis 从 BSD 许可证改为 RSALv2/SSPLv1 双许可证。这意味着什么？意味着 AWS、Google Cloud、阿里云等云厂商不能再免费地将 Redis 作为托管服务提供给用户——除非它们签署商业授权协议。

一个运行了超过 14 年、拥有超过 8 万 GitHub Stars、被全球数百万应用依赖的开源项目，一夜之间不再是"开源"的。

开源社区的反击来得比任何人预期的都快。不到两周，Linux 基金会牵头，AWS、Google、Oracle、Ericsson、Snap 等技术巨头联合宣布：基于 Redis 7.2.4 的最后一个 BSD 版本进行 Fork，新项目命名为 Valkey。

两年后的今天，Valkey 已经走过了从 7.2 → 8.0 → 9.0 → 9.1 的完整演进路线。Valkey 9.1.0 于 2026 年 5 月 19 日正式发布，带来了数据库级访问控制、无锁 IO 线程队列、ARM NEON SIMD 哈希优化、增量 rehash 释放等一系列重量级特性。

本文将从五个维度深度剖析 Valkey 9.1.0：许可证风暴的来龙去脉、架构演进的核心突破、新特性的生产级实践、从 Redis 迁移的完整方案、以及 Valkey 与 Redis 的终极对决。

一、许可证风暴：Redis 为什么"背叛"开源？

1.1 从 BSD 到 RSALv2：一场蓄谋已久的商业转型

要理解 Valkey 的诞生，首先要理解 Redis 的许可证变更为什么引发了如此大的反应。

Redis 项目由 Salvatore Sanfilippo（antirez）于 2009 年创建，最初采用 BSD 3-clause 许可证。BSD 许可证被认为是"最自由"的开源许可证之一——你可以用它做任何事，包括商业用途、修改、分发，甚至闭源使用，唯一的要求是保留版权声明。

2015 年，antirez 因为项目维护压力过大，与 Redis Labs（后更名为 Redis Ltd.）达成合作，后者负责项目的商业化和企业级支持。最初一切正常，Redis Labs 也尊重了 BSD 许可证。

但转折点出现在 2018 年。Redis Labs 开始将其开发的某些模块（如 RediSearch、RedisJSON、RedisBloom）采用 SSPL（Server Side Public License）——这是一种"准开源"许可证，允许自由使用，但禁止作为云服务提供。

2024 年 3 月，Redis Ltd. 更进一步：将 Redis 核心本身也改为 RSALv2/SSPLv1 双许可证。这意味着，如果你是一家云服务提供商，想把 Redis 作为托管数据库服务提供给用户，你必须获得 Redis Ltd. 的商业授权——或者停止使用 Redis。

这不是许可证的"微调"，这是一次根本性的商业模式转型：从开源软件到 Source Available。

1.2 为什么社区反应如此剧烈？

核心原因有三点：

第一，信任崩塌。 Redis 是全球使用最广泛的内存数据库之一，被嵌入到无数个生产系统中。社区贡献者付出了超过 14 年的代码贡献，突然发现他们的工作成果被"锁"在了商业许可证后面。

第二，供应商锁定风险。 对于深度依赖 Redis 的企业来说，许可证变更意味着未来可能面临不可控的成本——如果你使用的是云厂商的 Redis 服务，云厂商要么支付授权费（最终转嫁给你），要么停止服务。

第三，先例效应。 如果 Redis 可以这样做，下一个会是谁？MongoDB、Elasticsearch 已经有过类似的许可证变更（分别改为 SSPL 和 SSPL/Elastic License），但 Redis 的影响力更大——它是 TIOBE 编程语言排行榜、DB-Engines 数据库排名中常年前十的选手。

1.3 Linux 基金会的迅速反应

2024 年 3 月 20 日，Redis 许可证变更的消息传出后不到 48 小时，Linux 基金会就宣布成立 Valkey 项目。创始成员包括：

• AWS：最大的 Redis 云服务提供商之一，贡献了大量代码和基础设施
• Google Cloud：GCP 的 Memorystore for Redis 需要一个开源替代方案
• Oracle：数据库巨头，对开源许可证问题高度敏感
• Ericsson：通信领域的技术领导者
• Snap：知名软件分发平台
• 以及腾讯、阿里云等中国科技公司的参与

Valkey 的核心承诺：

• 永远开源：BSD 3-clause 许可证，不可更改
• 社区治理：Linux 基金会托管，技术委员会（TSC）决策
• 100% 兼容：与 Redis 7.2.4 及之前的版本完全兼容

二、Valkey 架构演进：从 7.2 到 9.1 的技术突破

2.1 版本演进时间线

2024.03  Valkey 7.2.4 (Fork from Redis 7.2.4)
2024.09  Valkey 8.0 (6 个月后，首次独立演进)
2025.03  Valkey 8.1
2025.09  Valkey 9.0 (重大版本升级)
2026.05  Valkey 9.1.0 (最新稳定版)

从 Fork 到 9.1.0，Valkey 团队用不到两年时间完成了四个大版本的迭代——这比 Redis 在同等时间内的版本节奏快了几乎一倍。

2.2 Valkey 8.0：第一次独立飞跃

Valkey 8.0 是第一个真正意义上的"独立版本"，不再仅仅是 Redis 的兼容 Fork，而是开始走出自己的技术路线：

增强型 I/O 多线程：虽然 Redis 6.0 就引入了 I/O 多线程，但 Valkey 8.0 在此基础上进行了深度优化。通过改进线程间通信模型和 CPU 亲和性调度，在 16 vCPU 的 AWS 实例上达到了 119 万 RPS 的基准测试成绩。

双通道复制（Dual-Channel Replication）：这是 Valkey 首创的复制优化方案。传统的全量同步需要先生成 RDB 快照，再传输给新节点——这个过程是串行的，意味着新节点在 RDB 传输完成前无法接收增量数据。Valkey 8.0 的双通道复制可以同时传输 RDB 快照和实时复制流，大大缩短了节点上线时间。

/* Valkey 双通道复制的核心逻辑简化示意 */
void replicaStartFullSync(client *replica) {
    // 通道1: RDB 快照传输（后台线程生成 + 网络发送）
    startRDBBackgroundSave(replica->fd);
    
    // 通道2: 复制缓冲区实时同步
    // 新的写命令同时进入 replication backlog
    // replica 可以在接收 RDB 的同时接收增量数据
    replica->repl_state = REPL_STATE_RECEIVE_BGSAVE;
    
    // 传统的 Redis：只能等 RDB 传完才能开始增量同步
    // Valkey 8.0：RDB 和增量数据并行传输
}

实验性 RDMA 支持：Valkey 率先探索了 RDMA（Remote Direct Memory Access）技术。RDMA 允许一台机器直接访问另一台机器的内存，绕过操作系统内核和 TCP/IP 协议栈，实现微秒级网络延迟。这在超大规模集群（数百节点）的场景下有显著优势。

2.3 Valkey 9.0：架构重组的里程碑

Valkey 9.0 是一次"架构减法+性能加法"的重大升级：

Lua 脚本引擎模块化：这是 Valkey 9.0 最具前瞻性的架构变更。传统上，Redis/Valkey 的 Lua 脚本引擎（LuaJIT 或 Lua 5.1）是编译进核心的，与 Valkey 本体紧耦合。Valkey 9.0 将 Lua 脚本引擎变成了一个 Valkey Module，通过标准的 Module API 接入。

这意味着什么？意味着你可以在不修改 Valkey 核心代码的情况下，替换或升级 Lua 脚本引擎。理论上，你可以用 Python、JavaScript 甚至 WebAssembly 来替代 Lua 作为脚本语言——只要有人实现了对应的 Module。

/* Valkey 9.0 Lua 引擎模块化后的配置示例 */
# valkey.conf
# Lua 引擎现在是模块，可以加载/卸载
loadmodule /usr/lib/valkey/valkey-lua.so

# 独立的 Lua 配置
lua-enable-insecure-api no  # 安全默认关闭
lua-time-limit 5000         # 脚本超时 5 秒
lua-replicate-commands yes # 复制脚本效果而非脚本本身

CLUSTERSCAN 命令：在集群模式下，传统的 SCAN 命令只能扫描当前节点的 key。如果要在整个集群中查找满足特定模式的 key，你需要连接每个节点分别执行 SCAN。Valkey 9.0 引入了 CLUSTERSCAN 命令，一次调用即可扫描整个集群。

# 传统方式：需要逐节点扫描
valkey-cli -h node1:6379 --scan --pattern "user:*"
valkey-cli -h node2:6379 --scan --pattern "user:*"
valkey-cli -h node3:6379 --scan --pattern "user:*"
# 还需要处理跨节点的游标同步...

# Valkey 9.0 方式：一次搞定
valkey-cli CLUSTERSCAN 0 MATCH "user:*" COUNT 100

MSETEX 命令：批量设置多个 key 的过期时间。在实现分布式锁、会话管理等场景下，经常需要对多个 key 设置相同的过期时间。传统方式需要多次调用 EXPIRE，Valkey 9.0 的 MSETEX 一次原子操作搞定：

# 传统方式：三次网络往返
EXPIRE session:token1 3600
EXPIRE session:token2 3600
EXPIRE session:token3 3600

# Valkey 9.0：一次网络往返，原子操作
MSETEX 3600 session:token1 session:token2 session:token3

2.4 Valkey 9.1.0：性能优化的巅峰之作

Valkey 9.1.0 是本文的重点，它在保持 100% 兼容的基础上，对性能进行了多项深度优化：

三、Valkey 9.1.0 核心特性深度解析

3.1 无锁 IO 线程队列（Lock-Free IO Threading）

这是 Valkey 9.1.0 最大的性能亮点。

在 Valkey（以及 Redis）的 I/O 多线程模型中，主线程负责命令执行，I/O 线程负责网络读写。传统实现中，主线程和 I/O 线程之间的任务传递是通过 互斥锁保护的队列 实现的——每次主线程向 I/O 线程提交读写任务，或者 I/O 线程向主线程报告完成事件，都需要加锁和解锁。

在高并发场景下，这个锁会成为性能瓶颈。Valkey 9.1.0 的贡献者 @akashkgit 重新设计了 IO 线程通信模型，用 无锁队列（Lock-Free Queue） 替代了传统的互斥锁队列：

/*
 * Valkey 9.1.0 无锁 IO 线程通信模型（简化示意）
 * 
 * 传统模型:  mutex_lock(&queue_mutex); enqueue(task); mutex_unlock(&queue_mutex);
 * 新模型:   使用原子操作（CAS）实现 MPSC 无锁队列
 */

typedef struct {
    _Atomic(io_task_t*) head;  // 原子指针，多生产者安全
    io_task_t* tail;           // 单消费者（主线程），无需原子
} lf_queue_t;

// I/O 线程（多生产者）：入队
void lf_queue_push(lf_queue_t* q, io_task_t* task) {
    task->next = NULL;
    io_task_t* prev = atomic_exchange(&q->head, task);
    if (prev != NULL) {
        prev->next = task;  // 串接到链表尾部
    }
}

// 主线程（单消费者）：批量出队
io_task_t* lf_queue_drain(lf_queue_t* q) {
    // 交换为 NULL，一次取走所有任务
    return atomic_exchange(&q->head, NULL);
}

性能提升：在标准基准测试中，无锁 IO 线程模型带来了 8-17% 的吞吐量提升。在高核数（16+ vCPU）场景下提升更为显著，因为锁竞争随核数增加而加剧。

为什么这很重要？ 对于 Valkey 这样的单进程、多线程架构，线程间通信是性能的关键路径。在每秒百万级请求的场景下，即使每次锁操作只节省几十纳秒，累积起来也是可观的性能提升。

3.2 内嵌字符串阈值提升（64 → 128 字节）

Valkey 使用了一种叫做"嵌入字符串"的内存优化技术。当一个字符串的值足够短时（小于某个阈值），Valkey 不会单独分配内存来存储字符串内容，而是直接将字符串内容嵌入到 Valkey 对象（robj）结构体中。这消除了额外的内存分配开销和指针间接寻址。

Valkey 9.1.0 将这个阈值从 64 字节提升到 128 字节（贡献者 @Nikhil-Manglore）：

/*
 * 嵌入字符串阈值变更对内存布局的影响
 */

// Redis/Valkey 传统实现：阈值 64 字节
// robj 结构体大小约 56 字节
// 所以 robj + 内嵌字符串 ≈ 56 + 64 = 120 字节
// 当字符串 > 64 字节时：robj (56字节) + malloc指针(8字节) + SDS头部(3字节) + 字符串数据
// 需要额外的内存分配

// Valkey 9.1.0：阈值 128 字节
// robj + 内嵌字符串 ≈ 56 + 128 = 184 字节
// 更多的短字符串可以直接嵌入，减少 malloc 调用

// 影响：对于缓存大量短值的场景（如用户 token、短 ID、配置值）
// GET 命令的吞吐量提升约 30%！

30% GET 吞吐量提升！这是一个令人惊讶的数字。原因在于：Valkey 的典型工作负载中，GET 是最高频的操作。缓存应用中，绝大部分 value 都是短字符串（token、session ID、计数器值等），提升嵌入阈值意味着更多的 GET 操作可以直接从对象结构体中读取数据，避免了指针跟踪和潜在的缓存行未命中。

3.3 ARM NEON SIMD 哈希优化

Valkey 的集群模式使用 CRC16 算法将 key 映射到 16384 个 slot。在处理大量命令时，这个哈希计算会被频繁调用。Valkey 9.1.0 引入了 ARM NEON SIMD 指令优化（贡献者 @ahmadbelb），对 pvFind() 函数进行了加速：

/*
 * ARM NEON SIMD 优化 CRC16 哈希计算
 * 
 * 传统实现：逐字节计算 CRC16
 * NEON 优化：使用 128-bit SIMD 寄存器，同时处理 16 个字节
 * 
 * 性能提升：2-3x 加速（在 ARM 平台上）
 */

#include <arm_neon.h>

// NEON 加速的批量 key 哈希
uint16_t cluster_key_slot_neon(const char *key, size_t len) {
    // 使用 NEON 寄存器并行处理
    uint8x16_t data = vld1q_u8((const uint8_t*)key);
    // SIMD 加速的 CRC16 计算
    // ... (完整实现使用 NEON intrinsics)
    return crc16_result;
}

为什么重要？ 随着 ARM 架构在云服务器中的占比越来越高（AWS Graviton、阿里云倚天、华为鲲鹏等），这个优化在实际生产中有重要意义。在 ARM 实例上，集群模式的命令处理速度可以获得 2-3 倍的加速。

3.4 数据库级访问控制（Database-Level ACL）

Valkey 9.1.0-rc1 引入了数据库级访问控制（贡献者 @dvkashapov），这是对 Valkey ACL（Access Control List）系统的重大增强：

# 传统 Redis ACL：只能控制用户权限，不能限制到特定数据库
# 用户可以访问所有数据库（0-15）

# Valkey 9.1.0：数据库级访问控制
# 创建一个只能访问 DB1 的用户
ACL SETUSER analytics_user on >strong_password ~* &db1 +@read +@connection

# 创建一个只能访问 DB2 的应用用户
ACL SETUSER app_user on >app_secret ~* &db2 +@all -@dangerous

# 验证
AUTH analytics_user strong_password
SELECT 1  # 成功
SELECT 0  # 被拒绝！(error) NOPERM this user has no permissions to access the database
SELECT 2  # 被拒绝！

应用场景：在多租户场景中，不同租户的数据通常存储在不同的数据库中（DB0, DB1, ... DB15）。传统上，如果要让每个租户只能访问自己的数据库，需要在应用层做权限控制。Valkey 9.1.0 将这个能力下沉到了数据库层面，提供了更强的隔离保证。

3.5 增量 Rehash 释放

Valkey（以及 Redis）使用哈希表作为核心数据结构。当哈希表需要扩容或缩容时，会执行 rehash 操作——将数据从一个哈希表迁移到另一个。传统实现中，rehash 是增量执行的（每次处理一小部分 bucket），但在 rehash 完成后，旧哈希表的内存是一次性释放的。

在旧哈希表很大的情况下，一次性释放可能触发操作系统的内存回收机制，导致短暂的延迟尖峰。Valkey 9.1.0 引入了 增量页面释放（贡献者 @chzhoo），将旧哈希表的内存分批释放：

/*
 * 增量 Rehash 释放的原理
 * 
 * 传统实现:
 *   rehash 完成后 → free(old_ht) → 可能触发 madvise → 延迟尖峰
 * 
 * Valkey 9.1.0:
 *   rehash 完成后 → 每次释放若干页（4KB/16页）→ 平滑内存归还
 *   对延迟敏感的请求几乎无影响
 */

void incrementalRehashRelease(dict *d) {
    // 每次释放一部分旧哈希表的内存
    // 释放粒度: 一个或多个 OS 页面（通常 4KB）
    while (d->ht[0].rehash_release_pages > 0) {
        release_page(d->ht[0].table, d->ht[0].rehash_release_offset);
        d->ht[0].rehash_release_pages--;
    }
}

3.6 其他重要特性

四、生产级实战：从 Redis 迁移到 Valkey

4.1 迁移可行性评估

Valkey 与 Redis 7.2.4 及之前的版本 协议级兼容。这意味着：

• 所有标准的 Redis 命令都可以直接使用
• RESP（Redis Serialization Protocol）完全兼容
• RDB 文件格式兼容
• AOF 文件格式兼容
• 客户端库无需任何修改

不兼容的部分：

• Redis 8.0 新增的命令（如某些向量搜索命令）
• Redis Stack 模块（RediSearch、RedisJSON 等）——Valkey 不包含这些
• Redis 的 Function 特性（Valkey 仍使用 Lua 脚本）

4.2 迁移步骤：生产级完整方案

# 步骤 1：在测试环境部署 Valkey 9.1.0
docker run --name valkey-test -p 6380:6379 -d valkey/valkey:9.1.0

# 步骤 2：使用 valkey-cli 验证兼容性
# 导出 Redis 数据
redis-cli --rdb /tmp/redis_dump.rdb

# 导入到 Valkey
valkey-cli --pipe < /tmp/redis_dump.rdb

# 或者使用在线复制迁移
# 让 Valkey 作为 Redis 的 replica，同步完成后再切换
# valkey.conf:
# replicaof redis-master 6379

# 步骤 3：运行兼容性测试
# 对比 Redis 和 Valkey 的命令返回值
./run_compatibility_tests.sh

# 步骤 4：灰度切换
# 在应用配置中，将部分读流量指向 Valkey
# 观察错误率、延迟、内存使用等指标

# 步骤 5：全量切换
# 确认无问题后，将所有流量切换到 Valkey

4.3 Python 迁移实战

"""
从 Redis 迁移到 Valkey 的 Python 实战
只需要修改连接配置，其他代码完全不变！
"""

import redis
# or: from redis.asyncio import Redis as AsyncRedis

# 之前: 连接 Redis
# client = redis.Redis(host='redis.example.com', port=6379, decode_responses=True)

# 之后: 连接 Valkey（只需要改 host/port）
client = redis.Redis(host='valkey.example.com', port=6379, decode_responses=True)

# 所有操作完全相同：
client.set('user:1001:profile', '{"name":"张三","age":28}')
profile = client.get('user:1001:profile')

# Hash 操作
client.hset('user:1001:details', mapping={
    'email': 'zhangsan@example.com',
    'phone': '13800138000',
    'level': 'VIP'
})

# 有序集合：排行榜
client.zadd('leaderboard', {'player1': 9500, 'player2': 8800, 'player3': 7200})
top10 = client.zrevrange('leaderboard', 0, 9, withscores=True)

# Pipeline 批量操作
pipe = client.pipeline(transaction=True)
for i in range(1000):
    pipe.set(f'session:{i}:token', f'token_{i}')
    pipe.expire(f'session:{i}:token', 3600)
pipe.execute()

# 流（Streams）：消息队列
client.xadd('order_events', {'order_id': '1001', 'status': 'created'})
events = client.xread({'order_events': '$'}, count=10, block=5000)

print("迁移完成！所有 Redis 命令在 Valkey 上正常工作。")

4.4 Go 迁移实战

package main

import (
    "context"
    "fmt"
    "github.com/redis/go-redis/v9"
)

/*
 * Go 程序从 Redis 迁移到 Valkey：
 * 只需要修改 Addr 配置，其他代码完全不变
 * go-redis 库自动使用 RESP 协议，兼容 Valkey
 */

var ctx = context.Background()

func main() {
    // 之前: Redis 连接
    // rdb := redis.NewClient(&redis.Options{
    //     Addr: "redis.example.com:6379",
    // })

    // 之后: Valkey 连接（只改 Addr）
    rdb := redis.NewClient(&redis.Options{
        Addr:     "valkey.example.com:6379",
        Password: "your_password",
        DB:       0,
    })

    // 基本操作
    rdb.Set(ctx, "greeting", "Hello from Valkey!", 0)
    val, _ := rdb.Get(ctx, "greeting").Result()
    fmt.Println(val) // 输出: Hello from Valkey!

    // Hash 操作
    rdb.HSet(ctx, "config:app", map[string]interface{}{
        "version": "2.0.0",
        "env":     "production",
        "debug":   "false",
    })

    // 排行榜
    rdb.ZAdd(ctx, "daily_active", redis.Z{Score: 150, Member: "user:A"})
    rdb.ZAdd(ctx, "daily_active", redis.Z{Score: 230, Member: "user:B"})
    rdb.ZAdd(ctx, "daily_active", redis.Z{Score: 89, Member: "user:C"})

    topUsers, _ := rdb.ZRevRangeWithScores(ctx, "daily_active", 0, 9).Result()
    for _, user := range topUsers {
        fmt.Printf("  %s: %.0f\n", user.Member, user.Score)
    }

    // Pipeline
    pipe := rdb.Pipeline()
    for i := 0; i < 1000; i++ {
        pipe.Set(ctx, fmt.Sprintf("key:%d", i), fmt.Sprintf("value:%d", i), 0)
    }
    pipe.Exec(ctx)

    fmt.Println("Go 程序已成功连接 Valkey！")
}

4.5 Docker Compose 生产配置

# docker-compose.yml
version: '3.8'

services:
  valkey-master:
    image: valkey/valkey:9.1.0
    container_name: valkey-master
    ports:
      - "6379:6379"
    volumes:
      - ./valkey.conf:/etc/valkey/valkey.conf
      - valkey-data:/data
    command: valkey-server /etc/valkey/valkey.conf
    restart: always
    deploy:
      resources:
        limits:
          memory: 8G
        reservations:
          memory: 4G
    healthcheck:
      test: ["CMD", "valkey-cli", "ping"]
      interval: 10s
      timeout: 3s
      retries: 3

  valkey-replica:
    image: valkey/valkey:9.1.0
    container_name: valkey-replica
    ports:
      - "6380:6379"
    volumes:
      - ./valkey-replica.conf:/etc/valkey/valkey.conf
      - valkey-replica-data:/data
    command: valkey-server /etc/valkey/valkey.conf
    depends_on:
      valkey-master:
        condition: service_healthy
    restart: always
    deploy:
      resources:
        limits:
          memory: 8G

volumes:
  valkey-data:
  valkey-replica-data:

# valkey.conf 生产配置
bind 0.0.0.0
port 6379
protected-mode yes
requirepass your_strong_password_here

# 内存管理
maxmemory 6gb
maxmemory-policy allkeys-lru

# 持久化：RDB + AOF 双保险
save 900 1
save 300 10
save 60 10000
appendonly yes
appendfsync everysec

# IO 多线程
io-threads 4
io-threads-do-reads yes

# TLS（生产环境强烈推荐）
# tls-port 6379
# tls-cert-file /etc/valkey/valkey.crt
# tls-key-file /etc/valkey/valkey.key
# tls-ca-cert-file /etc/valkey/ca.crt

# ACL
aclfile /etc/valkey/users.acl

# 日志
loglevel notice
logfile ""

五、性能基准测试：Valkey vs Redis 2026

5.1 GET/SET 基准测试

测试环境: AWS c7i.2xlarge (8 vCPU, 16GB RAM)
工具: valkey-benchmark / redis-benchmark
数据: 1000 万 key，value 64 字节

分析：GET 操作的 30% 提升主要来自内嵌字符串阈值从 64 提升到 128 字节。SET 操作的提升相对较小，但 IO 多线程模式下的 15.5% 提升来自无锁队列优化。

5.2 集群模式性能（ARM 平台）

测试环境: AWS Graviton4 (16 vCPU, ARM 架构)
集群: 3 主 3 从

ARM NEON SIMD 优化在集群模式下效果显著，CLUSTER KEYSLOT 计算速度提升了接近 3 倍。

六、Valkey 生态系统与工具链

6.1 客户端兼容性

Valkey 使用标准的 RESP 协议，所有主流 Redis 客户端库都可以直接使用：

6.2 监控与可观测性

Valkey 兼容所有 Redis 监控工具：

# 使用 valkey-cli 获取性能指标
valkey-cli info stats
valkey-cli info memory
valkey-cli info replication
valkey-cli info commandstats

# Prometheus + Grafana 监控
# 使用 valkey_exporter 暴露指标
docker run -d --name valkey-exporter \
  -p 9121:9121 \
  oliver006/redis_exporter \
  --redis.addr=valkey://valkey-host:6379

6.3 Valkey Gateway

Valkey 社区正在开发 Valkey Gateway（VGW），这是一个用 Go 编写的高性能代理，类似于 Redis 的 TWEMPROXY 但功能更强。VGW 支持：

• 请求路由和负载均衡
• 连接池管理
• 自动故障转移
• 多集群路由
• 请求级 ACL 控制

# valkey-gateway.yaml
listeners:
  - name: default
    addr: ":6380"
    tls: false

pools:
  - name: main
    addresses:
      - "valkey-node1:6379"
      - "valkey-node2:6379"
      - "valkey-node3:6379"
    type: cluster
    connections: 1000

routes:
  - listener: default
    pool: main

七、Valkey vs Redis：2026 年终极对决

7.1 功能对比矩阵

7.2 选择建议

选择 Valkey 的场景：

• 云服务提供商（提供托管 Redis/Valkey 服务）
• 对许可证合规性有严格要求的企业
• 需要在 ARM 架构（Graviton/鲲鹏）上获得最佳性能
• 已经在使用 Redis 且不需要 Stack 模块功能
• 想要避免单一供应商锁定

选择 Redis 8.0 的场景：

• 需要内置向量搜索（AI/RAG 应用）
• 需要时间序列数据类型
• 已购买 Redis Ltd. 的商业支持
• 需要完善的官方文档和培训资源

八、总结与展望

Valkey 从 Fork 到 9.1.0 的两年历程，证明了一件事：开源社区的力量可以超越任何单一公司。

当 Redis Ltd. 选择 Source Available 的商业模式时，很多人担心 Fork 项目会陷入分裂和混乱。但 Valkey 用四个大版本的稳定迭代给出了答案：BSD 许可证下的社区治理模式不仅可行，而且能产出更快、更安全、更开放的产品。

Valkey 9.1.0 的三大核心贡献：

1. 无锁 IO 线程模型（8-17% 吞吐提升）：证明了在单进程多线程架构中，无锁编程的实践价值
2. 内嵌字符串阈值优化（30% GET 提升）：一个看似微小的内存布局调整，却带来了巨大的性能收益
3. ARM NEON SIMD 优化（2-3x 加速）：在 ARM 服务器崛起的背景下，这个优化具有战略意义

展望 Valkey 的未来：

• Valkey 10.0（预计 2026 年底）：预计将引入更完善的 Module 生态、原生 TLS 1.3 增强、以及更高级的集群管理工具
• Valkey Gateway 的成熟：将提供更强大的代理和路由能力
• 企业级支持生态的完善：Percona 等公司已经在提供 Valkey 的商业支持

对于正在使用 Redis 的开发者来说，Valkey 提供了一条零迁移成本、低风险的替代路径。你甚至不需要改一行应用代码——只需要改一下连接地址。

Valkey 证明了：开源没有死亡，它只是在等待社区站出来。

参考资料

• Valkey 官方网站
• Valkey 9.1.0 Release Notes
• Valkey 9.1.0-rc1 Release Notes
• Valkey 9.1.0-rc2 Release Notes
• Valkey GitHub Repository
• Linux 基金会 Valkey 项目页
• DB-Engines Ranking