日志系统性能优化：减少I/O次数，批量写入，异步日志

日志系统跑得慢，往往是I/O在拖后腿。

我见过不少项目，功能逻辑写得挺好，结果一开日志，整个系统响应时间直接翻倍。你想想看，每次打一条日志就写一次磁盘，高频场景下这谁顶得住？

所以今天咱们就聊聊怎么给日志系统提速。核心思路就三个：减少I/O次数、批量写入、异步处理。

为什么I/O会成为瓶颈？

说白了，写磁盘这件事本身就很慢。一次磁盘写入大概要几毫秒，而CPU执行一条指令是纳秒级的。这中间差了百万倍。

我在项目中遇到过这样一个场景：一个网络服务每秒要处理上万条请求，每条请求都打两三条日志。如果每条日志都直接fwrite，那光写日志就把CPU吃满了，业务逻辑反而跑不动。

嗯，这里要注意：高频小I/O是性能杀手。每次写操作都有系统调用开销，频繁调用write()或fwrite()，上下文切换的成本会迅速累积。

批量写入：攒够了再写

批量写入的思路很简单：日志先攒在内存缓冲区里，等缓冲区满了，或者达到一定时间间隔，再一次性写入磁盘。

我习惯的做法是这样的：

#define LOG_BUF_SIZE 4096

static char log_buffer[LOG_BUF_SIZE];
static int buf_pos = 0;

void log_write(const char *msg) {
    int len = strlen(msg);
    // 如果当前消息放不下，先刷盘
    if (buf_pos + len >= LOG_BUF_SIZE) {
        flush_log_buffer();
    }
    memcpy(log_buffer + buf_pos, msg, len);
    buf_pos += len;
}

void flush_log_buffer(void) {
    if (buf_pos > 0) {
        fwrite(log_buffer, 1, buf_pos, log_file);
        fflush(log_file);
        buf_pos = 0;
    }
}

你看，这样就把几十次小写入合并成了一次大写入。磁盘喜欢大块连续写入，讨厌零散小写入。这个做法正好迎合了磁盘的脾气。

异步日志：别让日志阻塞业务

批量写入解决了I/O次数问题，但还没解决阻塞问题。想想看，如果业务线程在flush缓冲区时被卡住，那还是会影响响应时间。

异步日志的思路是：业务线程只管往缓冲区写，刷盘的事交给后台线程去做。

我常用的异步日志架构是这样的：

// 生产者-消费者模型
static pthread_mutex_t log_mutex = PTHREAD_MUTEX_INITIALIZER;
static pthread_cond_t log_cond = PTHREAD_COND_INITIALIZER;
static char *log_queue[QUEUE_SIZE];
static int queue_head = 0, queue_tail = 0;

// 业务线程调用：把日志消息入队
void async_log_write(const char *msg) {
    pthread_mutex_lock(&log_mutex);
    // 如果队列满了，可以丢弃或阻塞等待
    log_queue[queue_tail] = strdup(msg);
    queue_tail = (queue_tail + 1) % QUEUE_SIZE;
    pthread_cond_signal(&log_cond);
    pthread_mutex_unlock(&log_mutex);
}

// 后台线程：从队列取消息并写入磁盘
void *log_worker(void *arg) {
    while (1) {
        pthread_mutex_lock(&log_mutex);
        while (queue_head == queue_tail) {
            pthread_cond_wait(&log_cond, &log_mutex);
        }
        char *msg = log_queue[queue_head];
        queue_head = (queue_head + 1) % QUEUE_SIZE;
        pthread_mutex_unlock(&log_mutex);

        // 批量写入缓冲区
        append_to_buffer(msg);
        free(msg);
    }
    return NULL;
}

这个模型的好处是：业务线程几乎不会被阻塞。入队操作只是内存拷贝，微秒级就能完成。刷盘操作在后台线程里慢慢做，不影响前台响应。

三种方案的性能对比

我拿一个实际项目的数据给大家看看。测试环境是普通SSD，每秒写入10000条日志，每条日志约100字节：

方案	平均耗时（微秒/条）	CPU占用	日志丢失风险
直接写入（每次fwrite）	约120μs	高	无
批量写入（4KB缓冲区）	约8μs	中	无
异步日志（后台线程）	约2μs	低	有（约100ms窗口）

从数据能看出来，异步日志的性能是最好的，但代价是可能丢日志。批量写入是性价比最高的方案，实现简单，效果也不错。

我踩过的坑

我曾经在一个嵌入式项目里用了异步日志，结果发现日志文件里偶尔会出现乱码。排查了半天，原来是多线程竞争缓冲区导致的——两个线程同时往缓冲区里写数据，互相覆盖了。

解决方案很简单：给缓冲区加锁，或者用无锁队列。我后来改成了无锁队列，性能更好，也避免了死锁风险。

还有一个坑：日志文件不要开太大。我见过有人把日志文件设成1GB，结果写满了磁盘，系统直接挂了。现在我的习惯是：单文件不超过100MB，配合日志轮转，自动切分旧文件。

SVG：日志系统性能优化核心逻辑

总结一下

日志系统性能优化，说白了就是三件事：少写、攒着写、异步写。

• 减少I/O次数：合并系统调用，别让每条日志都触发一次write。
• 批量写入：用内存缓冲区攒数据，满了再刷盘。4KB缓冲区是个不错的起点。
• 异步日志：业务线程只管入队，后台线程负责刷盘。性能最好，但要注意丢日志的风险。

我个人建议：先从批量写入开始，实现简单，效果明显。如果对性能要求更高，再上异步日志。别一上来就搞复杂架构，容易翻车。