这是我参与8月更文挑战的第14天，活动详情查看：8月更文挑战
逻辑上：
- 消息以 topic 为基本单位划分
- 一个 topic 分为若干个 partition
- partition 中的每一条 msg 写入时，都会分配一个唯一序列号 → offset (relative address)
- 一个 partition 在多个 broker 中都有存储，互为 replica
- broker 中的一个 partition → 一个 Log 对象
物理上：
-
Log ⇒ 对应物理存储中一个文件夹
-
Log 命名 ⇒ -。topic: user_topic
- user_topic-0
- user_topic-0
-
Log 由多个 LogSegment 组成，分段存储，方便消息的维护和清理
-
LogSegment ⇒ 对应物理存储中的
**.log_file & .index_file**
向 Log 中追加 msg 是顺序写入，而且只有最后一个 LogSegment 才由写入权限，其他的 LogSegment 都被写满而失去写入能力。
为了方便描述，将最后一个 LogSegment 称为**"activeSegment"**，即表示当前活跃的日志分段。
activeSegment 是在不断变化的，所以 LogSegment 中的 logStartOffset 也是在不断变化的，因为需要改变操作文件对象。
文件结构
之前也说了，LogSegment 对应物理存储中的 **.log_file & .index_file** 。这个设计也是处于对消息的检索，index file 分别有：偏移量index file (.index)，时间戳index file (.timeindex) 。每一个 LogSegment 写入消息时，都有一个 baseOffset，表示 LogSegment 段中第一条 msg，而 .log 和 .index 都是由此变量命名的：
- 00000000000000000000.log
- 00000000000000000000.index
- 00000000000000000133.log
- 00000000000000000133.index
此外还有一些 checkpoint file：
- cleaner-offset-checkpoint
- log-start-offset-checkpoint
- recovery-point-offset-checkpoint
- replication-offset-checkpoint
- leader-epoch-checkpoin
主要说明几个吧：
- recovery-point-offset-checkpoint ⇒ LEO
- replication-offset-checkpoint ⇒ HW
- log-start-offset-checkpoint ⇒ logStartOffset
这里提一嘴 HW 的文件结构：
replication-offset-checkpoint文件结构很简单：
- 第一行：版本号，当前是0
- 第二行：当前写入的Topic+Partition的记录个数
- 其他每行: topic 空格 partition 空格 offset
而这个文件存放在整个 kafka log 文件夹中，作为一个 checkpoint file 见证 kafka server 中全部分区的 HW 形式。
日志格式
这里我们进入日志内部，看看日志本身的存储是怎么样的？
首先日志的写入是由 client → accumulator → server。在 client 端发送的 msg 是：ProducerBatch，其中包含着若干 ProducerRecord。而到真实存储这，存储的消息集称为：RecordBatch，其中包含的消息被存放在：Record。
- ProducerBatch ⇒ RecordBatch
- ProducerRecord ⇒ Record
