目录1. Redis 概述与核心特性1.1 什么是 Redis1.2 8 大重要特性1.3 为什么 Redis 这么快1.4 典型应用场景1.5 Redis 不适合做什么2. 版本演进关键点3. 全局命令与键管理4. 数据结构与内部编码4.1 对外数据结构 vs 内部编码4.2 查看内部编码OBJECT ENCODING key4.3 为什么要有多种内部编码5. 单线程模型5.1 什么是单线程5.2 为什么单线程能支撑高并发5.3 单线程的致命弱点5.4 引入多线程 I/O 后还是单线程吗1. Redis 概述与核心特性1.1 什么是 Redis基于键值对key-value的 NoSQL 数据库值支持多种数据结构string、hash、list、set、zset、Bitmaps、HyperLogLog、GEO 等数据全在内存中支持持久化RDB AOF、主从复制、哨兵高可用、集群分布式1.2 8 大重要特性特性说明速度快内存存储 C语言 单线程 精良源码基于键值对的数据结构服务器值可以是多种数据结构开发灵活功能丰富过期、发布订阅、Lua脚本、事务、Pipeline简单稳定源码少早期2万行单线程模型简单极少因自身BUG宕机客户端语言多几乎覆盖所有主流语言Java、Python、Go、Node…持久化RDB 快照 AOF 日志保证数据不丢失主从复制支持多个副本分布式基础高可用与分布式Sentinel 故障自动转移Cluster 真正分布式Redis 的发布订阅Pub/Sub是一种基于频道channel的消息广播机制发布者通过 PUBLISH 向指定频道发送消息所有已通过 SUBSCRIBE 订阅该频道的客户端都会实时收到消息也支持 PSUBSCRIBE 按模式订阅Redis 服务器充当消息中转站实现发布者与订阅者之间的解耦和一对多通信。其特点是轻量、实时、低延迟但消息不持久化、不保证可靠投递订阅者离线或断开期间的消息会丢失也没有 ACK 和消费组机制因此更适合实时通知、聊天、广播等允许丢失的场景若需要可靠消息通常应使用 Redis Stream 或专业消息队列1.3 为什么 Redis 这么快纯内存访问内存延迟约比磁盘快几个数量级非阻塞 I/O基于 epoll 的 I/O 多路复用将网络事件转化为事件驱动单线程模型避免线程切换和竞态消耗简化数据结构和算法C 语言实现更“接近”操作系统1.4 典型应用场景缓存键过期 淘汰策略排行榜有序集合 zset计数器视频播放数、电商浏览数社交网络赞/踩、粉丝、共同好友消息队列发布订阅 阻塞队列1.5 Redis 不适合做什么大规模冷数据内存成本极高不适合存储海量不常访问的数据复杂关系查询非关系型不适合 SQL 多表联查数据量极大且经济敏感如每天数亿用户行为用 Redis 存储是“无底洞”2. 版本演进关键点Redis 版本号规则第二位偶数 稳定版如 2.8、3.0、4.0、5.0、6.0、7.0奇数 开发版版本核心新特性2.6服务端 Lua 脚本毫秒级过期从节点只读2.8部分主从复制PSYNCSentinel 第二版生产可用3.0Redis Cluster官方分布式实现LRU 优化3.2GEO地理位置功能quicklist 编码4.0模块系统LFU淘汰算法异步删除unlinkRDB-AOF 混合持久化5.0Stream数据类型消息队列增强redis-cli 集群管理器从 Ruby 移植到 C6.0多线程 I/O但命令执行仍是单线程ACL 权限控制RESP3 协议客户端缓存7.0AOF 多文件存储RDB 版本升级至 10不兼容旧版listpack 替换 ziplistprotected-mode 默认开启6.0 的多线程仅用于网络读写和协议解析命令执行仍然单线程不需要担心并发安全问题3. 全局命令与键管理所有数据结构共用的命令注意其时间复杂度和使用注意事项命令作用时间复杂度注意KEYS pattern返回匹配模式的所有 keyO(N)生产环境禁用会阻塞 RedisEXISTS key判断 key 是否存在O(1)可同时检查多个返回存在的个数DEL key删除指定 keyO(1)删除大 key 时建议用UNLINK异步EXPIRE key seconds设置秒级过期时间O(1)返回 1 成功0 失败TTL key查看剩余过期时间秒O(1)-1 表示永不过期-2 表示 key 不存在TYPE key返回当前键对应 value 的对外数据类型O(1)返回值string, list, hash, set, zset, stream 等KEYS * 绝对不要在生产使用它会扫描全库阻塞所有命令。替代方案SCAN 游标迭代EXPIRE 和 TTL 还有毫秒版本 PEXPIRE / PTTL4. 数据结构与内部编码Redis 对外暴露 5 种数据类型但底层有多种内部编码根据场景动态切换4.1 对外数据结构 vs 内部编码数据结构可能的内部编码stringraw,int,embstrhashhashtable,ziplist7.0 后改为 listpacklistlinkedlist,ziplist3.2 后统一为quicklistsethashtable,intsetzsetskiplist,ziplist7.0 后改为 listpack4.2 查看内部编码OBJECT ENCODING key4.3 为什么要有多种内部编码解耦升级优化内部编码不影响外部命令如 3.2 引入 quicklist 用户无感知场景适配ziplist 节省内存但元素多时性能下降达到阈值会转为 hashtable 或 skiplist7.0 重要变化ziplist 被 listpack 替代且 RDB 版本升级至 10旧版 RDB 无法直接读取5. 单线程模型5.1 什么是单线程Redis 服务端命令执行是单线程的所有客户端请求排队依次处理微观上命令按到达顺序线性执行不存在两条命令同时执行5.2 为什么单线程能支撑高并发内存操作极快瓶颈不在 CPU 而在网络 I/O非阻塞 I/O 多路复用epoll将连接、读写、关闭注册为事件不浪费 CPU 等待无上下文切换和无锁竞争性能更稳定5.3 单线程的致命弱点单个命令执行时间过长会阻塞后续所有命令。因此严禁大 key 操作如 KEYS *、大集合交集等5.4 引入多线程 I/O 后还是单线程吗命令执行仍为单线程。多线程仅用于网络数据读写和协议解析所以并发安全性依然由单线程保证Redis 6.0 引入的多线程机制是一种混合式设计其核心是将网络 I/O 的读写操作交由多个 I/O 线程并行处理而命令的解析与执行依然由主线程单线程串行完成。具体来说主线程负责接收连接并将可读的 socket 通过轮询分发给 I/O 线程进行读取和解析随后主线程串行执行命令执行完毕后再由 I/O 线程将结果写回客户端。这一设计旨在解决高并发下网络 I/O 成为瓶颈的问题通过利用多核 CPU 提升网络数据的读写效率。由于命令执行阶段仍保持单线程所以它避免了多线程带来的数据竞争和并发安全问题在提升吞吐量的同时保留了单线程模型简单、原子性的优点。该特性默认关闭需通过 io-threads 等参数手动启用
