1. Redis核心架构与设计哲学

Redis作为开源的内存数据结构存储系统，其设计哲学可概括为"简单即美"。采用单线程事件循环模型（6.0版本后支持多线程IO），通过非阻塞IO复用技术实现高并发处理能力。核心组件包括：

• 事件驱动框架（ae.h）：基于epoll/kqueue/select的多路复用实现
• 内存分配器（zmalloc）：对系统malloc的封装，支持内存统计
• 对象系统（redisObject）：统一的值对象表示，包含类型/编码/指针等元数据

关键设计取舍：单线程模型避免了锁竞争，但CPU成为瓶颈。实际应用中网络IO和内存访问才是主要延迟来源，因此单线程反而简化了设计。

典型工作流程：

1. 客户端发起连接请求
2. 事件循环接收命令并解析
3. 命令执行器处理请求
4. 返回响应到输出缓冲区
5. 可写事件触发时将数据返回客户端

2. 数据结构与底层实现

2.1 字符串（SDS）

简单动态字符串(Simple Dynamic String)是Redis的基础结构：

struct sdshdr { int len; // 已用长度 int free; // 剩余空间 char buf[]; // 字节数组 };

优势：

• O(1)时间复杂度获取长度
• 自动扩容（小于1MB时加倍，大于时每次加1MB）
• 二进制安全（可存储任意数据）

2.2 哈希表（dict）

使用MurmurHash2算法和渐进式rehash策略：

typedef struct dict { dictType *type; // 类型特定函数 void *privdata; // 私有数据 dictht ht[2]; // 哈希表数组 long rehashidx; // rehash进度 } dict;

扩容触发条件：

• 服务器未执行BGSAVE时：负载因子≥1
• 执行BGSAVE时：负载因子≥5

2.3 跳跃表（zskiplist）

有序集合的底层实现之一，平均O(logN)复杂度：

typedef struct zskiplistNode { robj *obj; // 成员对象 double score; // 分值 struct zskiplistNode *backward; // 后退指针 struct zskiplistLevel { struct zskiplistNode *forward; // 前进指针 unsigned int span; // 跨度 } level[]; } zskiplistNode;

层级生成采用幂次定律（越高层概率越低），最高32层。

3. 持久化机制详解

3.1 RDB持久化

二进制快照存储，触发方式：

1. 手动执行SAVE/BGSAVE
2. 配置文件中设置save规则（如save 900 1）
3. 主从复制时全量同步
4. shutdown时若无AOF则自动执行

优缺点对比：

3.2 AOF持久化

记录写命令的日志文件，重写机制：

1. 创建子进程遍历数据库生成新AOF
2. 父进程继续处理命令并缓冲新变更
3. 子进程完成后将缓冲命令追加到新文件
4. 原子替换旧文件

fsync策略：

• always：每个命令都同步（安全但慢）
• everysec：每秒同步（默认推荐）
• no：由操作系统决定（最快但风险最大）

4. 高可用与集群

4.1 主从复制

全量同步流程：

1. 从节点发送PSYNC ? -1
2. 主节点执行BGSAVE生成RDB
3. 发送RDB文件到从节点
4. 从节点清空数据加载RDB
5. 主节点发送缓冲区的写命令

部分重同步依赖：

• 主节点复制积压缓冲区（默认1MB）
• 从节点保存的复制偏移量
• 主节点运行ID

4.2 Redis Cluster

数据分片采用哈希槽（16384个槽）：

• 键通过CRC16算法计算后取模16384
• 每个节点负责部分槽位
• 支持ASK/MOVED重定向

故障检测：

1. 节点间通过Gossip协议通信
2. 主观下线（PFAIL）和客观下线（FAIL）
3. 从节点选举采用Raft-like算法

5. 实战优化技巧

5.1 内存优化

• 使用ziplist编码：小哈希/列表/有序集合
• 设置maxmemory-policy（推荐volatile-lru）
• 监控内存碎片率（info memory）
• 大key拆分（通过SCAN+DEL分批删除）

5.2 性能调优

关键配置项：

# 网络相关 tcp-backlog 511 timeout 0 # 内存管理 maxmemory 4gb maxmemory-policy volatile-lru # 持久化 appendfsync everysec auto-aof-rewrite-percentage 100

慢查询分析：

1. 设置阈值（slowlog-log-slower-than 10000）
2. 查看日志（SLOWLOG GET）
3. 优化热点命令（如批量操作）

6. 典型应用场景

6.1 缓存设计

多级缓存架构：

1. 本地缓存（Caffeine）→ Redis集群 → DB
2. 缓存击穿解决方案：
   • 互斥锁（SETNX）
   • 逻辑过期时间
3. 热点数据发现：
   • 监控命令统计
   • 客户端采样上报

6.2 分布式锁

Redlock算法要点：

1. 获取当前时间（start）
2. 顺序向N个节点获取锁（SET k v NX PX）
3. 计算获取锁耗时（<锁有效期）
4. 实际持有时间 = 有效期 - 获取耗时

注意事项：时钟漂移可能导致锁失效，生产环境建议使用Zookeeper/etcd等CP系统替代。

7. 运维监控体系

7.1 指标采集

关键监控项：

• 内存使用率（used_memory_rss）
• 命中率（keyspace_hits/keyspace_misses）
• 延迟（latency monitor）
• 连接数（connected_clients）

推荐工具：

• Prometheus + Grafana
• Redis Exporter
• 自定义Lua脚本采集

7.2 故障处理

常见问题排查：

1. 内存溢出：
   • 分析RDB文件（rdb-tools）
   • 查找大key（MEMORY USAGE）
2. 连接泄漏：
   • 查看客户端列表（CLIENT LIST）
   • 设置timeout参数
3. AOF损坏：
   • 使用redis-check-aof修复
   • 回滚到上一个可用版本

我在生产环境中发现，合理设置maxmemory和淘汰策略比想象中更重要。曾遇到因未设置maxmemory导致OOM被系统kill的案例，建议即使作为缓存使用也明确设置内存上限。对于持久化配置，everysec通常是最佳平衡点，除非对数据一致性要求极高。