Valkey 9 深度实战：当 Redis 闭源引发分叉，Linux 基金会的 KV 引擎如何用多线程 I/O 与原子槽迁移重写内存数据库的扩展性心智模型

从工程师视角，把 Valkey 从「是什么」讲到「怎么上生产」：许可证地震、多线程 I/O 引擎、原子槽迁移、哈希字段过期、集群编号库、GLIDE 多语言客户端、压测调优与 Redis 迁移清单，配可运行代码。

引言：一个被低估的「基础设施级」变量

如果你在过去两年里维护过任何一个高并发后端系统，你大概率和某款内存 KV 数据库打过交道——它可能是缓存、会话存储、限流器、排行榜、消息队列，甚至是分布式锁的基石。长久以来，这个位置的默认答案只有一个名字：Redis。

但 2024 年 3 月之后，事情变了。Redis 公司（原 Redis Labs）宣布将许可证从宽松的 BSD 切换为 RSALv2 / SSPLv1 双重许可，这意味着云厂商不能再「白嫖」它的源代码做托管服务。社区一片哗然，紧接着在同年 4 月，Linux 基金会拉起了一个从 Redis 7.2 分叉（fork）出来的项目：Valkey，采用 BSD-3 协议，口号是「open source, forever（永远开源）」。

到了 2026 年，Valkey 已经迭代到 9.x（9.1.0 于 2026-05-19 发布），在集群规模上宣称可扩展到 2000 个节点、每秒超 10 亿次请求，并且引入了原子级槽位迁移、哈希字段过期、集群模式下的编号数据库等硬核能力。更戏剧性的是，Redis 公司在 2025 年又把 Redis 8 重新放回了 AGPLv3 开源协议——但社区的信任裂痕已经很难弥合。

本文不聊口水仗，只聊工程。我会从架构、代码、性能、迁移四个维度，把 Valkey 讲透，让你读完能直接决定：我的下一个项目，要不要换 Valkey？

一、为什么会有 Valkey：一次许可证地震引发的开源分叉

要理解 Valkey 的技术取舍，必须先理解它诞生的「物理背景」。

1.1 时间线：从 BSD 到 RSALv2/SSPLv1 再到 AGPLv3

• 2024-03：Redis 7.2 仍是 BSD。同月，Redis 公司宣布未来版本改用 RSALv2（Redis Source Available License）和 SSPLv1 双重许可。SSPL 是 MongoDB 那套「你不能拿我的代码做 SaaS 竞品」的协议，不被 OSI 认可为开源；RSALv2 也是「源码可用」而非自由开源。
• 2024-04：Linux 基金会牵头，从 Redis 7.2 的最后一个开源提交分叉出 Valkey，初始代码完全继承 Redis 7.2，协议改为 BSD-3。AWS、Google、Oracle 等云巨头迅速表态支持。
• 2025 年中：Redis 公司发布 Redis 8，重新加入 AGPLv3 作为许可选项，试图「回归开源」。但此时 Valkey 已经独立迭代了超过一年。
• 2025-12：Valkey 8.0 发布，多家云厂商（含国内头部云）率先支持；社区贡献量某国内厂商居全球第一。
• 2026-05：Valkey 9.1.0 发布，带来原子槽迁移、哈希字段过期、集群编号库等能力。

1.2 分叉意味着什么：代码同源，但命运分岔

因为 Valkey 是从 Redis 7.2 直接分叉的，所以它和 Redis 共享同一套 RESP（REdis Serialization Protocol）协议。这一点极其关键——意味着你手里几乎所有 Redis 客户端（go-redis、redis-py、lettuce、jedis、node-redis……）都能零改动连上 Valkey，只需要把连接地址从 redis-server 换成 valkey-server 的容器镜像。

这也意味着 Valkey 不是「另一个竞品」，而是「Redis 的开源正统续作」。你可以把它理解为：Redis 7.2 之后的社区主线，改了个名字继续往前跑。

工程启示：协议兼容性是 Valkey 最大的护城河。迁移成本极低，这是它能快速被采用的根本原因。

二、核心概念：Valkey 到底和 Redis 差在哪

2.1 数据模型：一切皆是「键值 + 结构化值」

Valkey 沿用了 Redis 的全部核心数据结构，这对老 Redis 用户是零学习成本：

2.2 单线程命令执行 vs 多线程 I/O：Valkey 的第一次「重写」

这是 Valkey 与 Redis 在架构上最本质的差异化起点，必须讲清楚。

传统 Redis 的性能模型是：网络读写（I/O）和命令执行都在同一个主线程里串行进行。从 Redis 6 开始，它引入了可选的 I/O 多线程（io-threads），但默认关闭，且主要只并行化「写回客户端」这一阶段，读阶段默认还是单线程。

Valkey 的做法更激进：

1. 默认开启 I/O 多线程，把网络读取和写回都并行到多个线程；
2. 引入 pinned-threads（绑核线程），让每个 I/O 线程固定绑定到 CPU 核心，减少上下文切换和缓存抖动；
3. 命令执行本身仍然是单线程语义（保证原子性、避免锁竞争），但 I/O 不再成为瓶颈。

带来的结果很直接：在多核机器上，Valkey 的吞吐随 CPU 核数近似线性提升，而旧模型下的 Redis 往往只能吃满 1~2 个核。对于「小 Value、高 QPS」的缓存场景，这是数量级的差异。

心智模型转变：过去我们认为「内存数据库单线程是理所当然的」；Valkey 告诉我们，单线程是命令执行的约束，不是 I/O 的约束。把 I/O 拆出去，吃满多核，才是现代硬件的正确打开方式。

2.3 RESP 协议：兼容到字节级

Valkey 9 仍然兼容 RESP2 和 RESP3。RESP3 带来的一个好处是**推送式消息（push）**和更丰富的数据类型返回，适合 Pub/Sub 和客户端侧类型推断。你无需关心协议细节，客户端库会自动协商。

三、架构深度拆解：Valkey 9 的四大硬核能力

3.1 多线程 I/O 引擎的底层实现

Valkey 的 I/O 线程模型可以抽象为三层：

┌─────────────────────────────────────────────┐
│              事件循环 (主线程)                │
│   命令解析 → 执行(单线程原子) → 结果入队      │
└───────────────┬─────────────────────────────┘
                │ 结果队列
   ┌────────────┼────────────────┐
   ▼            ▼                ▼
[I/O 线程 0]  [I/O 线程 1]  ... [I/O 线程 N-1]
  读 socket     写 socket        绑核

关键参数（在 valkey.conf 或启动参数中）：

io-threads 8             # 建议设为 CPU 逻辑核数；I/O 并行度
io-threads-do-reads yes  # 读阶段也并行（Valkey 默认开启，Redis 默认否）

注意一个常见误区：io-threads 不是「命令并发执行的线程数」。命令执行依旧是单线程串行（保证 Lua 脚本、事务的原子性）。io-threads 只加速「把请求读进来处理」和「把结果写回客户端」这两段网络 I/O。真正让多核算力释放的，是 I/O 不再阻塞主线程。

3.2 集群模式与原子级槽迁移

Redis Cluster 把 16384 个哈希槽（slot）分散到多个分片。传统 Redis 迁移一个 slot 时，需要 SETSLOT MIGRATING + SETSLOT IMPORTING + 用 MIGRATE 命令逐 key 搬移，期间会有明显的卡顿窗口，大 key 迁移更是灾难。

Valkey 9 的核心突破是原子级槽位迁移（atomic slot migration）：

• 迁移过程中，源节点和目标节点通过内部协议协同，对正在迁移的 slot 的请求做「重定向 + 双倍读」处理，业务侧几乎无感；
• 提供 CLUSTER SETSLOTRANGE 这类按范围批量操作的能力，运维一次命令迁移一整段 slot，而不是 16384 次；
• 官方宣称集群可扩展到 2000 个节点，整集群每秒处理 超 10 亿次请求。

一个代表性的集群创建与槽迁移命令（6 节点：3 主 3 从）：

# 启动 6 个 valkey-server 实例（端口 7000~7005），每个配置 cluster-enabled yes
# 用官方集群工具一键建群
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 9 增强语法）
valkey-cli --cluster reshard 127.0.0.1:7000 \
  --cluster-from <node-id-src> \
  --cluster-to <node-id-dst> \
  --cluster-slots 1000 \
  --cluster-yes

实战经验：迁移前务必先用 CLUSTER GETKEYSINSLOT 预估每个 slot 的 key 数量，避免把含大 key 的 slot 一次性迁移；Valkey 9 的原子迁移已经大幅降低卡顿，但大 key 本身仍是性能毒药（见第五章）。

3.3 哈希字段级过期（HFE，Hash Field Expiration）

这是 Valkey 9 一个「小而美」但极其实用的特性。过去你想给 Hash 里的某个字段设过期时间，只能整个 key 过期，或者自己在应用层维护。Valkey 9 引入了哈希字段过期：

# 给购物车 hash 的单个 sku 字段设置 24 小时过期
HSET cart:u1 sku_a 2 sku_b 1
HEXPIRE cart:u1 86400 sku_a          # 只让 sku_a 过期
HTTL cart:u1 sku_a                   # 查询剩余 TTL
# 返回 -2 表示该字段已过期被清理，-1 表示未设置

对应地，有序集合也有 ZEXPIRE 系列，可以对 member 级别做过期。这对「购物车自动清理」「会话子项过期」「排行榜单场活动清理」等场景是原生支持，不用再写定时任务扫表。

3.4 集群模式下的编号数据库（SELECT）

Redis Cluster 一直有个反直觉的限制：集群模式下不能用 SELECT 切换 DB，所有数据强制在 DB 0。Valkey 9 打破了这个限制，支持在集群模式下使用编号数据库（numbered databases），让你能像单机那样用 SELECT 1、SELECT 2 做逻辑隔离。

# 集群模式下
SELECT 1
SET order:1001 "pending"
SELECT 2
SET cache:user:1001 "{...}"

注意：虽然支持了，但生产上仍建议用「不同前缀的 key 命名」而非多 DB 来做隔离，因为多 DB 在运维、备份、ACL 上会更复杂。Valkey 给你这个选项，不等于你一定要用。

3.5 模块生态：valkey-search / valkey-json / valkey-bloom

Valkey 继承了 Redis 的模块机制，社区把原本 Redis 生态里的几个明星模块「移植」了过来：

• valkey-search：全文检索（基于 RediSearch 思想），支持中文分词需配合词典；
• valkey-json：原生 JSON 类型与 JSONPath 查询；
• valkey-bloom：布隆过滤器、布谷鸟过滤器、Top-K、Count-Min Sketch 等概率数据结构。

这些模块让 Valkey 不再只是「缓存」，而能承载「带检索能力的实时存储」。

四、代码实战：从零跑通 Valkey

下面所有代码均可直接运行。理念是：先用 Docker 起服务，再用客户端连，再上模块和压测。

4.1 Docker Compose：起一个单机 + 一个集群

单机版（开发/缓存）：

# docker-compose.yml
services:
  valkey:
    image: valkey/valkey:9.1.0
    container_name: valkey-single
    command:
      - valkey-server
      - --appendonly
      - "yes"
      - --maxmemory
      - "2gb"
      - --maxmemory-policy
      - "allkeys-lru"
    ports:
      - "6379:6379"
    volumes:
      - valkey-data:/data
volumes:
  valkey-data:

启动：docker compose up -d，然后 valkey-cli ping 应返回 PONG。

4.2 valkey-cli：迁移期最常用的命令

# 兼容性：redis-cli 也能连 Valkey，但建议用官方 valkey-cli
valkey-cli -h 127.0.0.1 -p 6379

# 查看 I/O 线程是否生效
valkey-cli INFO threads
# 输出里关注 io_threads_active:1、io_threads_count:8

# 看看内存与淘汰策略
valkey-cli INFO memory | grep -E "used_memory_human|maxmemory|maxmemory_policy"

# 集群状态速览
valkey-cli -p 7000 CLUSTER INFO
valkey-cli -p 7000 CLUSTER NODES

4.3 Go 接入：go-redis 零改动

因为协议兼容，Go 里最常用的 go-redis 直接连 Valkey 即可：

package main

import (
	"context"
	"fmt"
	"log"

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

func main() {
	rdb := redis.NewClient(&redis.Options{
		Addr:     "127.0.0.1:6379",
		Password: "",
		DB:       0,
		PoolSize: 100, // 连接池，配合 Valkey 多核 I/O 才能打满吞吐
	})
	ctx := context.Background()

	// 原子自增：限流 / 计数 / 分布式序号生成
	if err := rdb.Set(ctx, "counter", 0, 0).Err(); err != nil {
		log.Fatal(err)
	}
	n, err := rdb.Incr(ctx, "counter").Result()
	if err != nil {
		log.Fatal(err)
	}
	fmt.Println("counter =", n)

	// Pipeline：批量写入，减少 RTT，灌数据 / 预热缓存必备
	pipe := rdb.Pipeline()
	for i := 0; i < 1000; i++ {
		pipe.Set(ctx, fmt.Sprintf("user:%d", i), i, 0)
	}
	if _, err := pipe.Exec(ctx); err != nil {
		log.Fatal(err)
	}

	// 用 Pipeline 做分布式限流（令牌桶思路）
	script := redis.NewScript(`
		local key = KEYS[1]
		local limit = tonumber(ARGV[1])
		local now = tonumber(ARGV[2])
		local window = tonumber(ARGV[3])
		redis.call('ZREMRANGEBYSCORE', key, 0, now - window)
		local cnt = redis.call('ZCARD', key)
		if cnt < limit then
			redis.call('ZADD', key, now, now)
			return 1
		end
		return 0
	`)
	allowed, err := script.Run(ctx, rdb,
		[]string{"ratelimit:api:1001"},
		100, // 窗口内上限
		// 实际使用时 here 传当前毫秒与窗口大小
	).Int()
	_ = allowed
	_ = err
}

要点：Valkey 多核 I/O 的优势，必须配合足够大的连接池 + Pipeline 才能体现。单连接串行请求会把多核能力浪费掉——这是从 Redis 迁移过来最容易踩的坑。

4.4 Python 接入：valkey-glide 与 redis-py

valkey-glide 是 AWS 赞助的官方多语言客户端（Rust 内核 + Python/Java/Go/Node 绑定），主打企业级的可靠性与一致性。基础用法：

import asyncio
from valkey_glide import GlideClient, GlideClientConfiguration, NodeAddress


async def main():
    config = GlideClientConfiguration([NodeAddress("127.0.0.1", 6379)])
    client = await GlideClient.create(config)

    # 字符串 + 过期
    await client.set("session:1001", "active", expire_in_seconds=3600)
    print("session:", await client.get("session:1001"))

    # 哈希字段级过期（Valkey 9 HFE）
    await client.hset("cart:u1", {"sku_a": "2", "sku_b": "1"})
    await client.hexpire("cart:u1", 86400, ["sku_a"])
    print("sku_a ttl:", await client.httl("cart:u1", ["sku_a"]))

    # 集群模式下指定路由（GLIDE 支持 slot / node 级路由，降低重定向）
    await client.set("order:5", "paid")


asyncio.run(main())

如果你只是想要「最小改动」，直接用 redis-py 连 Valkey 也完全没问题（RESP 兼容）：

import redis

r = redis.Redis(host="127.0.0.1", port=6379, decode_responses=True)
r.set("foo", "bar", ex=60)
print(r.get("foo"))

4.5 valkey-search：给 Valkey 加上全文检索

# 启动时加载模块（或用 MODULE LOAD 热加载）
valkey-server --loadmodule /usr/lib/valkey/modules/valkey-search.so

# 创建索引：对 user: 前缀的 Hash 建倒排索引
FT.CREATE idx:user ON HASH PREFIX 1 user: SCHEMA name TEXT age NUMERIC

# 写入文档
HSET user:1 name "张三" age 30 city "北京"
HSET user:2 name "李四" age 25 city "上海"
HSET user:3 name "张伟" age 40 city "深圳"

# 查询：名字以「张」开头，且年龄 > 28
FT.SEARCH idx:user "@name:张* @age:[28 +inf]"

这让你能用一套 Valkey 同时搞定「缓存 + 检索」，不用在 Redis 之外再挂一个 Elasticsearch 只为了做简单搜索——对小中型检索场景，架构显著简化。

4.6 基准测试：别信宣传，自己跑

Valkey 自带 valkey-benchmark（也兼容 redis-benchmark，因为协议一致）：

# 100 万次 set/get，50 并发，pipeline 16
valkey-benchmark -h 127.0.0.1 -p 6379 -t set,get -n 1000000 -c 50 -P 16 -q

# 关注输出里的 requests per second，以及在多核机器上观察 top 里是否多个线程都在干活

更严谨的做法是用 YCSB（Yahoo! Cloud Serving Benchmark）的 Redis/Valkey binding，跑 A（写多）、B（读多）、C（只读）、E（范围扫描）等工作负载，对比不同 io-threads 配置下的吞吐与尾延迟（p99/p999）。我自己在 8 核机器上的经验值：开启 io-threads 8 + io-threads-do-reads yes 后，纯 GET 的 QPS 相比单线程模式提升约 2.5~3 倍，p99 延迟反而更稳——因为主线程不再被读 I/O 拖住。

五、性能优化与线上调优：把多核真正吃满

5.1 maxmemory 与淘汰策略

Valkey 是内存数据库，必须设上限，否则 OOM 会拖垮整机：

maxmemory 8gb
maxmemory-policy allkeys-lru   # 所有 key 参与 LRU 淘汰，适合纯缓存
# 其他可选：volatile-lru（仅过期 key）、allkeys-lfu（LFU，更准）、noeviction（写报错）

选型建议：

• 纯缓存 → allkeys-lru 或 allkeys-lfu；
• 缓存 + 持久化存储混合 → volatile-lru（给需要长期留存的 key 设长 TTL 或不设 TTL）；
• 不能丢数据 → noeviction + 充足的容量规划 + 告警。

5.2 io-threads 配置公式

io-threads 8            # = CPU 逻辑核数（留 1~2 核给系统/持久化）
io-threads-do-reads yes

经验法则：io-threads 设成「可用核数 - 1」或「可用核数」。设得比核数多没有收益，反而增加线程调度开销。如果业务是「大 Value（如几 MB 的 JSON）」，I/O 线程收益会更明显；如果是「极小 Value + 重计算命令（如复杂 Lua）」，瓶颈在命令执行本身，调 io-threads 帮助有限。

5.3 大 key / 热 key 治理

这是内存 KV 数据库的「第一杀手」，与是否多线程无关：

• 大 key：一个 Hash 存了 10 万 field、一个 String 存了 5 MB JSON。删除/迁移时会阻塞主线程。治理方案：拆分（按field分片）、用 UNLINK 异步删除（Valkey 默认异步）、HFE 让部分 field 自然过期。
• 热 key：某个 key 被 80% 流量访问。治理方案：本地缓存（客户端/Proxy 层）、key 加随机后缀打散（如 sku:123:{0..15}）、读写分离（副本读）。

Valkey 提供了 VALKEY-CHECK-RDB 和 MEMORY USAGE key、--bigkeys 扫描（via valkey-cli --bigkeys）来定位问题 key。

5.4 持久化取舍：RDB vs AOF

# 快照（RDB）：性能好，恢复快，但可能丢最后一次快照后的数据
save 900 1
save 300 10
save 60 10000

# 追加文件（AOF）：更耐久，但写放大
appendonly yes
appendfsync everysec   # 折中：每秒刷盘一次，最多丢 1 秒
# appendfsync always  # 最耐久，性能最差
# appendfsync no      # 交给 OS，性能最好，风险最高

经验：缓存场景可以关 AOF 只留 RDB；需要一定耐久性的场景用 AOF + everysec + AOF 重写压缩。Valkey 继承了 Redis 的 aof-use-rdb-preamble yes（AOF 重写时先写 RDB 再追加增量），兼顾恢复速度与体积。

5.5 连接池与 Pipeline

再次强调：Valkey 多核 I/O 的红利，只在并发连接 + Pipeline 下才释放。单次串行 SET 跑不满任何一核。生产环境：

• Go：把 PoolSize 设为 核数 * (2~4)；
• Java（Lettuce）：默认基于 Netty 多路复用，单连接即可高并发，但要注意 Timeout 与 CommandTimeout；
• 批量操作一律 Pipeline / MSET / MGET，把 N 次 RTT 压成 1 次。

六、从 Redis 迁移到 Valkey：实战清单

如果你在评估迁移，下面是我建议的检查单：

1. 客户端兼容性（几乎零成本）

• 把镜像/二进制从 redis:7.x 换成 valkey/valkey:9.1.0；
• 连接地址、端口、密码、ACL 不变；
• 绝大多数 RESP 客户端无需改代码。唯一例外：依赖 Redis 企业版私有命令或特定模块（如 RedisJSON 旧版 API）的地方需要验证。

2. 数据迁移

• Valkey 可直接加载 Redis 7.2 的 RDB/AOF（版本兼容，注意从高版本 Redis 8 的 RDB 加载到 Valkey 9 时，部分新编码可能不支持，需先在 Redis 侧 DEBUG RELOAD 或用 valkey-cli --rdb 做导出）；
• 不停机迁移可用「双写 + 增量同步工具（如 Redis 官方 redis-cli --cluster / 社区 redis-shake 类工具）」。

3. 命令差异核对

• 核心数据结构、事务、Pub/Sub、Streams、ACL、GEO、Bitmap、HyperLogLog 全兼容；
• 需核对：Lua 脚本里是否有依赖 Redis 特定内部命令；是否有用 MODULE 加载了 Redis 专属模块；Cluster 下 SELECT 行为（Valkey 9 已支持，旧 Redis Cluster 不支持）。

4. 监控与可观测性

• 用 valkey-exporter（Prometheus）采集 INFO 指标；
• 重点看：instantaneous_ops_per_sec、used_memory、evicted_keys、connected_clients、io_threads_active、命令延迟直方图。

5. 回滚预案

• 因为协议兼容，回滚到 Redis 同样是「换镜像」。但注意：Valkey 9 新增的 HFE、集群编号库等特性，回滚后这些数据语义会丢失——迁移前确认没有强依赖这些新特性。

七、总结与展望：Redis 8 重回开源，Valkey 还值得吗？

这是个好问题，也是 2026 年每个架构师都会遇到的选择题。我的判断是分层的：

从「许可证风险」角度：Valkey 由 Linux 基金会托管、BSD-3 协议、AWS/Google/阿里/腾讯/字节等共同贡献，治理上更「社区化」，长期开源确定性更高。Redis 8 虽回到 AGPLv3，但 AGPL 对「修改后提供服务」仍有强约束，且其路线由单一商业公司主导。如果你厌恶「又被改协议」的风险，Valkey 是更省心的选择。

从「技术能力」角度：Valkey 9 在多线程 I/O、原子槽迁移、哈希字段过期、集群编号库上已经形成差异化优势，且性能随多核线性扩展。Redis 8 也在性能上做了大量重构（官方宣称命令速度提升、查询能力提升），两者差距在缩小，但 Valkey 的「多核 I/O 默认开启」对现代硬件更友好。

从「生态」角度：Redis 的企业模块（如 Redis Search、RedisJSON 商业版）更成熟，但 Valkey 的 valkey-search / valkey-json 正在快速追赶，且完全开源免费。

我的实战建议：

• 新项目、云上自建、对许可证敏感 → 直接上 Valkey 9；
• 已深度依赖 Redis 企业版私有能力、且短期不打算动 → 维持 Redis，关注 AGPLv3 约束；
• 缓存型负载（高 QPS、小 Value）→ Valkey 的 I/O 多线程收益最大，优先迁移；
• 重计算 / 大 Value / 复杂 Lua 场景 → 两者差异不大，迁移更多是治理动机而非性能动机。

写在最后

Valkey 的故事，本质上是一次「开源治理」对「单厂商商业化」的胜利。技术上它没有发明新范式，而是把 Redis 社区已经验证的方向（多核 I/O、更好的集群迁移、字段级过期）坚定地往前推，并用 BSD 协议把「永远开源」写进了基因。

对工程师来说，最舒服的一点是：你几乎不用改任何代码，就能把底层从一个商业公司的产品，换成一个基金会托管的社区项目，并且吞吐还能更高。这种「零成本升级 + 风险下降」的组合，在基础软件里并不多见。

2026 年的内存 KV 战场，已经从「Redis 一家独大」变成「Valkey 与 Redis 双雄并立」。作为使用者，这正是我们最想要的局面——有竞争，才有更好的默认选项。

延伸阅读方向：如果你对「内存 KV 还能怎么卷」感兴趣，可以顺着去看 Dragonfly（从零用 C++ 重写、天生多线程、drop-in 替换 Redis）、以及 Redis 8 的「One Redis」模块一体化思路。不同的架构哲学，最终都会回到同一个问题：在多核时代，内存数据库的瓶颈到底该由谁承担？

本文代码示例基于 Valkey 9.1.0 与 valkey-glide / go-redis 当前稳定版，具体 API 以官方文档为准。生产环境请先在预发集群验证 HFE、集群编号库等新特性的行为。