Skip to main content

Redis K/V 存储引擎的 RVV 向量化优化

S2603
人民币 15000
1
2026-04-01 (AoE)
2026-08-31 (AoE)

项目描述​

Redis（Remote Dictionary Server）是目前全球最受欢迎的开源、内存中数据结构存储系统。它通常被用作数据库、缓存、消息队列（Broker）和流处理引擎。

Redis 作为高性能的内存键值数据库，其核心瓶颈之一在于网络输入缓冲区的协议解析，比如，Redis 采用 RESP（REdis Serialization Protocol）文本协议，服务端在处理请求时，需要频繁执行单字节循环扫描，以查找控制字符（如 *、$）及换行符（\r\n）。在传统的标量处理器上，这种串行字符匹配消耗了大量的 CPU 周期。

RISC-V Vector（RVV 1.0）扩展提供了强大的单指令多数据（SIMD）并行处理能力，本题要求参赛者将 Redis 完整适配至 RISC-V 平台，并利用 RVV 1.0 向量指令对 Redis 的 RESP 协议解析、RDB/AOF 压缩、Dict 哈希计算等核心模块进行性能加速，推动 RISC-V 在数据库向量化方向的应用落地。

  • 目标架构：RISC-V（RV64GCV，支持 RVV 1.0）
  • 推荐测试环境：QEMU virt 机器（-cpu rv64,v=true,vlen=256）或真实 RISC-V 开发板
  • 验证平台：蓝芯 LX5000 开发板

评分要求​

必做任务​

优化后的代码必须完全兼容 RESP 协议规范，能够正确解析包括单行字符串、错误信息、整数、大块字符串（Bulk Strings）和数组在内的所有标准 Redis 命令报文。

  • 必须使用 RVV 1.0 Intrinsic 函数，可以辅助少量 RISC-V 内联汇编进行优化

  • 支持不同 VLEN（128/256/512 bit）的自适应实现，可利用 RVV 的 vsetvl 灵活向量长度特性

  • 可实现自动向量长度调优（VLEN 探测 + 运行时分发）

  • 允许合并或重构原有的循环结构，但不得改变原解析状态机的业务逻辑边界

  • 禁止使用多线程优化

  • 验证文档：记录测试方案，用于组委会验证参赛选手的优化成果

性能要求及正确性验证​

  1. 评测指标：基础测试、高并发测试、高Value测试、管道测试、持久化测试
  2. 能正确运行自带的回归测试集（对比 ARM 平台的测试结果）
  3. 相比于 memtier_benchmark 标量版本在验证平台的基线测试结果，性能需提升至少 30%
  4. 性能提升指标包括： GET/SET QPS、P99 延迟等
  5. 现有数据库内核、字符串核心以及协议解析函数的 RVV 向量化占比 >=70%

注意事项​

  1. 请确保遵循相关的开源协议和版权规范。
  2. 参赛者需要自行准备开发环境。
  3. 禁止直接搬运已有第三方 RISC-V Redis 移植代码，须自主实现或明确标注引用来源。
  4. 若使用 AI 辅助编写代码，需在提交报告中说明使用方式及占比。
  5. 需符合现有 Redis 代码规范。

参考资料​

资源链接
Redis 8.8.0 源码https://github.com/redis/redis/tree/8.8.0
memtier_benchmarkhttps://github.com/redis/memtier_benchmark/releases/tag/2.4.1
RISC-V RVV 1.0 规范https://github.com/riscv/riscv-v-spec
RISC-V RVV 1.0 规范https://github.com/riscv/riscv-v-spec
RVV Intrinsics 参考手册https://github.com/riscv-non-isa/rvv-intrinsic-doc
RISC-V GNU 工具链https://github.com/riscv-collab/riscv-gnu-toolchain
QEMU RISC-V 文档https://www.qemu.org/docs/master/system/target-riscv.html

提交说明​

1. 提交仓库​

参赛者需将代码提交至以下仓库：

https://github.com/rv2036/rvspoc-S2603-redis

2. 提交方式​

请通过 Pull Request（PR） 的方式将结果提交至上述仓库。

下文中所提及的「PR」均指针对该仓库创建的 Pull Request。

3. PR 中需包含的内容​

创建 PR 时，必须提供用于复现移植及优化结果的全部必要内容，包括但不限于：

  • 完整的源代码或二进制文件（* 详见第 5 条说明）
  • 配置文件（若有）
  • 依赖的库文件（若有）
  • 补丁文件（若有）
  • 其他对验证提交结果所必需的内容

4. 必须附带的说明文件​

创建 PR 时，须同时附带一份说明文件，内容应包含用于验证优化成果的详细步骤与信息，包括但不限于：

  • 验证平台说明：是否限定特定平台？若限定，请注明操作系统名称、版本及安装说明
  • 依赖库说明：是否限定特定依赖库？若限定，请注明相关信息及安装说明
  • 程序编译及安装步骤
  • 程序运行步骤
  • 程序运行结果
  • 其他对验证提交结果所必需的信息

5. 关于源代码的特别说明（优化类赛题）​

针对第 3 条中「完整的源代码或二进制文件」一项，补充说明如下：

  • 若参赛者在比赛截止时间前仅提交了二进制文件用于结果验证，则必须在之后通过 PR 的方式补充提交完整的源代码，方可视为完成本赛题。
  • 补充提交的完整源代码必须与先前提交的二进制文件 100% 对应（即由该源代码编译生成）。
  • 比赛截止时间后提交的源代码，其验证结果不计入比赛成绩，组委会仅会核实其是否与对应的二进制文件一致。

6. 成绩认定时间节点​

组委会将在比赛结束后（即 2026 年 8 月 31 日 (AoE) 之后）统一对提交内容进行验证。

自该时间点起，新增或修改的 PR 内容均不计入比赛成绩。

获胜条件：精度符合产出要求，性能评分最高的选手。

7. 评判与争议处理​

比赛组委会与赞助商将共同委派技术代表，组成 「联合评判组」。

评判组的职责包括：

  1. 对比赛过程及评判结果进行技术评判
  2. 受理并处理所有与比赛相关的争议

验收说明​

  • 2026 年 9 月 20 日后，由 RVSPOC 组委会公布。
  • 由于赛题的开放性和软件的复杂性，赛题发布时可能存在未解释或需要修正的部分。针对未考虑到的方面，随着比赛进程的推进可能根据选手的反馈会有调整，请保持对赛事网站的关注。最终解释权归属于比赛的赛题评审委员会。

知识产权及开源协议要求​

所有参赛结果要求开源，并提交至主办方指定仓库。参赛者（作者）持有作品的所有权。主办方鼓励参赛者将结果回馈贡献至 upstream。