第2章日志采集层优化

日志采集层优化：异步日志 vs 同步日志、内存映射文件（mmap）的使用、日志缓冲区设计

日志采集层，说白了就是整个监控系统的「咽喉」。数据能不能及时、完整地送出去，全看这一层扛不扛得住。我见过太多系统，CPU 算力明明够用，结果被日志写入给拖垮了。嗯，今天咱们就聊聊怎么把这层做扎实。

一、同步日志 vs 异步日志：别让日志拖垮主流程

先问个问题：你的日志写入，是同步还是异步？

同步日志，就是每条日志产生时，直接调用 write() 或 fwrite() 写到磁盘。逻辑简单，但代价很大。我在项目中遇到过，一个高频交易系统，每秒产生几万条日志，同步写入直接让主线程的响应时间从 50 微秒飙升到 2 毫秒。你想想看，这谁受得了？

异步日志就不一样了。日志先丢到一个内存缓冲区里，后台有个专门的线程负责刷盘。主线程只管写内存，几乎零阻塞。

核心区别一句话：同步日志让业务线程等磁盘，异步日志让业务线程只管内存。

我个人的习惯是：生产环境一律用异步日志。除非你的日志量极小（比如每秒几十条），或者你明确需要日志写入失败时立即感知，否则别碰同步模式。

来看一个简单的异步日志框架设计思路：

// 伪代码：异步日志核心结构
struct AsyncLogger {
    // 前端缓冲区（业务线程写入）
    char* front_buffer;
    // 后端缓冲区（刷盘线程读取）
    char* back_buffer;
    // 缓冲区大小，通常 4MB ~ 16MB
    size_t buffer_size;
    // 刷盘线程
    pthread_t flush_thread;
    // 条件变量，通知刷盘
    pthread_cond_t flush_cond;
};

// 业务线程调用：写入日志
void log_write(const char* msg) {
    lock();
    memcpy(front_buffer + write_pos, msg, len);
    write_pos += len;
    if (write_pos >= threshold) {
        // 通知刷盘线程
        signal(flush_cond);
    }
    unlock();
}

// 刷盘线程：持续消费
void* flush_thread_func(void* arg) {
    while (1) {
        wait(flush_cond);
        swap(front_buffer, back_buffer);
        write(back_buffer, to_file);
        reset(back_buffer);
    }
}

避坑指南：我曾经犯过一个错——缓冲区满了直接阻塞业务线程。后来改成「丢弃旧日志 + 告警」的策略，宁可丢几条日志，也不能让主流程卡死。记住：日志是辅助，业务才是核心。

二、内存映射文件（mmap）：让日志写入接近内存速度

说到日志写入，很多人第一反应是 write() 或 fwrite()。但如果你追求极致性能，mmap 值得认真考虑。

mmap 的原理很简单：把磁盘文件映射到进程的虚拟地址空间。你往这块内存写数据，操作系统在后台帮你刷到磁盘。说白了，你写的是内存，但数据最终落到了磁盘上。

为什么 mmap 快？因为省去了用户态到内核态的数据拷贝。write() 需要把数据从用户缓冲区拷贝到内核缓冲区，mmap 直接操作内核页缓存，少了一次拷贝。

我在 ARM 平台上做过对比测试：

写入方式	延迟（微秒）	CPU 占用	适用场景
fwrite（带缓冲）	5 ~ 20	中	通用场景
write（直接写）	10 ~ 50	高	实时性要求高
mmap	1 ~ 5	低	高频日志、大文件

看到没？mmap 的延迟只有 fwrite 的几分之一。但要注意，mmap 不是银弹。

警告：mmap 在 ARM 平台上有几个坑：

ARM 的页大小通常是 4KB 或 64KB，mmap 映射必须按页对齐
频繁的 msync() 会触发页错误，反而降低性能
如果日志文件增长太快，mmap 区域需要动态扩展，处理不好会段错误

我个人的做法是：mmap 配合固定大小的环形文件。预分配一个 256MB 的文件，映射到内存，写满了就从头覆盖。这样既避免了动态扩展，又保证了写入速度。

// mmap 环形日志文件示例
int fd = open("log.bin", O_RDWR | O_CREAT, 0644);
ftruncate(fd, 256 * 1024 * 1024);  // 预分配 256MB
char* mapped = mmap(NULL, 256MB, PROT_WRITE, MAP_SHARED, fd, 0);

// 写入日志（循环覆盖）
size_t offset = atomic_add(&write_pos, len) % 256MB;
memcpy(mapped + offset, data, len);

// 定期刷盘（比如每 100ms）
msync(mapped, 256MB, MS_ASYNC);

三、日志缓冲区设计：双缓冲 + 水位线

缓冲区设计，是日志采集层的「心脏」。设计得好，吞吐量翻倍；设计得烂，各种丢数据、卡顿。

我推荐双缓冲机制。说白了就是两个缓冲区轮流用：一个给业务线程写，一个给刷盘线程读。写满了就交换角色。

为什么不用单缓冲？因为锁竞争太激烈。业务线程和刷盘线程抢同一个缓冲区，性能直接腰斩。

来看一个成熟的双缓冲设计：

struct DoubleBuffer {
    char buffer_a[4 * 1024 * 1024];  // 4MB
    char buffer_b[4 * 1024 * 1024];  // 4MB
    char* active;   // 当前可写缓冲区
    char* pending;  // 等待刷盘的缓冲区
    atomic_t write_offset;
    atomic_t flush_flag;
};

// 业务线程写入
void write_log(const char* data, size_t len) {
    char* buf = active;
    size_t offset = atomic_fetch_add(&write_offset, len);
    if (offset + len > BUFFER_SIZE) {
        // 当前缓冲区满了，触发交换
        trigger_swap();
        buf = active;
        offset = atomic_fetch_add(&write_offset, len);
    }
    memcpy(buf + offset, data, len);
}

这里有个关键点：水位线设计。别等到缓冲区满了才刷盘，那样会有写入尖峰。我习惯设置三个水位：

低水位（30%）：正常写入，不触发刷盘
中水位（60%）：后台线程开始异步刷盘
高水位（85%）：强制同步刷盘，防止溢出

经验之谈：缓冲区大小怎么定？我一般按「峰值写入速率 × 最大容忍延迟」来算。比如峰值 100MB/s，容忍延迟 100ms，那缓冲区至少 10MB。再留 2 倍余量，20MB 起步。ARM 平台内存有限，但日志缓冲区别省，省了会出大问题。

四、知识体系总览

下面这张图，把日志采集层的核心逻辑串起来了。你可以看到数据从业务线程出发，经过异步写入、双缓冲、mmap 映射，最终落到磁盘的全过程。

从这张图你能看到，整个日志采集层其实就三个核心环节：异步写入解耦、双缓冲削峰、mmap 加速落盘。每个环节都有坑，但踩过去之后，你会发现日志采集不再是性能瓶颈。

嗯，今天就聊到这儿。日志采集层优化好了，后面的监控分析才能拿到干净、及时的数据。下一层咱们再聊传输层的优化。

📚 课程目录

日志采集层优化：异步日志 vs 同步日志、内存映射文件（mmap）的使用、日志缓冲区设计

一、同步日志 vs 异步日志：别让日志拖垮主流程

二、内存映射文件（mmap）：让日志写入接近内存速度

三、日志缓冲区设计：双缓冲 + 水位线

四、知识体系总览