前言

在现代分布式系统、日志系统、消息队列和数据库中，高效、可靠的写入与持久化机制是系统核心能力之一。传统的线性日志虽然简单，但在长时间运行、大规模数据场景下存在扩展性瓶颈。**Segmented Log（分段日志）**正是一种应对这些问题的设计，通过将日志拆分为多个可管理的段，提升写入性能、便于清理与恢复。

定义

Wiki 中关于分段日志的定义不直接存在，结合主流系统的实践，可以给出如下定义：

A segmented log is a log structure divided into multiple smaller log files or segments, each acting as a manageable unit for write, read, and cleanup, improving performance, reliability, and scalability in persistent logging systems.

简而言之：Segmented Log 是将日志划分为多个段，每个段独立读写、存储、回放，支持高效管理。

工作原理

一句话：通过分段管理日志文件，实现高效写入、快速回放与灵活清理。

基本流程：

  1. 日志系统按顺序写入当前活跃段（active segment）；
  2. 当前段写满后，生成新段继续写；
  3. 老段（cold segment）只读或归档，不再写入；
  4. 根据系统策略（如消费进度、checkpoint）清理过期段；
  5. 在恢复时，从最近 checkpoint 向后按段顺序回放日志。

属性与指标

Segmented Log 关注的关键属性如下：

  1. 写入吞吐（Write Throughput）：顺序写活跃段，具备高性能；
  2. 读取性能（Read Efficiency）：段内顺序读 + 内存索引提升查询速度；
  3. 持久性与可靠性：每个段持久化，崩溃恢复更稳定；
  4. 回放效率：分段加速日志重放过程；
  5. 日志清理策略：基于 TTL 或 offset/LSN 的段回收；
  6. 空间管理：支持异地备份、归档冷段，降低主存储压力；
  7. 可扩展性：多个段可并行压缩、复制、分发；
  8. 容错能力：段损坏时影响范围有限，易于修复。

类型

按段角色分类：

  1. Active Segment 当前活跃写入段，顺序追加写入。

  2. Inactive Segment 历史段，仅供读取或回放，不再写入。

  3. Archived Segment 已清理或转移的段，通常压缩后存储于冷数据层。

按段策略分类：

  1. 定长段（Fixed-size Segment） 每个段固定大小（如 128MB），便于管理与优化。

  2. 滚动段（Rolling Segment） 时间或事件驱动切段，如每小时/每天生成新段。

  3. 可变段（Dynamic Segment） 根据写入速率或负载动态调整段大小。

应用场景

Segmented Log 广泛应用于以下系统：

  1. 消息队列系统：如 Apache Kafka、Redpanda、Pulsar 等基于分段日志构建；
  2. 数据库引擎：如 RocksDB、ClickHouse、TimescaleDB 使用分段 WAL；
  3. 分布式存储系统：如 HDFS、SeaweedFS，写入日志采用分段优化；
  4. 共识算法：如 Raft 协议的 log entries 分段处理；
  5. 文件同步系统：如 Dropbox Delta Sync，按段比对变化；
  6. 区块链系统：如 Tendermint、Ethereum 2.0 使用分段存储区块；
  7. 日志分析平台：如 Loki、Fluentd 中日志写入和压缩采用分段策略。

常见产品与实现

典型采用 segmented log 的系统包括：

  1. Apache Kafka：核心以分段日志文件为设计基础；
  2. RocksDB：LSM-Tree 中 WAL 采用分段管理；
  3. ClickHouse：MergeTree 引擎数据文件按段写入；
  4. etcd / TiKV：底层 raft 日志为分段式；
  5. Apache Pulsar：Segmented WAL 架构便于 broker 崩溃恢复；
  6. Apache BookKeeper：分布式 ledger 按 entry segment 管理；
  7. Redpanda：零拷贝、高效分段日志结构；
  8. InfluxDB：时间序列数据写入采用按时间分段的 WAL。