HorizonVault 技术深潜：如何在 HDD 上做出 100GB/s+ 级大吞吐分布式存储｜得物技术

📌 一句话摘要

得物技术团队详细介绍了自研高吞吐分布式存储引擎 HorizonVault 的架构设计，阐述其如何通过顺序追加、磁盘隔离、状态感知调度和副本同步等机制，在通用 HDD 上实现 100GB/s+ 的集群写入吞吐，以解决 Kafka 远程存储场景下的性能、成本和稳定性问题。

📝 详细摘要

本文深入剖析了得物技术团队自研的分布式存储引擎 HorizonVault。该引擎专为 Kafka 远程存储、冷/温数据下沉等大容量低成本场景设计，核心目标是在通用 HDD 上实现高吞吐、低抖动、可恢复的存储能力。文章从性能主线出发，详细拆解了 HorizonVault 的整体架构，包括：以磁盘为单位的存储结构（DiskStore、Replica、Log/Index）、基于顺序追加的写入路径与基于索引的读取路径、磁盘治理与线程隔离机制、网络背压控制、Broker 与 Meta 的状态感知调度、Leader/Follower 的 HA 复制策略，以及通过 Kafka Tiered Storage 插件实现的无缝接入。文章强调，HorizonVault 通过将磁盘提升为系统一等资源，并构建一套围绕资源池运行的闭环调度系统，成功将通用 HDD 的容量优势转化为集群级吞吐，同时将慢盘、慢副本等问题限制在局部，实现了性能、成本和稳定性的统一。

💡 主要观点

- HorizonVault 通过顺序追加、多盘并行和状态感知调度，在 HDD 上实现 100GB/s+ 集群吞吐。 核心公式为单盘顺序吞吐乘以可用磁盘数乘以并行节点数乘以有效利用率。系统通过将随机 I/O 压缩到小索引上，并利用分布式并行写入摊薄单盘能力上限，从而突破 HDD 的性能瓶颈。

磁盘被提升为系统一等资源，具备状态、水位、线程和隔离能力，实现精细化的资源治理。 每块磁盘被抽象为 DiskStore，拥有独立的执行器、缓存和限速器。系统通过磁盘级 inflight 跟踪和负载响应时间分析，自动隔离慢盘，避免单点故障扩散为全局问题。

写入路径与 HA 复制解耦，通过 ACK 等级和事件驱动的 PutReqHolder 实现吞吐与确认语义的平衡。 普通写入在 leader 本地顺序追加后即可返回，强确认请求则通过 PutReqHolder 等待 flush 或 follower 同步事件。这避免了写线程直接阻塞，保证了 HDD 后端的高吞吐。

Broker 和 Meta 协同实现状态感知的资源调度，确保流量均匀分布并避开压力点。 Meta 负责在创建和迁移阶段将资源均匀分布，Broker 则在每次请求时选择状态健康的 partition 和 leader，并排除近期使用过的热点目标，共同决定了系统吞吐的天花板。

💬 文章金句

- HorizonVault 把「写一个文件」变成了「基于集群资源状态、磁盘水位、线程隔离、网络背压和副本同步进度共同决策的一次分布式调度」。

• 对 HDD 资源池来说，这种克制本身就是性能的一部分。
• HorizonVault 没有把 HDD 当作普通挂载目录来用。它把磁盘提升成了系统的一等资源：有状态、有水位、有线程、有缓存、有隔离，也会被 Meta 纳入全局资源调度。
• 高吞吐依赖可控队列里的健康请求持续向前，而非无条件接收更多请求。
• 这套闭环最终服务的是同一个目标：把性能、成本和稳定性放在一起解决。

📊 文章信息

AI 初评：88

来源：得物技术

作者：得物技术

分类：软件编程

语言：中文

阅读时间：32 分钟

字数：7765

标签： 分布式存储, Kafka, HDD, 高吞吐, 系统设计

阅读完整文章