4、日志存储架构：环形缓冲区设计、内存映射文件、SQLite嵌入式数据库在日志中的应用

日志存储，说白了就是怎么把数据又快又稳地写进硬盘。我见过不少项目，日志系统一跑起来，CPU占用直接飙到30%，电机控制周期都被拖垮了。嗯，这里要讲清楚三个核心武器：环形缓冲区、内存映射文件、还有SQLite。

4.1 环形缓冲区：无锁设计的基石

先说说环形缓冲区。为什么需要它？因为直接写文件太慢了。一次fprintf调用，可能耗时几毫秒，而运动控制周期只有几百微秒。你想想看，这怎么扛得住？

环形缓冲区的思路很简单：在内存里划一块固定大小的区域，用两个指针（读指针和写指针）来回转圈。写日志时只往缓冲区里塞数据，读日志时再从缓冲区里取数据写到文件。这样写操作几乎不耗时。

我在项目中遇到过一个问题：缓冲区大小设成1024字节，结果日志一多就覆盖了。后来我改成4096字节，配合水位线告警，才彻底解决。

下面是一个典型的环形缓冲区实现：

typedef struct {
    uint8_t *buffer;
    volatile uint32_t head;  // 写指针
    volatile uint32_t tail;  // 读指针
    uint32_t size;
} ring_buffer_t;

// 写入一个字节
int ring_buffer_write(ring_buffer_t *rb, uint8_t data) {
    uint32_t next_head = (rb->head + 1) % rb->size;
    if (next_head == rb->tail) {
        return -1;  // 缓冲区满
    }
    rb->buffer[rb->head] = data;
    rb->head = next_head;
    return 0;
}

// 读取一个字节
int ring_buffer_read(ring_buffer_t *rb, uint8_t *data) {
    if (rb->head == rb->tail) {
        return -1;  // 缓冲区空
    }
    *data = rb->buffer[rb->tail];
    rb->tail = (rb->tail + 1) % rb->size;
    return 0;
}

4.2 内存映射文件：零拷贝写入

环形缓冲区解决了写入速度问题，但数据最终还是要落盘。传统做法是fwrite，但每次写入都要经过用户态到内核态的切换。说白了，太慢了。

内存映射文件（mmap）就不一样。它把文件直接映射到进程的虚拟地址空间，写内存就是写文件。没有拷贝，没有系统调用，性能直接拉满。

我建议在运动控制系统中这样用：

1. 预分配一个固定大小的文件（比如64MB）
2. 用mmap映射到内存
3. 环形缓冲区满了，就把数据memcpy到映射区
4. 定期调用msync强制刷盘

#include <sys/mman.h>
#include <fcntl.h>
#include <unistd.h>

// 映射日志文件
void* map_log_file(const char *path, size_t size) {
    int fd = open(path, O_RDWR | O_CREAT, 0644);
    if (fd < 0) return NULL;
    
    // 扩展文件到指定大小
    ftruncate(fd, size);
    
    // 映射到内存
    void *addr = mmap(NULL, size, 
                      PROT_READ | PROT_WRITE,
                      MAP_SHARED, fd, 0);
    close(fd);
    return addr;
}

// 写入日志（零拷贝）
void write_log(void *mapped, uint32_t offset, 
               const uint8_t *data, uint32_t len) {
    memcpy((uint8_t*)mapped + offset, data, len);
}

4.3 SQLite：结构化日志的利器

环形缓冲区和mmap适合存原始二进制数据。但如果你需要查询日志、按时间筛选、或者做统计分析，那就得上数据库了。

SQLite是嵌入式系统的首选。它不需要单独的数据库服务，一个.so文件搞定一切。我见过有人在STM32上跑SQLite，虽然慢了点，但功能确实强大。

在运动控制日志中，我通常这样设计表结构：

CREATE TABLE motion_log (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    timestamp_us INTEGER NOT NULL,   -- 微秒级时间戳
    axis_id INTEGER NOT NULL,        -- 轴编号
    position REAL,                   -- 实际位置
    velocity REAL,                   -- 实际速度
    torque REAL,                     -- 实际转矩
    target_position REAL,            -- 目标位置
    error_code INTEGER,              -- 错误码
    raw_data BLOB                    -- 原始二进制数据
);

-- 按时间查询的索引
CREATE INDEX idx_timestamp ON motion_log(timestamp_us);
-- 按轴查询的索引
CREATE INDEX idx_axis ON motion_log(axis_id);

写入时用事务批量提交，性能会好很多：

// 批量写入日志
void batch_write_logs(sqlite3 *db, log_entry_t *entries, int count) {
    sqlite3_exec(db, "BEGIN TRANSACTION", NULL, NULL, NULL);
    
    sqlite3_stmt *stmt;
    sqlite3_prepare_v2(db, 
        "INSERT INTO motion_log VALUES(NULL,?,?,?,?,?,?,?,?)",
        -1, &stmt, NULL);
    
    for (int i = 0; i < count; i++) {
        sqlite3_bind_int64(stmt, 1, entries[i].timestamp);
        sqlite3_bind_int(stmt, 2, entries[i].axis_id);
        sqlite3_bind_double(stmt, 3, entries[i].position);
        // ... 绑定其他字段
        sqlite3_step(stmt);
        sqlite3_reset(stmt);
    }
    
    sqlite3_finalize(stmt);
    sqlite3_exec(db, "COMMIT", NULL, NULL, NULL);
}

4.4 三种方案的选型对比

说了这么多，到底该用哪个？我整理了一个对比表：

特性	环形缓冲区	内存映射文件	SQLite
写入速度	纳秒级	微秒级	毫秒级
查询能力	无	弱（需自行解析）	强（SQL支持）
断电保护	无	需msync	WAL模式
内存占用	固定大小	文件大小	动态增长
适用场景	实时日志缓存	高速数据采集	结构化日志查询

我个人习惯这样搭配：环形缓冲区做第一级缓存，mmap做第二级持久化，SQLite做第三级归档查询。三级架构下来，既保证了实时性，又兼顾了查询能力。

4.5 整体架构图

下面这张图展示了三种存储方案的协作关系：

你看，三层架构各司其职。环形缓冲区扛住实时写入压力，mmap提供持久化保障，SQLite负责数据检索。我在实际项目中，环形缓冲区满了就触发一次mmap写入，mmap文件达到阈值后再导入SQLite。这样CPU占用始终控制在5%以内。

---

公众号:蓝海资料掘金营，微信deep3321