4、数据持久化策略：SQLite轻量数据库、文件系统存储、环形缓冲区设计、内存与Flash管理

聊到边缘计算设备的数据持久化，我脑子里第一个蹦出来的词就是「因地制宜」。你想想看，一个跑在工业现场的网关，跟咱们手机里的App，对数据存储的要求能一样吗？完全不是一回事。

边缘设备资源有限，可能就几百KB的RAM，几MB的Flash。断电、断网是家常便饭。所以，数据怎么存、存哪里、怎么保证不丢，就成了实战中的硬骨头。今天我就把这几年啃下来的经验，掰开了揉碎了跟你聊聊。

4.1 SQLite：轻量级数据库的取舍

说到嵌入式数据库，SQLite绝对是绕不开的名字。它小，真的小，完整编译后也就几百KB。但它功能一点不含糊，支持标准SQL，支持事务，支持ACID。

我个人的习惯是：只要设备有1MB以上的可用Flash，并且数据需要结构化查询（比如按时间、按设备ID检索），我首选SQLite。

但这里有个坑。SQLite在频繁写入时，如果掉电，有损坏风险。虽然它有WAL（Write-Ahead Logging）模式，但嵌入式环境下的突然断电，还是可能让数据库文件处于不一致状态。

⚠️ 避坑指南： 我曾经在一个农业物联网项目中，就因为没处理好掉电保护，导致SQLite数据库文件损坏，一整天的传感器数据全丢了。后来我加了一个「双备份」机制：每次写入前，先复制一份数据库文件，写入成功后再删除旧备份。代价是Flash占用翻倍，但数据安全有了保障。

SQLite在边缘设备上的典型用法，我一般这样配置：

-- 开启WAL模式，提升并发写入性能
PRAGMA journal_mode=WAL;

-- 设置同步模式为NORMAL，平衡性能与安全
PRAGMA synchronous=NORMAL;

-- 设置缓存大小，根据RAM情况调整
PRAGMA cache_size=-2000;  -- 约2MB缓存

嗯，这里要注意，WAL模式虽然好，但它会生成额外的日志文件。如果你的Flash空间捉襟见肘，可以考虑用PRAGMA journal_mode=TRUNCATE，但写入性能会下降一些。

4.2 文件系统存储：简单粗暴但有效

有些场景，数据不需要复杂查询。比如，设备只是把传感器数据按天存成CSV文件，或者把日志按小时切分。这时候，用文件系统存储反而更直接。

我常用的方案是：

  • 日志文件：按日期命名，比如 log_2024_01_15.txt，每天一个文件。超过7天的自动删除。
  • 数据文件：按批次命名，比如 data_001.bin，每个文件存固定数量的数据点。上传成功后立即删除。

文件系统的好处是，你不需要依赖任何第三方库。只要你的RTOS或Linux内核支持文件系统（比如FAT32、LittleFS、SPIFFS），就能直接用。

💡 小技巧： 在嵌入式Linux上，我习惯用 rename() 系统调用来实现原子操作。先把数据写入一个临时文件，写入成功后，再rename成正式文件名。这样即使写入过程中断电，最多丢一个临时文件，不会破坏已有数据。

但文件系统也有短板。频繁的小文件写入，会导致Flash磨损。你想想看，如果每秒钟写一个几字节的小文件，那Flash的寿命会急剧下降。所以，我一般会做一个「写缓冲」：攒够一定数据量，或者每隔一段时间，才真正落盘一次。

4.3 环形缓冲区设计：内存里的环形赛道

环形缓冲区，说白了就是一个固定大小的数组，加上两个指针：读指针和写指针。写指针追着读指针跑，追上了就覆盖旧数据。这玩意儿在数据采集、串口通信、日志记录里太常见了。

我为什么偏爱它？因为它没有动态内存分配，没有碎片问题。在资源受限的MCU上，这简直是救命的设计。

一个典型的环形缓冲区实现，我通常这样写：

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

// 写入一个字节
int ring_buffer_put(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_get(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;
}

你看，代码就这么几行。但实际项目中，我踩过不少坑。比如，在多线程或中断环境下，head 和 tail 的读写必须保证原子性。我曾经在一个项目中，因为没加内存屏障，导致中断服务程序和主循环同时操作缓冲区，数据乱得一塌糊涂。

🔑 核心要点： 环形缓冲区的大小，最好是2的幂次方。这样取模运算可以用位运算替代：index & (size - 1)。性能提升很明显，尤其是在没有硬件除法器的MCU上。

4.4 内存与Flash管理：寸土寸金的艺术

边缘设备的内存和Flash，就像大城市里的房子，寸土寸金。怎么用好每一字节，是嵌入式工程师的基本功。

先说内存管理：

我个人的原则是：能静态分配，绝不动态分配。在MCU上，malloc 和 free 是万恶之源。碎片、泄漏、不确定性，随便一个就能让你的设备跑几个月后突然崩溃。

如果实在需要动态分配，我会用内存池（Memory Pool）。提前划分好固定大小的内存块，需要时从池里取，用完归还。这样没有碎片，分配时间也是确定的。

// 一个简单的内存池示例
#define POOL_SIZE 10
#define BLOCK_SIZE 64

typedef struct {
    uint8_t blocks[POOL_SIZE][BLOCK_SIZE];
    uint32_t free_mask;  // 位图，标记哪些块空闲
} mem_pool_t;

void* pool_alloc(mem_pool_t *pool) {
    // 找到第一个空闲位
    uint32_t bit = __builtin_ctz(pool->free_mask);
    if (bit >= POOL_SIZE) return NULL;
    pool->free_mask &= ~(1 << bit);
    return pool->blocks[bit];
}

void pool_free(mem_pool_t *pool, void *ptr) {
    uint32_t index = ((uint8_t*)ptr - pool->blocks[0]) / BLOCK_SIZE;
    pool->free_mask |= (1 << index);
}

再说Flash管理：

Flash的寿命是有限的。一般的NOR Flash，擦写次数在10万次左右。如果你每秒写一次，那不到两天就报废了。所以，磨损均衡（Wear Leveling） 是必须考虑的。

我常用的策略是：

  • 日志型存储：每次写入追加到新的位置，而不是覆盖旧位置。这样每个扇区的擦写次数更均匀。
  • 数据备份：关键配置参数，存两份。一份在主区域，一份在备份区域。写入时先写备份，再写主区域。读取时校验主区域，如果损坏，从备份恢复。
⚠️ 注意： Flash写入前必须先擦除。而擦除是以扇区（通常4KB或64KB）为单位的。如果你只改一个字节，也得先擦除整个扇区，再重新写入。所以，频繁的小数据修改，对Flash的寿命是灾难性的。我建议把多个小数据打包成一个扇区大小的块，一次性写入。

好了，关于数据持久化，我暂时就想到这些。说白了，没有银弹。SQLite、文件系统、环形缓冲区、内存池，各有各的适用场景。关键是你得清楚你的设备要面对什么样的环境，数据有多重要，资源有多紧张。想清楚这些，你自然就知道该选什么了。

← 上一章 📖 返回目录 下一章 →