一、基础定义
Milvus2.0版本后,Woodpecker使用了专门构建的云原生WAL(预写日志)引擎,用于替代传统的Kafka/Pulsar,承担向量数据库写入流水、持久化、故障恢复、流订阅能力,是Milvus新一代的流式架构核心组件。
当前定位:内置式日志消息系统,不再需要独立部署外部MQ集群,大幅度简化Milvus集群运维。
二、核心设计:Zero-Disk无本地磁盘架构
- 日志实体数据:直接持久化到对象存储(MinIO/S3/GCS/阿里云OSS),复用Milvus自身对象存储、不占用本地磁盘。
- 元数据:仅依赖etcd存储通道、分片、位点、分段元信息,复用Milvus自身对象存储,不占用本地磁盘
- 无独立Broker:无需额外MQ组件,以库形式嵌入Milvus各组件(RootCoord、DataCoord、StreamingNode)
- 写入流程:内存缓冲 -- > 异步批量刷对象存储 ,本地仅临时内存缓存,无落盘依赖
三、部署模式

- MemoryBuffer (Embedded嵌入式)

MemoryBuffer模式提供了一种简单、轻量级的部署选项,Woodpecker的嵌入式客户端会在内存中临时写入的内容,并定期将其刷新到云对象存储服务。这种模式Woodpecker以静态库形式内嵌到Milvus进程(StreamingNode/DataNode),无独立LogStore服务;所有读写逻辑运行都在Milvus内部,仅依赖两套外部底座:
- etcd:存储通道,分段、消费位点元数据
- 对象存储MinIO/S3/OSS:持久化全部WAL日志(Zero-Disk 无本地落地)
写入链路:客户端写入 ---> 进程内MemoryBuffer内存缓冲池批量攒数据 -->异步刷写到对象存储、默认200ms强制刷新一批。
关键特性:
(1)组件无分离
不新增独立Pod/进程,Milvus集群只维护原有的Coordinator、StreamingNode、DataNode,去掉了MQ(Kafka、Pulsar中间件依赖);
(2)写入延迟
MinIO对象存储场景:200~500ms,由批量刷写间隔决定;本地文件后端仅10ms刷新时间、延迟更低
(3)数据持久机制
纯内存缓冲+异步批量上传,无本地磁盘日志;崩溃会丢失内存未刷写的一小段数据窗口(Max 200ms数据)
(4) 扩缩容
跟随Milvus StreamingNode 水平扩容,缓冲能力随节点线性提升
milvus.yaml配置模版:
mq:type: woodpecker
woodpecker:meta:type: etcdprefix: woodpecker# 嵌入式默认MemoryBuffer缓冲策略logstore:segmentSyncPolicy:maxInterval: 200ms # 对象存储批量刷写间隔maxIntervalForLocalStorage: 10ms
- QuorunBuffer(Service独立服务式)

QuorumBuffer模式:用于对延迟敏感的高频率读写工作负载,这些负载既需要实时响应能力,又需要较强的容错能力。这种模式下,客户端与三副本交互,提供了高速写缓冲、通过分布式共识机制确保强一致性和高可用性。
核心架构原理:
- 单独部署一套LogStore集群(独立POD/进程),Milvus各组件通过gRPC远程调用Woodpecker Client访问日志服务;
- 采用Quorum三副本仲裁机制:写入需至少2个LogStore节点确认成功,强一致性;内置两层缓冲:内存QuorumBuffer + 本地临时磁盘StagedFile,再异步上传对象存储,延迟大幅度降低。
关键特性
(1)独立集群组件
新增LogStore服务集群,通过Gossip协议自动节点发现、故障摘除、负载均衡;Milvus与日志存储计算分离,可独立扩缩容LogStore;
(2)写入延迟
个位数毫秒级,远低于嵌入式模式,适配高实时增量写入
(3)高可靠强一致
多副本Quorum仲裁,节点宕机不会丢失未刷写数据;本地临时磁盘兜底,崩溃恢复完整回放
(4)吞吐上限更高
独立缓冲池、多节点并发写入,支撑十万级QPS实时插入,高频CDC订阅
配置:
mq:type: woodpecker
woodpecker:client:mode: service # 切换为独立服务模式endpoints: "woodpecker-logstore-0:9000,woodpecker-logstore-1:9000,woodpecker-logstore-2:9000"meta:type: etcd
两种模式各个维度对比:
|
对比维度 |
Embedded 嵌入式 MemoryBuffer |
Service 独立服务 QuorumBuffer |
|
运行形态 |
内嵌 Milvus 进程,无独立服务 |
独立 LogStore 集群,gRPC 远程访问 |
|
一致性机制 |
单节点内存缓冲,无副本仲裁 |
Quorum 三副本,写入 2 节点确认 |
|
写入延迟 |
200~500ms(S3) |
1~10ms |
|
数据丢失风险 |
最多丢失 200ms 窗口内存数据 |
几乎无丢失,本地磁盘兜底 |
|
运维复杂度 |
极低,仅维护 Milvus+etcd+MinIO |
高,额外维护一套 LogStore 集群 |
|
扩缩容方式 |
跟随 StreamingNode 扩容 |
LogStore 集群独立水平扩缩容 |
|
推荐规模 |
单机、中小集群(亿级以内) |
大规模、多租户、十亿级向量 |
|
默认部署 |
Milvus 2.6 标准默认模式 |
企业高性能专属部署 |
|
本地磁盘依赖 |
无,纯内存 + 对象存储 |
有本地临时缓冲磁盘 |
四、五层内部分层架构

- Wooppecker Client 客户端(接入入口)
Milvus所有组件(RootCoord、DataNode、StreamingNode)调用WAL的统一SDK接口主要跟部署模式有关,分为以下两类:
(1)EmbedClient(嵌入式客户端,默认)
- 直接链接进Milvus进程,无独立服务,内置完整LogStore
- 适配单价Standalone,小规模分布式集群
(2)ServiceClient(独立服务客户端)
- 通过gRPC远程访问独立LogStore集群
- 超大吞吐、多租户、跨集群场景使用
Client内部组件:
- LogWrite:写入器,接收Insert、Delete、DDL、TimeTick数据,批量组装日志块
- LogReader:读取器,提供位点消费、数据回放、故障恢复拉流能力
- LogHandle:PChannel通道句柄,绑定Milvus分片流,管理单个WAL流生命周期
- SegmentHandle:日志分段句柄,控制分段创建、切换、位点查询
- Meta Client:对接etcd,读写通道元数据,消费checkpoint,分段索引
- Meta元数据管理层(分布式协调核心)
唯一元数据存储依赖etcd,复用Milvus集群已有etcd,不新增组件:
(1)存储内容:
- PChannel流拓扑、分片分配
- 所有Segment分段元信息(起始偏移、存储路径、大小、时间范围)
- StreamingNode消费位点checkpoint
- 集群节点成员、副本仲裁配置
(2)核心能力
- 分布式锁、原子位点更新
- 集群节点自动发现、副本仲裁(Quorum)
- 元数据快照、故障快速恢复流状态
- LogStore Service服务调度层(内存缓冲核心)
Woodpecker读写中枢,所有写入/读取请求统一路由到此模块:
(1)MemoryBuffer 内存缓冲池
零磁盘核心设计:写入数据先驻留内存队列,批量聚合后异步上传对象存储,减少S3/OSS高频请求;
支持配置队列长度、刷写间隔、单段最大内存阈值
(2)分段滚动调度器
触发分段切分策略:单段256M上限,最大10分钟强制滚动、块数量上限
(3)异步上传协程池
批量压缩日志后并发写入对象存储
(4)预读缓存管理器
StreamingNode实时订阅时预加载远端Fragment,降低查询延迟
(5)日志压缩/清理调度
过期分段、重复删除记录自动合并清理,节省对象存储成本
- LogStore存储抽象层(底层存储适配器)
统一屏蔽本地文件/S3/MinIO/OSS差异,提供标准化读写接口:
两种存储后端实现:
(1)ObjectStorage(生产默认)
Zero-Disk核心:所有日志持久化至对象存储,本地无持久化文件;
分片文件以Fragment单元存放在对象桶独立路径
(2)LocalFile(测试单机)
本地文件模拟对象存储,仅开发调试使用,不推荐生产
内置组件:
- StagedWriter:分级写入器,高吞吐场景临时落本地缓冲后再上传对象存储
- FragmentReader/FragmentWriter: 分段读写底层接口
- 压缩器:支持Snappy/ZSTD批量日志压缩
- SegmentProcessor +Fragment数据存储单元(最小持久化单元)
(1)Segment(日志分段、逻辑单元)
一条PChannel流会被切分成多个Segment,每个Segment包含多条有序日志块:
- 固定滚动策略:maxSize 256M/ maxInterval 10Min
- 存储分段索引、起始offset、结束offset、时间戳范围
- 故障恢复最小回滚粒度
(2)SegmentProcessor(分段处理器)
单个Segment的专属读写逻辑单元
- 日志追加、位点校验、副本同步
- 读写范围过滤、数据回收
- 分段过期判断、删除归档
(3)Fragment(分片文件,物理存储单元)
对象存储上真实存在的最小文件,一个Segment拆分为多个Fragment:
- 纯追加写、不可修改,保证WAL有序性
- 存储原始向量变更日志(insert/delete/ts tick)
- 支持mmap零拷贝读取,提升回放速度
- 独立部署模式额外核心组件(Service模式专用)
当Woodpecker单独部署LogStore集群时,新增集群管控组件:
(1)QuorumDiskCovery副本仲裁模块
多副本写入一致性协议,支持多可用区节点亲和
(2)Membership 集群成员管理
Gossip协议自动发现LogStore节点,故障剔除,负载均衡
(3)gRPC Gateway网关
提供远程Client访问独立LogStore集群的RPC服务
核心组件数据量写入链路:
Proxy/DataNode --> Woodpecker Client.LogWriter --> MemoryBuffer缓冲池 -->LogStoreService异步调度 --> SegmentProcessor 组装分段 --> Fragment压缩 --> LogStore上传对象存储 --> Meta更新etcd分段元数据
五、核心能力与优势
- 性能方面
- 对象存储S3模式:吞吐量750MB/s,是Kafka的5.8倍
- 本地文件模式:写入延迟仅1.8ms,延迟降至Kafka的1/32
- 批量异步刷写、日志分段合并、压缩优化、完美适配向量批量写入场景
- 运维方面,降低了架构复杂度
- 移除Kafka/Pulsar中间件,减少一套分布式集群维护、扩缩容、监控、故障处理
- 一套MinIO/对象存储同时承载向量索引、快照、WAL日志、存储统一管理
- Standalone单机、分布式集群两种部署模式全部支持
- 原生适配Milvus向量业务
- 对齐Milvus PChannel/VChannel分片模型,一条物理通道对应一套WAL流
- 原生支持Insert/Delete/DDL变更日志,Timetick时序信号、Streaming流节点订阅
- 日志自动分段、过期清理、压缩合并,无需手动配置消息保留策略
- 弹性无线扩展
对象存储天然无限扩容,不受本地磁盘容量限制;多可用区、跨地域部署友好,依托云存储实现数据多副本持久化
