Redis详解：从内存一致性到持久化策略的思维链条

Redis作为高性能的内存数据库，其工作原理和实现细节值得深入研究。本文将从浅入深，按照清晰的思维链条，分析Redis的内存一致性保证机制、核心数据结构以及持久化策略。

1. Redis主存的一致性保证

1.1 内存一致性的基本机制

Redis作为单线程模型（命令处理层面），通过以下机制保证主存的一致性：

c 复制代码

// Redis主事件循环 (src/server.c)
void aeMain(aeEventLoop *eventLoop) {
    eventLoop->stop = 0;
    while (!eventLoop->stop) {
        // 处理文件事件（客户端连接、命令请求等）
        // 并处理时间事件（定时任务）
        aeProcessEvents(eventLoop, AE_ALL_EVENTS|AE_CALL_AFTER_SLEEP);
    }
}

核心机制：

单线程命令处理：Redis主线程负责处理所有客户端命令，避免了多线程并发访问数据带来的一致性问题
原子操作：Redis的命令是原子执行的，如INCR、DECR等，不会被其他命令中断
事务支持：通过MULTI/EXEC实现命令批量原子执行

c 复制代码

// Redis事务实现片段 (src/multi.c)
void multiCommand(client *c) {
    c->flags |= CLIENT_MULTI;
    addReply(c,shared.ok);
}

void execCommand(client *c) {
    // 执行事务队列中的所有命令
    execCommandReal(c, 0, NULL);
}

1.2 不能保证一致性的情况

尽管Redis有良好的一致性保证机制，但在以下情况下可能无法保证一致性：

Redis崩溃：当Redis实例崩溃时，内存中未持久化的数据将丢失

事务弱一致性：Redis事务不支持回滚机制

sql 复制代码

MULTI
SET key1 value1
WRONGCOMMAND  // 错误命令
SET key2 value2
EXEC          // 执行结果：key1被设置，key2未被设置，不会回滚key1

主从复制延迟：在主从架构中，从节点数据可能落后于主节点

c 复制代码

// 主从复制实现片段 (src/replication.c)
void replicationFeedSlaves(list *slaves, int dictid, robj **argv, int argc) {
    // 向从节点传播命令
}

Redis 6.0之前的I/O多线程：只用于网络I/O处理，核心仍是单线程执行命令
Redis 6.0+的多线程：虽然引入了多线程处理，但命令执行仍是串行的，保证了数据安全

2. Redis核心数据结构

Redis的强大源于其多样化的数据结构，为不同场景提供高效支持。

2.1 String（字符串）

最基本的数据类型，内部实现为简单动态字符串(SDS)：

c 复制代码

// SDS定义 (src/sds.h)
struct sdshdr {
    unsigned int len;  // 已使用长度
    unsigned int free; // 剩余空间
    char buf[];        // 字符数组
};

特点：

二进制安全，可以存储任何二进制数据
预分配空间策略减少内存重分配
O(1)时间复杂度获取字符串长度

2.2 List（列表）

Redis 3.2之前使用ziplist和linkedlist，3.2之后统一使用quicklist：

c 复制代码

// quicklist定义 (src/quicklist.h)
typedef struct quicklist {
    quicklistNode *head;
    quicklistNode *tail;
    unsigned long count;     // 所有元素总数
    unsigned long len;       // quicklistNode节点数量
    // 压缩深度设置等其他属性
} quicklist;

typedef struct quicklistNode {
    struct quicklistNode *prev;
    struct quicklistNode *next;
    unsigned char *zl;       // ziplist数据
    // 其他属性
} quicklistNode;

特点：

双向链表结构，支持双端操作
每个节点使用ziplist压缩存储，平衡了空间和时间效率
适用于消息队列、最新动态等场景

2.3 Hash（哈希表）

当field较少且较小时使用ziplist，否则使用dict（字典）：

c 复制代码

// 字典定义 (src/dict.h)
typedef struct dict {
    dictType *type;
    void *privdata;
    dictht ht[2];     // 两个哈希表，用于渐进式rehash
    long rehashidx;   // rehash索引，标识rehash进度
    int iterators;    // 当前正在使用的迭代器数量
} dict;

特点：

O(1)时间复杂度的查询性能
渐进式rehash设计，避免瞬时压力
适合存储对象和计数器

2.4 Set（集合）

当元素都是整数且数量较少时使用intset，否则使用dict：

c 复制代码

// 整数集合定义 (src/intset.h)
typedef struct intset {
    uint32_t encoding;  // 编码方式
    uint32_t length;    // 元素数量
    int8_t contents[];  // 元素内容
} intset;

特点：

不允许重复成员
支持集合运算（交集、并集、差集）
适合标签、去重等场景

2.5 Sorted Set（有序集合）

当元素较少时使用ziplist，数量较多时使用skiplist（跳跃表）：

c 复制代码

// 跳跃表定义 (src/server.h)
typedef struct zskiplist {
    struct zskiplistNode *header, *tail;
    unsigned long length;
    int level;
} zskiplist;

typedef struct zskiplistNode {
    robj *obj;
    double score;
    struct zskiplistNode *backward;
    struct zskiplistLevel {
        struct zskiplistNode *forward;
        unsigned long span;
    } level[];
} zskiplistNode;

特点：

同时维护了值和分数
O(log(N))的时间复杂度实现了高效的范围查询
适合排行榜、优先级队列等场景

2.6 其他专用数据结构

HyperLogLog：用于基数统计的概率数据结构
Bitmap：位图，用于处理位级别操作
Geospatial：地理位置数据结构
Stream：Redis 5.0引入的消息队列结构

3. Redis持久化策略

为了解决内存数据库的数据持久化问题，Redis提供了多种持久化方案。

3.1 RDB（Redis DataBase）

RDB通过生成数据快照实现持久化：

c 复制代码

// RDB保存函数 (src/rdb.c)
int rdbSave(char *filename, rdbSaveInfo *rsi) {
    // 创建临时文件
    // 将数据写入临时文件
    // 原子性地替换现有RDB文件
}

特点：

按指定时间间隔执行，生成当前数据快照
单个紧凑的二进制文件，便于备份和恢复
恢复速度快，适合灾难恢复
可能会丢失最后一次快照后的数据

触发机制：

手动触发：通过SAVE或BGSAVE命令

自动触发：根据配置条件

bash 复制代码

save 900 1    # 900秒内至少1个键被修改
save 300 10   # 300秒内至少10个键被修改
save 60 10000 # 60秒内至少10000个键被修改

3.2 AOF（Append Only File）

AOF通过记录写操作命令实现持久化：

c 复制代码

// AOF写入函数 (src/aof.c)
void feedAppendOnlyFile(struct redisCommand *cmd, int dictid, robj **argv, int argc) {
    // 将命令转换为协议格式
    // 写入AOF缓冲区
}

特点：

记录所有写命令，可以重放恢复数据
文件体积较大，但可通过重写压缩
更好的数据安全性，支持不同级别的同步策略
恢复速度相对较慢

刷盘策略：

always：每次写命令都同步到磁盘，最安全但性能最低

c 复制代码

// 每次写入都调用fsync
if (server.aof_fsync == AOF_FSYNC_ALWAYS)
    aof_fsync(server.aof_fd);

everysec：每秒执行一次同步，性能和安全的平衡（默认）

c 复制代码

// 后台线程每秒执行一次fsync
if (server.aof_fsync == AOF_FSYNC_EVERYSEC && 
    server.aof_current_size != server.aof_last_fsync_size)
    aof_background_fsync(server.aof_fd);

no：由操作系统决定何时同步，性能最高但安全性最低

c 复制代码

// 不显式调用fsync，由操作系统决定
if (server.aof_fsync == AOF_FSYNC_NO)
    /* Let the OS handle it */;

3.3 AOF重写机制

为了解决AOF文件体积不断增大的问题，Redis提供了AOF重写机制：

c 复制代码

// AOF重写函数 (src/aof.c)
int rewriteAppendOnlyFileBackground(void) {
    // 创建子进程
    // 子进程生成新的AOF文件
    // 父进程继续处理命令，并记录重写期间的新命令
    // 重写完成后，父进程将新命令追加到新AOF文件
    // 原子性地替换旧AOF文件
}

特点：

不依赖原有AOF文件，直接从内存生成
使用子进程执行，不阻塞主进程
合并重复命令，如多次INCR合并为一个SET

3.4 Redis 4.0+的混合持久化

Redis 4.0引入了混合持久化机制，结合RDB和AOF的优点：

c 复制代码

// 混合AOF格式开关 (redis.conf)
aof-use-rdb-preamble yes

工作原理：

AOF重写时，先以RDB格式写入文件前半部分（快照）
再以AOF格式追加重写期间的增量命令
兼具RDB恢复速度快和AOF数据安全性高的优点

3.5 持久化方案选择思路

根据业务需求选择合适的持久化方案：

数据安全性要求高：使用AOF，fsync策略选always或everysec
恢复速度要求高：使用RDB或混合持久化
内存资源有限：注意AOF重写和RDB生成对内存的额外占用
最佳实践：Redis 4.0+建议开启混合持久化，同时使用RDB和AOF

总结

从Redis的内存一致性到持久化策略，我们沿着这条思维链条，了解了Redis如何同时保证高性能和数据安全：

内存一致性：通过单线程模型和原子命令实现
数据结构：精心设计的底层数据结构支持高效操作
持久化策略：多种方案满足不同场景需求

理解这些核心概念及其底层实现，有助于我们更好地使用和调优Redis，充分发挥其性能优势。