3. InfluxDB 架构解析：存储引擎 TSM、WAL、索引结构、数据分片

InfluxDB 的架构设计围绕时序数据的高吞吐写入、高效压缩存储与快速查询展开。其核心组件包括 TSM（Time-Structured Merge Tree）存储引擎、WAL（Write-Ahead Log）、倒排索引以及数据分片（Shard）。理解这些组件的工作原理，是进行性能调优与故障排查的基础。

InfluxDB 核心架构组件关系图 HTTP / UDP 写入 WAL (预写日志) Cache (缓存) TSM 文件 查询请求 倒排索引 TSM 读取 Shard (数据分片) 按时间范围 + 分区 TSM 文件集合 每个 Shard 独享 WAL 段文件 持久化保障 写入路径：HTTP → WAL → Cache → TSM 文件；查询路径：查询请求 → 倒排索引 → TSM 文件

3.1 TSM 存储引擎

TSM 是 InfluxDB 的专用存储引擎，针对时序数据的时间有序性、高写入吞吐和列式压缩进行了深度优化。一个 TSM 文件由多个段（Segment）组成，每个段包含一个 Index Block 和多个 Data Block。

组件 说明 性能影响
Index Block 存储 Series Key 到 Data Block 位置的映射，支持二分查找 影响查询时的定位速度
Data Block 按列存储时间戳、字段值，使用差值编码、游程编码、Snappy 压缩 影响存储空间与 I/O 效率
Bloom Filter 快速判断 Series Key 是否存在于当前 TSM 文件中 减少不必要的文件读取
调优要点： TSM 文件在达到阈值（默认 2GB）后会触发合并（Compaction）。合并过程会清理已删除的数据、合并小文件、重新压缩。适当调整 max-compaction-full-write-concurrency 可提升合并效率，但需注意磁盘 I/O 压力。

3.2 WAL（Write-Ahead Log）

WAL 是 InfluxDB 写入可靠性的第一道防线。所有写入请求首先追加到 WAL 文件，然后写入内存中的 Cache。当 WAL 文件达到大小阈值（默认 10MB）或时间阈值（默认 10 分钟）时，会被刷新到 TSM 文件。

  • 写入流程： 写入请求 → 序列化 → 追加到当前 WAL 段文件 → 更新 Cache → 返回成功。
  • 恢复流程： 节点重启后，从 WAL 文件重放未刷新的数据到 Cache，确保数据不丢失。
  • 性能影响： WAL 的写入延迟直接影响写入 P99 延迟。建议将 WAL 存储在独立的 SSD 或高性能磁盘上。
注意： 如果 WAL 文件损坏或丢失，未刷新的数据将永久丢失。生产环境中务必启用 wal-fsync-delay 并配置合理的副本策略。
WAL 写入与刷新流程 写入请求 追加 WAL 更新 Cache 返回成功 WAL 达到阈值 刷新到 TSM 完成

3.3 索引结构：倒排索引

InfluxDB 使用倒排索引（Inverted Index）来加速基于 Tag 的查询。每个 Tag Key-Value 对都会维护一个包含所有匹配 Series ID 的列表。查询时，通过 Tag 条件快速定位到对应的 Series ID 集合，再通过 Series ID 找到对应的 TSM 数据块。

索引类型 存储内容 查询场景
Tag 倒排索引 Tag Key-Value → Series ID 列表 SELECT * FROM cpu WHERE host='server01'
Series ID 索引 Series ID → Series Key（Measurement + Tags） 查询结果映射到具体序列
TSM 文件索引 Series Key → TSM 文件 + 偏移量 定位数据在磁盘上的位置
性能影响： 倒排索引完全存储在内存中（TSi 索引格式）。当 Series 基数（Cardinality）过高时，内存占用会急剧增加。建议将 Series 基数控制在 1000 万以内，避免 OOM。

3.4 数据分片（Shard）

InfluxDB 将数据按时间范围划分为多个 Shard。每个 Shard 是一个独立的存储单元，包含自己的 TSM 文件集合、WAL 和 Cache。Shard 的划分由 retention policy 中的 SHARD DURATION 控制。

  • 默认分片时长： 小于 2 天：1 小时；2 天 ~ 6 个月：1 天；大于 6 个月：7 天。
  • 分片与性能： 分片过小会导致大量小文件，增加文件句柄和合并开销；分片过大会导致单个分片数据量过大，查询和合并效率下降。
  • 分片与高可用： 在集群模式下，Shard 可以分布在不同的节点上，实现读写负载均衡和故障隔离。
数据分片（Shard）结构 时间轴（按 Shard Duration 划分） Shard 1 2024-01-01 ~ 2024-01-02 Shard 2 2024-01-02 ~ 2024-01-03 Shard 3 2024-01-03 ~ 2024-01-04 Shard 4 2024-01-04 ~ 2024-01-05 TSM + WAL + Cache TSM + WAL + Cache TSM + WAL + Cache TSM + WAL + Cache 每个 Shard 独立管理自己的 TSM 文件、WAL 和 Cache，互不干扰

3.5 写入路径与性能关键点

一次完整的写入请求经过以下路径：

  1. 解析与验证： 解析 Line Protocol，验证 Measurement、Tag、Field 格式。
  2. 写入 WAL： 序列化后追加到当前 WAL 段文件，确保持久化。
  3. 更新 Cache： 将数据写入内存中的 Cache，同时更新倒排索引。
  4. 返回成功： 写入请求返回 204 No Content。
  5. 异步刷新： 后台线程将 Cache 中的数据排序、压缩后写入 TSM 文件。
性能瓶颈识别： 如果写入延迟高，优先检查 WAL 磁盘的 iowait 和 await 指标。如果 WAL 磁盘性能不足，可考虑将 WAL 迁移到更高性能的存储设备，或调整 wal-fsync-delay 参数（但需权衡数据安全性）。

3.6 关键配置参数速查

参数 默认值 说明 调优建议
max-series-per-database 1000000 每个数据库允许的最大 Series 数量 根据内存容量调整，避免 OOM
max-values-per-tag 100000 每个 Tag Key 允许的最大 Tag Value 数量 防止高基数 Tag 导致索引膨胀
cache-snapshot-write-cold-duration 10m Cache 在无写入后多久刷新到 TSM 写入频繁时可适当减小，减少内存占用
compact-full-write-concurrency 4 TSM 文件合并的并发数 磁盘 I/O 能力强时可适当增加
架构总结： InfluxDB 通过 WAL 保证写入可靠性，通过 Cache 提供低延迟写入，通过 TSM 引擎实现高效压缩与存储，通过倒排索引加速 Tag 查询，通过 Shard 实现数据隔离与水平扩展。理解这些组件的协同关系，是进行性能调优的前提。
← 上一章 📖 返回目录 下一章 →