源码层面彻底读懂 VictoriaMetrics。
本系列基于 VictoriaMetrics v1.146.0 LTS 版本（Long-Term Support），共规划 238 篇正文 + 12 篇附录，覆盖架构设计、组件原理、存储引擎、查询引擎、工具链、运维实践、排障调优等 20 个维度。每一篇都从源码出发，兼顾理论深度和实战落地。
VictoriaMetrics 时序数据库 Prometheus MergeSet 云原生监控 Go 存储引擎 v1.146.0 LTS
学习重点提示
专题核心价值（必须掌握）
- 架构设计哲学：理解 VM 为什么能做到比 Prometheus 省 7x RAM（MergeSet vs TSDB、LSM-less 设计）
- 存储引擎原理：MergeSet 只合并不分层的 LSM-less 设计，commonPrefix 压缩，NearestDelta 编码
- 完整组件体系：vminsert/vmselect/vmstorage 三层架构，12 种协议接入，Cluster 模式
- 性能优化方法论：TSIDCache 37% 策略、blockCache 三层设计、rawRowsShards 分片
专题扩展知识（了解即可）
- VictoriaLogs 日志一体化监控
- Enterprise vs OpenSource 功能差异
- vmagent/vmalert/vmauth/vmbackup 工具链
- 与其他 TSDB（InfluxDB/Thanos/Mimir）的对比
文章目录
- 一、VictoriaMetrics 是什么？为什么它是 Prometheus 的"超级增强版"？
- 二、250 篇源码专题全景导航：20 个维度速览
- 三、组件体系全貌：从 HTTP 入口到 Part 文件的全链路
- 四、核心性能优势：为什么 VM 能做到省 7x RAM？
- 五、典型应用场景：谁在使用 VictoriaMetrics？
- 六、学习路线图：如何高效阅读这个专题
- 七、FAQ：常见疑问
- 八、Roadmap：后续预告
一、VictoriaMetrics 是什么？为什么它是 Prometheus 的"超级增强版"？
思考记忆提示 --- 本节是专题的"入口"------弄清楚 VM 是什么、解决了什么问题，才能理解后面每篇的定位
- VictoriaMetrics 是一个高性能、低资源占用的时序数据库，兼容 Prometheus 生态
- 核心优势：比 Prometheus 省 7x RAM、支持集群模式、无限 cardinality、长期存储
- 面试高频提问：VictoriaMetrics 和 Prometheus 的区别是什么？什么时候选择 VM 而不是 Prometheus？
VictoriaMetrics（简称 VM）是一个开源的时序数据库（Time Series Database, TSDB），专门为云原生监控场景设计。它与 Prometheus 完全兼容，支持 Prometheus remote_write 协议、Grafana 数据源、以及 PromQL 查询语言。但 VM 的野心不止于"兼容"------它要做的是在保持兼容性的同时，大幅超越 Prometheus 的性能和资源效率。
我理解源码的意思是说
可以把 VictoriaMetrics 想象成一个超级版 Prometheus------如果 Prometheus 是一台普通家用轿车，那 VictoriaMetrics 就是一台经过深度改装的赛车：同样的引擎（PromQL 协议），但性能（资源效率）提升了好几倍。
具体类比如下：
- Prometheus = 单机数据库：就像一台独立运行的数据库服务器，数据存在本地磁盘，受单机硬件限制。如果数据量太大（几百万 time series），内存就会爆掉（OOM）。而且不支持水平扩展------想要更大容量？只能换更强的服务器（垂直扩展），成本呈指数增长。
- VictoriaMetrics = 分布式集群版 Prometheus：就像一个数据库集群，可以横向扩展。想要处理更多数据？多加几台服务器就行。而且 VM 还做了"省油优化"------同样的数据量，VM 消耗的内存只有 Prometheus 的 1/7。
- 类比详解：如果 Prometheus 是"一栋办公楼"（固定容量，无法扩建），VictoriaMetrics 就是"一个园区"（可以无限扩建办公楼）。更神奇的是，同样的员工数量，园区的能耗比单栋办公楼还低。
- 兼容是关键：VM 不是另起炉灶，而是"站在巨人的肩膀上"。它完整实现了 Prometheus 的 API（/api/v1/*）和 remote_write 协议，意思是：Grafana 不用改配置，PromQL 查询不用改语法，告警规则不用重写------直接迁移，无缝衔接。
**为什么能做到"超级"？**核心在于 VM 的三个技术创新：① MergeSet 存储引擎（不用 LSM Tree 的分层合并）；② TSIDCache 37% 策略（热点数据缓存）；③ blockCache 三层设计（数据块按需加载）。这三个设计相互配合，实现了"数据按需加载而非全量常驻"，从而大幅降低内存占用。
VictoriaMetrics 由 Aliaksandr Valialkin 于 2019 年创建，最初是为了解决 Promscale（InfluxDB on PostgreSQL）的性能和存储成本问题。经过多年发展，VM 已经成为 CNCF 生态中最受欢迎的时序数据库之一，GitHub 超过 17.2k stars，被 Spotify、Roblox、Grammarly、DoorDash 等知名公司采用。
1.1 VictoriaMetrics 的四大核心优势
为什么选择 VictoriaMetrics 而不是 Prometheus 原生？以下四个优势是 VM 脱颖而出的关键：
设计精髓
VictoriaMetrics 的设计哲学是：在不牺牲兼容性的前提下，用更少的资源做更多的事。这体现在四个维度：存储效率（MergeSet 压缩）、内存效率（LSM-less + 缓存策略）、查询性能（并行 k-way 归并）、扩展性（Cluster 模式）。
| 维度 | Prometheus | VictoriaMetrics | 提升幅度 |
|---|---|---|---|
| RAM 占用 | 全量数据常驻内存 | TSIDCache 37% + blockCache 分层 | 省 7x |
| 水平扩展 | 不支持（单机） | Cluster 模式支持 | 无限扩展 |
| 长期存储 | 需要 Thanos/Mimir | 内置 retention | 原生支持 |
| Cardinality | 有限制 | BloomFilter 动态调整 | 更高上限 |
1.2 与 Prometheus 的关系：不是替代，是增强
理解 VictoriaMetrics 和 Prometheus 的关系非常重要：VM 不是要替代 Prometheus，而是要解决 Prometheus 的局限性。Prometheus 仍然是一个优秀的抓取和告警工具**，但它的本地存储不适合大规模长期存储。VictoriaMetrics 提供了两种集成方式：**
- 方式一：Prometheus 远程写入 VM （推荐）
Prometheus 继续负责抓取和告警评估，数据通过 remote_write 协议写入 VictoriaMetrics。VM 作为长期存储和高效查询的后端。 - 方式二：vmagent 替代 Prometheus
使用 vmagent（VM 原生的轻量级抓取代理）替代 Prometheus，负责抓取和远程写入。
注意
VictoriaMetrics 不是 Prometheus 的 fork，而是一个完全独立的实现。VM 使用了完全不同的存储引擎（MergeSet vs Prometheus TSDB），但通过完整实现 Prometheus 的 API（/api/v1/*）和协议（remote_write）来实现兼容性。
必记闭环逻辑（核心考点）
VictoriaMetrics 是一个与 Prometheus 完全兼容的时序数据库，通过 MergeSet 存储引擎和 LSM-less 设计实现比 Prometheus 省 7x RAM，同时支持 Cluster 模式无限水平扩展。它不是 Prometheus 的替代品，而是 Prometheus 的"超级增强版后端"。
二、250 篇源码专题全景导航：20 个维度速览
思考记忆提示 --- 本节是专题的"地图"------快速定位你需要的文章，避免迷失在 250 篇的海洋里
- 专题按 20 个维度组织，总计 238 篇正文 + 12 篇附录
- 每个维度有明确的定位：理论深度 vs 实战落地
- 面试高频提问：这个专题覆盖了 VM 的哪些方面？如何快速找到我需要的文章？
250 篇听起来很多，但通过 20 个维度的组织，每一篇都有清晰的定位。以下是每个维度的定位和推荐阅读顺序：
2.1 维度速览表
| 维度 | 篇数 | 定位 | 推荐阅读 |
|---|---|---|---|
| A. 架构设计篇 | 15 | 全局架构、设计哲学、组件关系 | #01-#15 必读（建立全局认知） |
| B. 组件深潜篇 | 25 | 按组件垂直深挖源码实现（含去重专题：写入/查询双阶段去重） | #16-#40（含 #29b 去重专题，深入理解核心组件） |
| C. 存储引擎篇 | 15 | storage/mergeset/encoding/cache | #41-#55 核心（理解性能基础） |
| D. 查询引擎篇 | 15 | promql/metricsql/netstorage | #56-#70（查询优化必读） |
| E. 工具链篇 | 20 | vmagent/vmalert/vmauth/vmbackup/vmgateway | #71-#90（运维必备） |
| F. 集成生态篇 | 10 | Grafana/k8s/Prometheus Operator/HA/TLS | #91-#100（快速上手） |
| G. 排障调优篇 | 15 | 慢查询/cardinality/OOM/写入瓶颈/pprof | #101-#115 实操（问题诊断） |
| H. 进阶专题篇 | 15 | decimal/bytesutil/fastcache/fs/consistenthash | #116-#130（深入理解） |
| I. 运维实践篇 | 15 | 迁移/k8s 部署/容量规划/对象存储 | #131-#145（生产环境） |
| J. 生产极限篇 | 15 | 10 亿 series/百万 samples-s/多租户 | #146-#160（大规模场景） |
| K. 源码追踪篇 | 15 | 完整链路追踪：HTTP 到 Part 文件 | #161-#175 硬核（源码阅读） |
| L. VictoriaLogs 协同篇 | 10 | LogQL/vlogscli/指标日志关联 | #176-#185（一体化可观测性） |
| M. 压轴总结篇 | 15 | PromQL 深潜/性能极限/工程哲学 | #186-#200（收尾升华） |
| N. Cluster 集群专题篇 | 8 | 分布式架构/数据路由/查询聚合 | #201-#208 生产核心 |
| O. vmgateway API 网关篇 | 5 | 认证/限流/路由/企业版特性 | #209-#213（API 网关） |
| P. vmui 前端技术篇 | 5 | React UI/查询构建/Dashboard | #214-#218（用户界面） |
| Q. 安全加固专题篇 | 5 | TLS/RBAC/审计日志/网络隔离 | #219-#223（安全加固） |
| R. 对象存储集成篇 | 5 | S3/GCS/冷热分层/成本优化 | #224-#228（存储扩展） |
| S. 附录篇 | 12 | 速查地图/API 端点/错误码 | A1-A12 工具书（日常参考） |
| T. 服务发现专题篇 | 10 | K8s/AWS/Azure/Consul/DNS 云厂商集成 | #229-#238 必读（监控采集） |
| 总计 | 238 篇正文 + 12 篇附录 = 250 篇 |
我理解源码的意思是说
250 篇源码专题就像一本**《VictoriaMetrics 源代码从入门到精通》** ------从目录设计到内容深度，都是经过精心规划的，目的是让读者能够从理论到实战，从会用到底层原理全方位掌握这个项目。
各维度的角色详解：
- A 架构设计篇（#01-#15） = 书的**"前言 + 概述 + 作者序"** 。告诉你 VM 是什么项目、解决了什么问题、为什么这么设计，读完脑子里要有 VictoriaMetrics 的整体轮廓：三层架构（vminsert/vmstorage/vmselect）、MergeSet 存储引擎、Cluster 模式。目标：建立全局认知，而不是陷入细节。
- B 组件深潜 + C 存储引擎（#16-#55） = 书的**"核心技术章节"** 。B 是"解剖学"------按组件垂直深挖源码实现；C 是"引擎原理"------讲清楚 MergeSet 是怎么工作的、为什么能省 7x RAM。这是专题的"硬核"部分，需要反复研读源码。
- D 查询引擎 + E 工具链 + F 集成生态（#56-#100） = 书的**"应用实战章节"** 。D 告诉你查询是怎么执行的；E 介绍 vmagent/vmalert/vmbackup 等工具链；F 教你如何与 Grafana/k8s/Prometheus Operator 集成。目标：把理论落地到实践。
- G 排障调优 + I 运维实践（#101-#145） = 书的**"故障排除 + 运维手册"** 。G 告诉你遇到 OOM、慢查询、cardinality 爆炸怎么办；I 教你如何在生产环境部署、迁移、规划容量。这是"下山历练"------从理论到实战的桥梁。
- H 进阶专题（#116-#130） = 书的**"高级进阶章节"**。深入 decimal/bytesutil/persistentqueue/histogram_quantile 等核心库的原理。这部分适合想要深入理解底层实现细节的读者。
- K 源码追踪（#161-#175） = 书的**"案例研究章节"**。完整追踪一条数据的旅程：从 HTTP 入口到 Part 文件、从 PromQL 解析到结果返回。如果前面的章节是"拆解零件"，K 就是"把零件组装起来运行"------让你看到完整的系统是如何协同工作的。
- M 压轴总结（#186-#200） = 书的**"升华 + 哲学思考"**。PromQL 深潜、性能极限、工程哲学。这部分帮助你从"会用"升华到"理解为什么这样设计"。
- N-T 专题篇（#201-#238） = 书的**"专题附录"** 。Cluster 集群、vmgateway API 网关、vmui 前端、安全加固、对象存储、服务发现。这是生产环境必备的高级话题。
- S 附录篇（A1-A12） = 书的**"工具书部分"**：API 速查表、错误码对照表、配置参数说明。日常开发运维时随手翻阅，不需要按顺序读。
学习避坑指南：
- 不要从中间开始------没有全局认知，直接看源码会迷失在细节里
- 不要只看不练------每篇都配套源码链接，建议 clone 代码边看边调试
- 附录是工具书------遇到问题时再查，不需要提前背下来
- 不要跳阶段------武功要一层层练，心急吃不了热豆腐
2.2 推荐阅读路径
根据不同的学习目标，这里提供三条推荐阅读路径：
- 路径一：快速入门（5 篇，约 3 小时）
#01 设计哲学 → #02 全局架构 → #04 整体数据流 → #11 开源生态 → #12 源码阅读路线图 - 路径二：深度理解（20 篇，约 2 天）
完成路径一后，继续 #41 MergeSet vs LSM Tree → #47 commonPrefix 压缩 → #51 压缩算法 → #54 TSIDCache → #56 PromQL 执行引擎 - 路径三：生产专家（50+ 篇，约 1 周）
完成路径二后，系统阅读 G 排障调优篇（#101-#115）、I 运维实践篇（#131-#145）、J 生产极限篇（#146-#160），以及 K 源码追踪篇（#161-#175）
必记闭环逻辑（核心考点）
250 篇源码专题按 20 个维度组织，覆盖理论深度（A-M）和实战落地（G/I）。推荐从 A 架构设计篇开始（建立全局认知），按需深入组件原理（#16-#55）和源码追踪（#161-#175），附录（A1-A12）作为日常工具书参考。
三、组件体系全貌：从 HTTP 入口到 Part 文件的全链路
思考记忆提示 --- 本节是专题的"骨架"------理解组件体系，后续各篇才有上下文
- VM 分为三层：vminsert（写入）→ vmstorage（存储）→ vmselect（查询）
- Single-Node 模式三合一，Cluster 模式可分离部署
- 面试高频提问：VictoriaMetrics 的组件有哪些？Cluster 模式下各组件如何协作？
VictoriaMetrics 的组件体系非常清晰。无论你是使用 Single-Node 模式还是 Cluster 模式，理解这三级架构都是理解 VM 的基础。
3.1 三层架构概述
VictoriaMetrics 架构分层
│
├── [1] 应用层 (app/)
│ ├── vminsert --- 写入接入层（Prometheus/InfluxDB/DataDog/OTel 等 12+ 协议）
│ ├── vmselect --- 查询执行层（PromQL/MetricsQL/GraphiteQL + 查询调度）
│ └── vmstorage --- 数据存储层（Cluster 模式核心）
│
├── [2] 存储核心层 (lib/storage/)
│ ├── Storage --- 全局协调器：分区/缓存/基数限制
│ ├── Table --- 表级抽象：按月分区生命周期
│ ├── Partition --- 分区级抽象：In-Memory/Small/Big Parts + indexDB
│ └── indexDB --- 倒排索引引擎：8 种索引前缀
│
├── [3] MergeSet 存储引擎 (lib/mergeset/)
│ ├── Table --- 分片/合并调度/刷盘策略
│ ├── Part --- metaindex + index + items + lens 四文件
│ └── InmemoryPart --- 内存未排序 Part，按 pendingRowsFlushInterval 定时刷盘
│
└── [4] 压缩编码层 (lib/encoding/)
├── MarshalType --- 6 种压缩类型
└── NearestDelta 算法 --- Counter/Gauge 自适应差分编码 + ZSTD3.2 Cluster 集群架构：核心重点
设计精髓
VictoriaMetrics Cluster 是生产环境的标准部署模式：三层分离（vminsert/vmstorage/vmselect），每层都可以独立水平扩展。通过 -cluster.mode 开启，支持 accountID/projectID 多租户隔离，支撑 100 万到 10 亿级 series 规模。Single-Node 模式仅用于快速验证和小型场景，集群模式才是 VM 的"主战场"。
以下是 VictoriaMetrics Cluster 的典型架构图（生产环境标准部署）：
| 特性 | Single-Node | Cluster |
|---|---|---|
| 进程数 | 1 个进程 | 3 种角色：vminsert、vmstorage、vmselect |
| 扩展方式 | 垂直扩展（加 CPU/内存/磁盘） | 水平扩展（增加 vmstorage/vmselect 节点） |
| 适用规模 | < 100 万 series | 100 万 ~ 10 亿 series |
| 推荐场景 | 本地开发、测试、小型监控 | 生产环境、中大型监控平台 |
小贴士
Single-Node 模式用一行命令即可启动，非常适合本地验证和测试。但生产环境必须使用 Cluster 模式------因为单机无法水平扩展，也无法支撑多租户场景。