Valkey 9.0 性能解剖：单节点 119 万 RPS 是怎么做到的

上周在排查一个缓存延迟问题的时候，同事提了一嘴："你知道 Valkey 现在单节点能跑到 119 万 QPS 吗？"

我第一反应是不信。Redis 单节点也就十几万的量级，Valkey 作为 Redis 的 fork，怎么突然快了这么多？

翻了一圈亚马逊云科技官博和 Valkey 社区的技术文档，发现这不是调参调出来的，是架构改了。从 I/O 模型到数据结构底层，动了好几刀。这篇文章把 Valkey 的性能优化拆开来说。

Valkey 是什么

先说清楚背景。Valkey 是 Redis OSS 7.2 的开源 fork，由 Linux 基金会托管。亚马逊云科技的 Amazon ElastiCache 用 Valkey 作为核心引擎。

简单说：ElastiCache 底下跑的就是 Valkey。你在 ElastiCache 上创建一个 Valkey 集群，不需要自己编译部署，开箱即用。

关键数据

先看几个数字，感受下量级：

指标 数值
单节点吞吐 119 万 RPS
集群节点上限 2000 节点
集群总吞吐 10 亿+ RPS
Pipeline 提升（9.0） +40%
I/O 延迟降幅 -69.8%

这些数据是在 EC2 c7g.4xlarge（Graviton3, 16 vCPU）上跑出来的，3M keys，512B value，650 并发客户端。

五层架构

Valkey 的设计哲学：单线程执行命令 + 多线程处理 I/O。命令执行保持原子性，I/O 线程负责榨取硬件性能。

┌─────────────────────────────────────────────┐
│  GLIDE 客户端（Rust Core + 多语言绑定）      │
├─────────────────────────────────────────────┤
│  网络连接层（TCP/Unix Socket/RDMA）          │
│  多路复用(epoll/kqueue) + 多线程 I/O         │
├─────────────────────────────────────────────┤
│  命令处理层（单线程顺序执行 + Pipeline 批处理）│
├─────────────────────────────────────────────┤
│  数据结构与存储（缓存行优化哈希表 + per-slot 字典）│
├─────────────────────────────────────────────┤
│  持久化与复制（RDB快照 + AOF + 双通道复制）   │
├─────────────────────────────────────────────┤
│  集群协调（16384 slot + Gossip + 自动故障转移）│
└─────────────────────────────────────────────┘

优化一：异步多线程 I/O

这是从 360K 跳到 119 万 RPS 的关键改动。

老方案的问题

Valkey 8.0 之前的多线程 I/O 是同步模式——主线程和 I/O 线程交替工作，不能并发。epoll_wait 系统调用吃掉主线程 20% 以上的时间。

新方案：真正的异步并发

AWS 团队贡献了全新的异步 I/O 架构：

主线程：执行命令 → 执行命令 → 执行命令（不被 I/O 打断）
   ↕ 事件通知（无锁）
I/O 线程池：读请求 → 解析协议 → 发送响应 → 轮询 epoll

设计细节：

  • 线程亲和性 — 同一客户端尽量由同一 I/O 线程处理，提升 CPU 缓存命中率
  • 动态伸缩 — 根据负载自动调整 I/O 线程数量
  • 零竞争 — I/O 线程和主线程通过事件通知协调，不加锁

性能对比（c7g.4xlarge，8 I/O 线程）

指标 旧方案（同步 I/O） 新方案（异步 I/O） 变化
吞吐量 360K RPS 1.19M RPS +230%
平均延迟 1.792ms 0.542ms -69.8%
主线程 I/O 占比 20%+ ~0% 释放

ElastiCache 上默认启用，不需要手动配线程数。

优化二：RDMA 直接内存访问

对延迟极度敏感的场景（实时竞价、游戏状态同步），网络协议栈本身就是瓶颈。

RDMA 的做法是绕过操作系统内核，让网卡直接读写应用内存：

  • 零拷贝 — 数据不经过内核缓冲区
  • 内核旁路 — 不走操作系统网络协议栈
  • CPU 卸载 — 远端 CPU 不参与数据搬运

Valkey 通过 valkey-rdma.so 模块支持 RDMA，相比 TCP 路径大约 2 倍 QPS 提升。

注意：RDMA 是社区实验性功能，ElastiCache 托管服务目前不用 RDMA，而是通过 Enhanced I/O 和多线程架构实现网络层加速。

优化三：缓存行对齐哈希表

数据结构层面的优化往往不显眼，但效果显著。

传统哈希表的问题：每个 entry 是独立的堆分配对象，指针跳转导致 CPU 缓存频繁 miss。

Valkey 的做法：

  • Entry 按 64 字节（一个 CPU 缓存行）对齐存储
  • 相邻 slot 的数据物理上也相邻
  • 减少指针间接引用

结果：哈希查找操作的 L1/L2 缓存命中率显著提升。

优化四：per-slot 字典 + Fenwick 树

集群模式下，Valkey 用 16384 个哈希 slot 分布数据。

每个 slot 独立字典的好处：

  1. 迁移效率 — slot 迁移只移动该 slot 的数据，不需要遍历全库
  2. 内存释放更快 — 删除 slot 直接释放对应字典
  3. 并发友好 — 不同 slot 的操作互不干扰

Fenwick 树（Binary Indexed Tree）用来做 slot 级别的统计查询（如某个 key range 有多少 key），O(log n) 复杂度。

优化五：Pipeline 批处理提升 40%（9.0）

Valkey 9.0 对 Pipeline 场景做了专项优化：

# 用 valkey-benchmark 测试 Pipeline
valkey-benchmark -h your-elasticache-endpoint -p 6379 \
  -t set,get -n 1000000 -P 64 -c 100

# Pipeline 深度 64 时，9.0 比 8.0 吞吐提升 40%

原理：优化了批量命令的内存分配策略和响应序列化路径。多条命令共享缓冲区，减少 malloc/free 调用。

在 ElastiCache 上体验

如果你想实际跑一把：

# 创建 Valkey 9.0 集群（Graviton3 实例）
aws elasticache create-replication-group \
  --replication-group-id "valkey-perf-test" \
  --replication-group-description "Valkey 9.0 performance test" \
  --engine valkey \
  --engine-version "9.0" \
  --cache-node-type cache.r7g.xlarge \
  --num-cache-clusters 2 \
  --multi-az-enabled \
  --automatic-failover-enabled \
  --region ap-northeast-1

几个配置建议：

  1. 选 Graviton 实例 — r7g/c7g 系列，性价比拉满
  2. 集群模式 — 如果单节点 QPS 不够，开集群模式水平扩展
  3. 跨 AZ 部署 — Multi-AZ 自动故障转移，可用性保底

GLIDE 客户端

AWS 联合 Google 和 Valkey 社区开发了 GLIDE 客户端（General Language Independent Driver for Enterprise）。底层 Rust Core 负责连接管理、重试、故障转移，上层提供多语言绑定：

# Python GLIDE 示例
from glide import GlideClusterClient, GlideClusterClientConfiguration

config = GlideClusterClientConfiguration(
    addresses=[("your-cluster.cache.amazonaws.com", 6379)],
    use_tls=True
)

client = await GlideClusterClient.create(config)

# AZ 亲和路由：优先读取同 AZ 副本
await client.set("user:1001", '{"name":"test","score":42}')
result = await client.get("user:1001")

GLIDE 内置了 AZ 亲和路由——自动优先读取和客户端同 AZ 的副本，减少跨 AZ 延迟。

总结

Valkey 性能提升不是靠调参，是靠架构重设计：

优化 核心思路 效果
异步多线程 I/O 主线程只执行命令，I/O 全部卸载 +230% 吞吐
RDMA 绕过内核，网卡直连内存 ~2x QPS
缓存行哈希表 数据物理连续，减少 cache miss 哈希查找加速
per-slot 字典 slot 独立管理，迁移效率高 集群扩缩容快
Pipeline 优化 批量命令共享缓冲区 +40%（9.0）

实际用的话直接上 ElastiCache，不需要自己折腾部署和调参。Graviton 实例 + Valkey 9.0 + GLIDE 客户端，性价比组合。

参考链接

posted @ 2026-06-09 11:30  亚马逊云开发者  阅读(13)  评论(0)    收藏  举报