一、Redis概述
Redis是一个开源的基于Key-Value结构的NoSQL内存数据库。通常作为数据库与应用程序之间的缓存层，主要目的是减少数据库I/O压力。
二、Redis工作流程
- 用户请求数据时，首先查询Redis缓存
- 若缓存命中，直接返回数据
- 若未命中，则查询数据库
- 将数据库查询结果返回给用户，同时写入Redis缓存
三、Redis核心优势
3.1 性能卓越
- 极致读写速度：纯内存操作，响应时间常低于1毫秒
- 持久化保障：支持RDB和AOF两种持久化方式
- 高可用性：主从模式数据备份，确保服务可靠性
3.2 丰富数据结构
| 常用数据结构 | 特点与应用 |
|---|---|
| String | 基础数据类型，存储文本、数字等 |
| List | 双向链表，有序且可重复 |
| Hash | 键值对集合，适合存储对象 |
| Set | 无序集合，元素唯一，支持集合运算 |
| ZSet | 有序集合，带分值排序 |
3.3 特殊数据类型
- Geospatial：地理位置计算，如"附近的人"
- Hyperloglog：基数统计，如UV统计
- Bitmap：位图操作，如用户签到、在线状态
四、核心数据结构深度解析
4.1 String（字符串）
特点：
- 最基础的数据类型，二进制安全
- 可存储文本、数字、序列化对象
常用命令：
SET user:1 "张三" # 设置键值
GET user:1 # 获取值
INCR article:100:views # 自增计数器
APPEND key "追加内容" # 字符串追加
应用场景：
- 缓存会话、Token、验证码
- 实现计数器（点赞数、浏览量）
- 分布式锁（SETNX命令）
4.2 Hash（哈希）
特点：
- field-value映射表，适合存储对象
- 支持部分字段更新
常用命令：
HSET user:1 name "李四" age 25 # 设置多个字段
HGET user:1 name # 获取单个字段
HGETALL user:1 # 获取所有字段
应用场景：
- 用户信息、商品详情等结构化数据
- 需要频繁更新部分属性的场景
4.3 List（列表）
特点：
- 有序双向链表，支持两端操作
- 元素可重复，新增删除效率高
常用命令：
LPUSH tasks "任务A" # 左端插入
RPUSH tasks "任务B" # 右端插入
LRANGE tasks 0 -1 # 获取全部元素
应用场景：
- 消息队列（FIFO/LIFO）
- 最新动态、时间轴
- 待办事项列表
4.4 Set（集合）
特点：
- 无序集合，元素唯一
- 支持交集、并集、差集运算
常用命令：
SADD tags "技术" "编程" # 添加元素
SINTER java_users python_users # 求交集
应用场景：
- 标签系统、兴趣推荐
- 共同好友、关注关系
- 数据去重（UV统计）
4.5 ZSet（有序集合）
特点：
- 带分值的排序集合
- 元素唯一，按分值自动排序
常用命令：
ZADD leaderboard 1000 "玩家A" # 添加带分值元素
ZREVRANGE leaderboard 0 9 # 获取前十名
应用场景：
- 排行榜、热点排序
- 优先级队列
- 延时任务
五、Redis部署架构
5.1 部署模式对比
| 模式 | 特点 | 适用场景 |
|---|---|---|
| 单机模式 | 部署简单，存在单点故障风险 | 开发测试环境 |
| 主从模式 | 读写分离，数据同步 | 中小型生产环境 |
| 哨兵模式 | 自动故障转移，监控告警 | 对高可用有要求的场景 |
| Cluster模式 | 分布式架构，数据分片 | 大数据量高并发场景 |
5.2 哨兵模式深度解析
核心功能：
- 集群监控：每秒发送ping命令检测节点状态
- 故障转移：主节点故障时自动提升从节点
- 配置中心：客户端自动发现新的主节点
5.3 哈希槽机制
设计原理：
- 引入16384个哈希槽，解决数据倾斜问题
- 数据通过CRC16算法计算槽位，均匀分布
工作流程：
slot = CRC16(key) % 16384 # 计算数据存储位置
六、缓存问题与解决方案
6.1 缓存穿透
问题描述：大量请求查询不存在的key，直接打到数据库
解决方案：
- 缓存空对象：对不存在的key也缓存空值
- 布隆过滤器：预判key是否存在，拦截无效请求
6.2 缓存击穿
问题描述：热点key突然过期，大量并发请求数据库
解决方案：
- 设置热点key永不过期
- 使用分布式锁，保证单线程重建缓存
6.3 缓存雪崩
问题描述：大量key同时过期，数据库压力剧增
解决方案：
- 随机化过期时间，避免同时失效
- Redis集群部署，分散压力
- 数据库连接池限流保护
七、数据一致性方案
7.1 数据同步挑战
Redis与MySQL双写时的数据一致性问题
7.2 解决方案
最终一致性方案：
- 基于MQ：通过消息队列保证操作的顺序性
- Canal组件：监控MySQL binlog，异步同步到Redis
八、技术对比：Redis vs Memcache
| 特性 | Redis | Memcache |
|---|---|---|
| 持久化 | 支持RDB/AOF | 不支持 |
| 数据类型 | 丰富多样 | 简单key-value |
| 数据备份 | 主从复制 | 无内置机制 |
九、持久化机制
9.1 RDB（Redis Database）
- 机制：定时生成数据快照（dump.rdb）
- 优点：文件紧凑，恢复速度快
- 缺点：可能丢失最后一次快照后的数据
9.2 AOF（Append Only File）
- 机制：记录每个写操作命令
- 优点：数据安全性高
- 缺点：文件较大，恢复较慢
十、主从同步机制
10.1 全量同步
- Master执行bgsave生成RDB文件
- 传输RDB文件至Slave
- Slave加载RDB文件
- 同步缓冲区增量数据
触发条件：
- 首次连接
- 复制缓冲区数据丢失
10.2 增量同步
- 通过服务器ID和偏移量标识
- 只同步缓冲区的增量写命令
十一、Redis线程模型
11.1 服务端线程安全
- Redis 6.0前：完全单线程
- Redis 6.0+：网络IO多线程，命令执行仍单线程
单线程优势：
- 避免上下文切换开销
- 无锁竞争问题
- IO多路复用提升效率
十二、内存管理策略
12.1 过期键删除策略
- 惰性删除：访问时检查并删除过期键
- 定期删除：周期性扫描并删除过期键
12.2 内存回收策略
| 策略类型 | 说明 |
|---|---|
| volatile-lru | 从设置了过期时间的键中使用LRU淘汰 |
| allkeys-lru | 从所有键中使用LRU淘汰 |
| volatile-lfu | 使用LFU算法淘汰过期键 |
| allkeys-lfu | 使用LFU算法淘汰所有键 |
十三、性能优化指南
13.1 性能问题排查路径
-
基准性能测试：获取无干扰状态下的性能基准
-
慢查询分析：启用慢查询日志定位性能瓶颈
-
键过期优化：避免大量键同时过期
-
BigKey检测：使用scan命令识别大键
-
AOF优化：
- 调整刷盘策略
- 使用SSD存储
- 关闭重写期间的fsync
-
系统层面：
- 监控swap使用情况
- 增加内存或使用集群分摊压力
总结
Redis作为高性能的内存数据库，在缓存、会话存储、消息队列等场景中发挥着重要作用。通过合理的架构设计、数据结构和配置优化，可以充分发挥其性能优势，为应用系统提供强力支撑。
核心要点：根据业务场景选择合适的数据结构、部署模式和配置策略，是Redis应用成功的关键。
