4. 日志采集器核心实现：异步日志采集架构、缓冲区设计、批量写入策略、磁盘I/O优化

日志采集器是整个追踪系统的起点。说白了，它负责把业务代码里吐出来的日志，安全、高效地送到下游。我见过不少团队，前期不重视采集器设计，结果流量一上来，要么丢日志，要么把业务线程卡死。

这一章，我们重点聊四个核心点：异步架构、缓冲区设计、批量写入、磁盘I/O优化。每个点我都会结合项目里的实际踩坑经验来讲。

4.1 异步日志采集架构

先问一个问题：日志采集为什么一定要异步？

你想想看，如果每次打日志都直接写磁盘，业务线程就得等I/O完成。高并发下，磁盘I/O的延迟会直接拖垮业务吞吐量。我曾在某电商大促前压测，发现日志写入占了接口响应时间的30%——这就是典型的同步写入反噬业务。

异步架构的核心思路很简单：业务线程只管把日志丢进内存队列，后台有专门的线程负责消费和写入。这样业务线程几乎零阻塞。

异步日志采集架构的核心原则：

业务线程与I/O线程完全分离
内存队列作为缓冲层，削峰填谷
消费线程按策略批量处理，控制写入频率

下面这张图展示了典型的异步采集流程：

我个人习惯用环形缓冲区（Ring Buffer）作为内存队列的实现。为什么？因为它可以做到无锁或极轻量锁，性能远高于链表队列。Disruptor 就是这方面的经典案例。

4.2 缓冲区设计

缓冲区设计得好不好，直接决定了采集器的性能和可靠性。我见过最惨的一次事故：缓冲区满了之后，新日志直接把旧日志覆盖了，排查问题时发现关键日志全丢了。

设计缓冲区时，有几个关键参数需要权衡：

参数	说明	建议值
缓冲区大小	单个缓冲区能容纳的日志条目数	64K ~ 1M 条目（视内存而定）
缓冲区数量	双缓冲或多缓冲机制中的缓冲区个数	2 ~ 4 个
写入阈值	触发刷盘的日志条目数或数据量	4K ~ 64K 条，或 1MB ~ 8MB
超时阈值	即使未达到写入阈值，最多等待多久必须刷盘	100ms ~ 1s

我的经验：双缓冲机制是最实用的。一个缓冲区用于写入，另一个用于刷盘。写入缓冲区满了之后，交换角色。这样能最大化利用内存，减少锁竞争。

我曾经在项目中用过一个三缓冲方案：写入缓冲区、待刷缓冲区、刷盘中缓冲区。虽然吞吐量更高，但代码复杂度翻倍。对于大多数场景，双缓冲已经足够。

4.3 批量写入策略

批量写入是提升磁盘I/O效率的关键。每次写一条日志和一次写1000条日志，磁盘寻道时间几乎一样。所以，攒一批再写是性价比最高的优化手段。

批量写入策略通常包含两个维度：

数量维度：攒够N条日志，触发一次写入
时间维度：距离上次写入超过T毫秒，即使没攒够也写入

为什么需要时间维度？因为有些场景下日志量很小，如果只等数量阈值，日志可能会在缓冲区里待很久。对于实时性要求高的系统，这不可接受。

下面是一个简单的批量写入伪代码：

class BatchWriter {
    private final List<LogEntry> buffer = new ArrayList<>();
    private final int batchSize = 4096;
    private final long flushIntervalMs = 200;
    private long lastFlushTime = System.currentTimeMillis();

    public void append(LogEntry entry) {
        synchronized (buffer) {
            buffer.add(entry);
            if (buffer.size() >= batchSize) {
                flush();
            }
        }
    }

    public void flush() {
        // 检查是否超时
        long now = System.currentTimeMillis();
        if (now - lastFlushTime >= flushIntervalMs) {
            doFlush();
            lastFlushTime = now;
        }
    }

    private void doFlush() {
        // 将buffer中的数据批量写入磁盘
        // 写入完成后清空buffer
    }
}

注意：批量写入的阈值不是越大越好。过大的批次会导致内存占用飙升，而且一旦进程崩溃，丢失的日志量也更大。我建议根据业务流量动态调整，比如在低峰期用较小的批次，高峰期用较大的批次。

4.4 磁盘I/O优化

磁盘I/O优化是日志采集器性能的最后一公里。前面做得再好，如果写入磁盘的方式不对，一切归零。

我总结了几条实战经验：

顺序写入：尽量让日志文件是顺序追加的，避免随机写入。顺序写入的速度是随机写入的几十倍甚至上百倍。
文件预分配：提前分配好日志文件的空间，避免写入时频繁扩展文件大小。我习惯预分配 64MB 或 128MB 的文件块。
使用直接I/O：绕过操作系统页缓存，减少数据拷贝次数。但要注意，直接I/O要求写入数据对齐，实现起来稍复杂。
异步刷盘：使用 fsync 或 fdatasync 时，不要每条日志都刷。批量刷盘，比如每 100ms 或每 1MB 刷一次。

这里有个对比表，可以直观看到不同I/O方式的性能差异：

I/O方式	吞吐量（MB/s）	延迟（us）	适用场景
顺序写入 + 页缓存	500 ~ 1000	10 ~ 50	大多数场景，通用性好
顺序写入 + 直接I/O	800 ~ 1500	5 ~ 20	高吞吐场景，减少内存占用
随机写入	10 ~ 50	1000 ~ 10000	尽量避免，除非万不得已

避坑指南：我曾经在SSD上做过测试，发现直接I/O在SSD上的优势不如HDD明显。因为SSD的随机读写性能本身就不错。所以，如果你的日志盘是SSD，可以优先考虑页缓存模式，代码更简单，维护成本更低。

另外，文件轮转也是I/O优化的一部分。我习惯按时间或大小轮转日志文件，比如每小时切分一次，或者每个文件达到 256MB 就切分。这样既能控制单个文件的大小，也方便后续的日志清理和归档。

📚 课程目录

4. 日志采集器核心实现：异步日志采集架构、缓冲区设计、批量写入策略、磁盘I/O优化

4.1 异步日志采集架构

4.2 缓冲区设计

4.3 批量写入策略

4.4 磁盘I/O优化