3、日志传输层优化：压缩算法选择（LZ4 vs Zstd）、批量传输策略、零拷贝技术应用

日志传输，说白了就是数据从嵌入式设备搬到服务器的那段路。这段路往往很窄——带宽有限、网络不稳定、CPU资源还金贵。我见过太多项目，日志采集端跑得飞快，结果一到传输环节就卡死，CPU飙到100%，网络被打满，最后连业务逻辑都受影响。

所以传输层优化，是日志监控系统的咽喉。今天咱们就聊聊三个核心手段：压缩算法怎么选、批量传输怎么玩、零拷贝技术怎么落地。

3.1 压缩算法选择：LZ4 vs Zstd

压缩这事儿，本质是拿CPU时间换网络带宽。但嵌入式环境里，CPU时间比带宽更值钱。你想想看，一个跑着实时控制任务的ARM Cortex-A72，你敢让它花50%的算力去压缩日志吗？

我这些年用下来，最顺手的两个算法就是LZ4和Zstd。它们各有千秋，选哪个得看场景。

3.1.1 LZ4：极速压缩，适合实时性要求高的场景

LZ4的特点就一个字——快。它的压缩速度能达到1GB/s级别，解压速度更是夸张。我在一个车载日志采集项目里用过LZ4，当时要求日志从产生到发送出去不能超过5毫秒延迟。用LZ4压缩，压缩比大概2:1，但CPU占用只有不到5%。

适合场景：

• 日志产生速率极高（每秒几百MB）
• 对延迟敏感（比如实时控制日志）
• CPU资源紧张（比如跑着多个业务进程）

// LZ4压缩示例
#include <lz4.h>

int compress_log(const char* src, int src_size, char* dst, int dst_capacity) {
    int compressed_size = LZ4_compress_default(src, dst, src_size, dst_capacity);
    if (compressed_size <= 0) {
        // 压缩失败，直接发送原始数据
        return -1;
    }
    return compressed_size;
}

3.1.2 Zstd：高压缩比，适合带宽受限的场景

Zstd是Facebook开源的算法，压缩比能到3:1甚至5:1。我在一个物联网项目里用过，设备通过4G网络上传日志，流量费是按MB算的。用Zstd压缩后，流量费直接砍了一半。

但代价是CPU占用高。Zstd的压缩速度比LZ4慢一个数量级。不过解压速度还行，服务器端扛得住。

适合场景：

• 网络带宽极窄（比如2G/3G网络）
• 流量费用敏感（比如按量计费的IoT）
• CPU资源相对充裕（比如有专用压缩核）

// Zstd压缩示例
#include <zstd.h>

int compress_log_zstd(const char* src, int src_size, char* dst, int dst_capacity) {
    int compressed_size = ZSTD_compress(dst, dst_capacity, src, src_size, 3); // level=3
    if (ZSTD_isError(compressed_size)) {
        return -1;
    }
    return compressed_size;
}

3.1.3 选型对比表

指标	LZ4	Zstd
压缩速度	极快（~1GB/s）	中等（~200MB/s）
解压速度	极快（~2GB/s）	快（~500MB/s）
压缩比	~2:1	~3:1 ~ 5:1
CPU占用	低（<5%）	中高（10-30%）
适用场景	实时性高、CPU紧张	带宽受限、流量敏感

3.2 批量传输策略

单条日志一条条发，那是新手干的事。网络传输有固定开销——TCP连接建立、三次握手、ACK确认，这些开销跟数据量无关。你发1字节和发1KB，网络延迟差不了多少。

所以批量传输的核心思路：攒一批，一起发。

3.2.1 批量策略设计

我常用的策略有两种：

1. 时间触发：每100ms或500ms发一次。适合日志产生速率稳定的场景。
2. 数量触发：攒够100条或1KB再发。适合日志产生不规律、但总量大的场景。
3. 混合触发：时间和数量谁先到就发。这是最稳妥的做法。

// 批量传输策略示例
typedef struct {
    char buffer[64 * 1024];  // 64KB缓冲区
    int offset;
    uint64_t last_send_time;
    int batch_count;
} BatchSender;

void batch_send(BatchSender* sender, const char* log, int len) {
    // 检查缓冲区是否够用
    if (sender->offset + len > sizeof(sender->buffer)) {
        flush(sender);  // 满了，立即发送
    }
    
    // 拷贝日志到缓冲区
    memcpy(sender->buffer + sender->offset, log, len);
    sender->offset += len;
    sender->batch_count++;
    
    // 检查是否达到发送条件
    uint64_t now = get_timestamp_ms();
    if (sender->batch_count >= 100 || (now - sender->last_send_time) > 500) {
        flush(sender);
    }
}

3.2.2 批量压缩

批量传输和压缩可以结合。先攒一批日志，然后整体压缩，再发送。这样压缩比更高，因为压缩算法对重复模式更敏感。

我做过测试：单条日志压缩比只有1.5:1，但攒够100条一起压缩，压缩比能到3:1。原因很简单——日志里有很多重复的字段（时间戳前缀、模块名、日志级别），批量压缩能把这些冗余去掉。

3.3 零拷贝技术应用

零拷贝，这个名字听起来高大上，其实核心思想就一句话：减少数据在内存里的搬运次数。

传统的数据发送流程是这样的：

1. 应用程序把数据从用户空间拷贝到内核空间
2. 内核把数据从内核空间拷贝到socket缓冲区
3. 网卡从socket缓冲区把数据拷贝到硬件发送队列

你想想看，一份数据在内存里被搬了三次。每次拷贝都消耗CPU和内存带宽。对于日志这种高频小数据，这个开销非常可观。

3.3.1 sendfile：最常用的零拷贝

如果日志数据已经写到了文件里（比如日志文件），可以用sendfile直接发送，省掉用户空间到内核空间的拷贝。

// sendfile零拷贝发送日志文件
#include <sys/sendfile.h>

int send_log_file(int socket_fd, int file_fd, off_t* offset, size_t count) {
    ssize_t sent = sendfile(socket_fd, file_fd, offset, count);
    if (sent == -1) {
        perror("sendfile failed");
        return -1;
    }
    return sent;
}

3.3.2 mmap：灵活的内存映射

如果日志数据在内存里（比如环形缓冲区），可以用mmap把内存映射到用户空间，然后直接操作。这样数据不用拷贝，直接就能发送。

// mmap零拷贝示例
#include <sys/mman.h>

void* map_log_buffer(int fd, size_t size) {
    void* addr = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
    if (addr == MAP_FAILED) {
        perror("mmap failed");
        return NULL;
    }
    return addr;
}

3.3.3 零拷贝的注意事项

3.4 本章小结

日志传输层优化，说白了就是三件事：

• 压缩算法：实时性要求高用LZ4，带宽受限用Zstd。别盲目追求高压缩比。
• 批量传输：攒一批再发，时间+数量混合触发。批量大小64KB-256KB最合理。
• 零拷贝：减少数据搬运次数。大块数据用sendfile或mmap，小块数据别折腾。

这三招用好了，日志传输的CPU占用能降一半以上，网络带宽利用率也能翻倍。嗯，这就是我这些年踩坑踩出来的经验。

---