我们正处在 AI 驱动的技术浪潮中，Valkey 作为开源社区核心 KV 存储引擎，已成为 AI 基础设施的 “数据粮仓”。随着 AI 业务爆发式增长，数据存储量指数级攀升、业务吞吐需求持续飙升，对 Valkey 的大规模分片集群服务提出了前所未有的严苛要求 —— 就像 “千军万马过独木桥”，原有架构难以承载如此高强度的业务压力。

图1：字节内部 AI 场景中典型实例规模和需求

字节内部某 AI 类业务实例的诉求堪称 “极端”：集群分片数高达 4096，需支撑 256T 内存容量与 800GB/s 总带宽的高速服务。这类超大规模场景下，Valkey 集群呈现三大核心诉求：

• 高带宽消耗：KVCache 类应用以 String 类型为主，但 value 尺寸常达 32M 及以上，单 shard 的 primary （或standby）节点需稳定支持 1GB/s 的热点带宽；
• 
  
• 灵活访问与高扩展：既需通过 proxy 模式实现无缝读写分离，也可以支持通过直连 Native cluster 的 RDMA offload，对高可用与扩展性提出双重要求；
• 
  
• 数据类型拓展：亟需支持向量类型存储与向量查询，核心是为基础数据结构新增向量索引能力。随着Agentic AI场景的深入，逐渐对更多数据类型如JSON，更多索引类型如时序等需求强烈。

从 Redis 到 Valkey，单集群最大容量与服务上限始终未形成明确标准，面对超大集群需求时，只能依赖用户横向拆分业务，这给业务开发与线上紧急运维带来巨大压力。如何让 Valkey 集群在 AI 洪流中“扛住重压”，成为下一代架构亟需突破的核心命题。

图2：Valkey in DB4AI - 推理中 Valkey 的典型用法

现状瓶颈：Gossip 协议，大规模集群的“致命短板”

当前 Valkey Cluster 采用基于 Gossip 协议的对等网络模型，每个节点均参与集群元数据维护与决策——这种架构在小规模集群中像“邻里间互相传话”，高效灵活，但在 AI 场景的超大规模部署中暴露致命缺陷：

• 通信开销指数级增长：在 4096 分片的大规模集群中，Gossip 协议的节点间信息同步成本随分片数呈指数上升，网络带宽被大量占用；
• 
  
• 故障收敛效率低下：去中心化设计导致故障发生时，节点间需通过 Gossip 协议长时间收敛才能达成一致，延长业务不可用时间；
• 
  
• 脑裂引发数据不一致：故障场景下分布式节点的拓扑视图易出现分歧，客户端请求路由至脑裂节点时，会直接导致数据访问结果不一致。

显然，Gossip 协议已成为大规模集群的“致命短板”。要突破这一瓶颈，必须摒弃大分片规模下的指数级网络信息传播模式，构建一套中心控制式的集群管理架构。

图3：Valkey 及 Redis 在 Native cluster 下使用 gossip 协议导致脑裂问题示意图

架构革新：两种中控方案的“生死对决”

针对大规模集群的核心痛点，业界与字节分别探索了两类中心控制架构，其设计逻辑与适配性各有侧重：

Configserver 中控集群管理架构

该方案借鉴成熟的 HDFS 体系架构，通过独立的 Configserver 作为集群 “外置遥控器”，将拓扑、配置等元数据存储于 ETCD/ZooKeeper 等强一致组件，Configserver 负责拓扑管理、高可用判定与配置下发，数据链路则由 server 与 proxy 组件承接。Valkey 内核提供两种适配模式：

• 集群模式（cluster enable）：移除内核中的 Gossip 协议逻辑，直接接收 Configserver 推送的动态路由表；
• 
  
• 静态分片（static shard）仿集群模式：采用 share-nothing 架构（或类 codis 模式），Valkey 节点仅校验本节点 slot 信息，依赖 proxy 组件完成请求路由转发。

该模式的核心优势在于管理灵活：既可管控专属独立实例，也可通过共享管理实例池实现多实例统一调度，支持定制化负载均衡策略与数据搬迁；且控制模块与数据模块分离，控制层更轻量、迭代更快，不影响数据层稳定性。

但在实际应用中，它的 “致命缺陷” 同样突出：

1. 客户端请求拓扑仍然是通过数据节点，客户端访问到脑裂的数据节点仍然会访问到错误的拓扑，导致数据不一致，客户端只能被动的在请求报错后才能逐渐收敛请求到正确的数据节点上。
2. 
   
3. 需额外构建、部署 Configserver 及维护 ETCD 集群，大幅增加运维成本及迭代发展；
4. 
   
5. 为保障 Control Plane 和 Data Plane 一致性，需对 Valkey 内核进行大幅改造，尤其需实现 “happens-before” 切换原语，这就像 “给旧机器装新零件，不仅要改结构，还得担心兼容性”，随着社区迭代，研发维护成本持续攀升。

图4：类 HDFS 中心化管理方法 - 从 gossip 协商到集中命令式集群

raft 一体化中控集群管理架构

为解决 configserver 模式的核心痛点，字节提出将中控服务直接集成于 Valkey node 的 “内置智能大脑” 方案 —— 所有中控能力均通过 Valkey 标准协议对外提供，彻底摒弃 Gossip 协议，无需额外存储与控制链路。

原有 Valkey node 仅支持 Primary、Replica 两种角色，新增 root 角色承担中控职能，核心功能包括拓扑查询、配置下发、节点替换、分片增减、slot 动态迁移与数据节点高可用切换。

图5：字节跳动轻量化内置控制器设计

值得一提的是在最早 Redis 8规划中，社区曾经讨论过代号为“flottia”的 cluster v2方案。但随着 Valkey 与 Redis 社区的分裂被搁置。字节由于其内部超大规模 Valkey/Redis 的实例演进持续进化出了类似方案。

raft-root 核心设计

• root 由 3 个以上的奇数个节点组成，内部使用raft一致性协议保障数据可靠性；
• 
  
• root 的持久化数据、raft log 格式和 Valkey 的 rdb、aof 格式一致，单独的目录存储；
• 
  
• 在 metaspace 可管理基础上，root 同时可兼容data节点服务，适用于小规模集群。

图6：字节跳动内置控制节点设计

客户端 - root 交互优化

在一体化中控体系下，控制节点可以非常高效的承担拓扑服务。在一致性的前提保障下，针对全量拓扑的获取，和局部拓扑的订阅可以高效的实现超大规模集群的快速下发，达到快速收敛的目的。下面介绍其思路：

客户端接入到 root 节点

客户端订阅 root 节点的拓扑（Linearizable read），脱离 raft 集群的 root 节点不对外提供服务，规避脑裂情况出现。

客户端访问 data 节点时收到 moved 或者报错，客户端到 root 节点重新拉取局部变更的拓扑，及时恢复访问。

拓扑局部更新：

现状拓扑 slot归属变更时，客户端需要拉取全部的拓扑信息变更，在大规模分片集群模式下，一次拉取全量拓扑，数据量过大，加载响应慢，均加重了客户端和服务端的负载；

有了root节点后，客户端可只通过订阅 root 节点上的 slot 归属变更，达到全局拓扑视图的更新；

root 节点推送slot变更失败后将主动 close 客户端的 session， 客户端重连需要先拉取一遍全量的拓扑信息。

图7：字节超大规模集群实例控制服务-提供接入服务和局部更新订阅

拓扑变更流程：

图8：字节超大规模集群实例控制服务 - 拓扑变更流程示意图

高可用设计：root 节点的稳定性保障

独立 cluster 线程

当前 cluster bus 与主线程共用进程，导致 root 节点与数据节点交互时易受业务流量干扰，造成 root 节点到 data 节点探活误报、运维命令下发失败等问题。方案将 cluster bus 抽离为独立线程，专门处理 cluster port 通信，大幅提升稳定性。

多点探活机制

root 节点组成的 raft 集群会对数据节点发起定时心跳检测，仅当超过半数 root 节点判定数据节点异常时，才判定该data节点状态异常，决策实行主备切换并执行 failover 流程和拓扑更新，避免单点误判导致的服务抖动。

图9：字节超大规模集群实例控制服务 - 多点探活流程示意图

多维度选主策略

root 节点对 master 节点判定异常后，需要选出新的候选 master 节点。在多副本场景中，可能出现多个健康状态的候选节点，root 节点可根据更多维度的信息对候选节点列表进行优先级排序：

• 基于offset数据全局选主：候选节点的 offset 越大，则优先级越高。
• 
  
• 区域亲和性选主：可支持对 data 节点属性打标，增加区域属性，优先选择与客户端同区域的候选节点。
• 
  
• 级联复制模式选主：可支持级联复制模式下的选主，满足读写分离复杂的复制链路，屏蔽掉复制链路的细节。

字节实践与社区共建，打破 Valkey 的“规模魔咒”

本文分享回顾了社区集群架构的现状、业界通用成熟的集群架构设计，探讨了以 raft 一体化和社区客户端协作，集成在 Valkey cluster 内的新一代中控集群管理架构。 以此推进 Valkey cluster 在 AI infra 提供更大规模的集群服务，满足日益增长的高容量、高吞吐、高性能的基础设施服务。这一架构革新，将助力 Valkey 在 AI 基础设施领域实现“质的飞跃”——轻松承载高容量、高吞吐、高性能的业务需求。

字节跳动正伴随业务高速发展，推动内部 Redis 逐步向 Valkey 演进，并积极参与社区建设：已向 Valkey 8/9 版本提交 RDMA、MPTCP、lttng 可观测性等重量级特性，以及数十个 bugfix，持续为社区贡献核心能力。

面向未来，随着复杂业务场景的拓展，我们将与 Valkey 社区引擎能进一步丰富核心特性，打破更多 “能力边界”：

• 分离 metaspace 与 keyspace，支持
• 可观测的 metaspace 统计，以支撑详细的资源规划、容量评估；这也是轻量级管控体系一体化的前置需求。
• 可管理的 metaspace，提供控制命令支持管理 metaspace 的布局；
• 丰富的集群感知 metaspace 能力，为类似 valkey search 等高度复杂的 module 提供高效的集群基础协作框架。像标准 DDL 管理一样来管理动态索引，TTL 可配置索引等。

• 增强 Expire & Eviction 能力：
• 引入更高效的 expiration 算法，如 Timer wheel 等可配置算法等弥补随机扫描过期导致的低效删除。尤其是对于高吞吐缓存，expire 消费不能够和生产（存入）达到动态平衡；
• 支持 bustable 的能力，实现可控的写 stall 能力。对 Eviction 来说，当前只有在满时逐出，对于突发写入等可用性急剧降低。同样在社区引擎和内部支持更平滑的逐出能力。

Valkey 的大规模集群之路道阻且长，但 AI 时代的需求不等人。字节跳动与社区携手共建，推动 Valkey 成为 AI 时代更可靠、更强大的存储基础设施。欢迎社区伙伴参与讨论，共同探索技术演进方向，让 Valkey 彻底打破 “规模魔咒”！