本文是博主根据 AI 获取的 全面掌握 Redis 所要掌握的知识汇总，博主会根据里面的内容进行逐步学习并记录，部分内容会以链接的形式添加在其中。
要完全掌握 Redis，需要从基础概念、核心特性、高级功能、底层原理、实践应用、运维监控等多个维度系统学习。
文章目录
一、基础核心概念
- 定义：开源的 高性能键值对（Key-Value）数据库 ，基于内存存储，支持持久化，兼具NoSQL和缓存的特性。
- 特点：高性能（单线程模型+IO多路复用）、支持多种数据结构、原子操作、可扩展（主从、集群）、跨平台。
- 应用场景：缓存、计数器、分布式锁、消息队列、排行榜、地理位置服务等。
- 数据模型与核心单位：
- 键（Key）：字符串类型，唯一标识一个值（Value），需注意命名规范（如
user:100:name）。 - 值（Value）：支持多种数据结构（String、Hash、List、Set、Sorted Set等），是Redis的核心灵活点。
- 键（Key）：字符串类型，唯一标识一个值（Value），需注意命名规范（如
二、核心数据结构及操作
Redis的核心竞争力在于丰富的数据结构，需掌握每种结构的定义、常用命令、底层实现、适用场景：
1、String（字符串）
- 定义：最基础的数据结构，可存储字符串、整数、浮点数（最大512MB）。
- 核心命令：
SET/GET/DEL、INCR/DECR（自增/自减，原子操作）、APPEND（追加）、STRLEN（长度）、SETNX（不存在则设置，分布式锁基础）、EXPIRE（设置过期时间）。 - 底层实现：简单动态字符串（SDS），兼容C字符串但优化了内存管理和操作效率。
- 场景：缓存简单值（如用户信息JSON）、计数器（文章阅读量）、分布式锁（
SETNX + EXPIRE）。
2、Hash（哈希）
- 定义：键值对的集合（类似Java的HashMap），适合存储对象（如用户信息：
user:100 {name: "xxx", age: 20}）。 - 核心命令：
HSET/HGET/HGETALL（设置/获取字段）、HDEL（删除字段）、HEXISTS（判断字段存在）、HINCRBY（字段自增）。 - 底层实现：
- 小数据量：压缩列表（ziplist，节省内存）；
- 大数据量：哈希表（hashtable，支持高效查找）。
- 场景：存储对象（避免序列化整个对象）、用户属性管理。
3、List（列表）
- 定义：有序的字符串列表（允许重复），支持两端插入/删除，类似“双向链表”。
- 核心命令：
LPUSH/RPUSH（左/右插入）、LPOP/RPOP（左/右弹出）、LRANGE（获取范围元素）、LLEN（长度）、LREM（删除指定元素）。 - 底层实现：
- 小数据量：压缩列表（ziplist）；
- 大数据量：快速列表（quicklist，双向链表+压缩列表的组合，平衡性能与内存）。
- 场景：消息队列（简单FIFO）、最新消息列表（如朋友圈）、栈/队列实现。
4、Set（集合）
- 定义：无序的字符串集合（不允许重复），支持交集、并集、差集等集合操作。
- 核心命令：
SADD/SREM（添加/删除元素）、SMEMBERS（获取所有元素）、SISMEMBER（判断元素存在）、SINTER（交集）、SUNION（并集）、SDIFF（差集）。 - 底层实现：
- 整数元素（且范围小）：整数集合（intset）；
- 其他情况：哈希表（hashtable）。
- 场景：去重（如用户标签去重）、共同好友（交集）、好友推荐（差集）。
5、Sorted Set（有序集合，ZSet）
- 定义：类似Set，但每个元素关联一个“分数（score）”，按分数排序（可重复分数，不可重复元素）。
- 核心命令：
ZADD（添加元素+分数）、ZRANGE（按分数升序取范围）、ZREVRANGE（降序）、ZSCORE（获取分数）、ZINCRBY（分数自增）、ZRank（元素排名）。 - 底层实现：跳跃表（skiplist）+ 哈希表（哈希表存元素→分数映射，跳跃表按分数排序，支持快速查找/范围查询）。
- 场景：排行榜（如游戏积分排名）、带权重的消息队列、范围统计（如“分数>90的用户”）。
三、高级数据结构与特性
1、Bitmap（位图）
- 定义：以“位（bit）”为单位存储数据（每个bit对应0/1），本质是String的扩展。
- 核心命令：
SETBIT（设置位值）、GETBIT（获取位值）、BITCOUNT（统计1的个数）、BITOP（位运算：与/或/非/异或）。 - 场景：用户签到（1亿用户仅需12.5MB）、状态标记（如“是否在线”）。
2、HyperLogLog
- 定义：用于基数统计（统计集合中不重复元素的个数），占用内存极小（固定≈12KB），但有0.81%的误差。
- 核心命令：
PFADD（添加元素）、PFCOUNT（统计基数）、PFMERGE（合并多个HyperLogLog）。 - 场景：UV统计（页面独立访客）、搜索关键词去重计数。
3、Geospatial（地理位置）
- 定义：存储经纬度信息，支持距离计算、范围查询（基于ZSet实现，分数为经纬度编码的Geohash值）。
- 核心命令：
GEOADD（添加地理位置）、GEODIST（计算两点距离）、GEORADIUS（根据坐标范围查询）、GEORADIUSBYMEMBER（根据元素范围查询）。 - 场景：附近的人、外卖配送范围筛选。
4、Stream
- 定义：Redis 5.0新增的消息队列结构，支持持久化、消费确认（ACK）、分组消费，类似Kafka的简化版。
- 核心命令：
XADD（生产消息）、XREAD（消费消息）、XGROUP（创建消费组）、XACK（确认消息）、XPENDING（查看未确认消息）。 - 场景：可靠消息队列（解决List作为队列的“消息丢失”问题）。
四、核心特性与机制
1、RDB（Redis Database）
- 原理：在指定时间间隔内，将内存中的数据快照（二进制文件）写入磁盘（默认
dump.rdb）。 - 触发方式：手动（
SAVE/BGSAVE）、自动（配置save <seconds> <changes>）。 - 优缺点：快（恢复快）、体积小，但可能丢失最后一次快照后的数。
2、AOF（Append Only File）
- 原理：记录所有写命令（如
SET key value）到日志文件（默认appendonly.aof），恢复时重新执行命令。 - 同步策略：
appendfsync always（每次写都同步，慢但安全）、everysec（每秒同步，平衡）、no（由OS决定，最快但不安全）。 - 重写（Rewrite）：压缩AOF文件（去除冗余命令，如
SET a 1; SET a 2→仅保留SET a 2），通过BGREWRITEAOF触发。 - 优缺点：数据安全性高（最多丢1秒数据），但文件大、恢复慢。
3、混合持久化（Redis 4.0+）
- RDB + AOF结合（AOF文件头部是RDB快照，尾部是增量命令），兼顾速度与安全性。
4、内存管理
- 内存限制：通过
maxmemory配置Redis可使用的最大内存。 - 内存淘汰策略（当内存超限时，删除部分Key释放空间）：
- 过期Key优先：
volatile-lru（最近最少使用的过期Key）、volatile-ttl（剩余时间最短的过期Key）等； - 全量Key：
allkeys-lru（最近最少使用的所有Key）、allkeys-random（随机删除所有Key）等； - 不淘汰：
noeviction（默认，拒绝写操作并返回错误）。
- 过期Key优先：
- 内存碎片：因频繁修改数据（如String扩容）导致的内存浪费，可通过
memory purge（主动整理）或重启解决。 - 过期键删除策略：
- 惰性删除：访问Key时才检查是否过期（节省CPU，可能浪费内存）；
- 定期删除：每隔一段时间随机检查部分过期Key（平衡CPU和内存）；
- 内存淘汰：配合上述淘汰策略，最终保证内存不超限制。
5、单线程模型
- 原理：Redis的核心操作（读写）由单个主线程处理（避免多线程上下文切换开销），但IO操作（如持久化、网络IO）由后台线程处理。
- 性能保障：
- 内存操作速度快（纳秒级）；
- 基于IO多路复用（select/poll/epoll/kqueue）处理多客户端连接，主线程无需阻塞等待IO。
- 注意：避免执行耗时命令（如
KEYS *、HGETALL大Hash），否则会阻塞主线程。
五、高可用与分布式
1、主从复制（Replication）
- 作用：实现数据备份（从节点复制主节点数据）和读写分离（主节点写，从节点读）。
- 原理：
- 从节点通过
SLAVEOF <master-ip> <port>连接主节点，触发全量复制（主节点生成RDB，从节点加载）+ 增量复制（主节点将写命令同步到从节点）。
- 从节点通过
- 复制流程：握手→全量同步→增量同步（基于偏移量）。
- 注意：主从延迟（网络/负载导致）、从节点只读（
slave-read-only yes）。
2、哨兵（Sentinel）
- 作用：监控主从节点状态，当主节点故障时自动故障转移（从节点升级为主节点），保证高可用。
- 核心功能：监控、通知、自动故障转移。
- 工作原理：
- 多个哨兵节点组成集群（避免单点故障），通过PING检测节点存活；
- 当多数哨兵认为主节点“客观下线”，触发故障转移：选举新主节点→通知其他从节点切换主节点→原主节点恢复后作为从节点。
- 配置：需定义哨兵监控的主节点（如
sentinel monitor mymaster 127.0.0.1 6379 2，2表示至少2个哨兵同意才故障转移）。
3、Redis Cluster（集群）
- 作用：解决单机内存/性能瓶颈，实现数据分片（水平扩展）和高可用（每个分片有主从复制）。
- 架构：
- 由多个节点（至少6个，3主3从）组成，每个主节点负责一部分槽位（slot），共16384个槽位（0-16383）。
- 数据分片：Key通过
CRC16(key) % 16384计算槽位，分配到对应主节点。
- 核心特性：
- 去中心化：节点间通过Gossip协议通信，无中心节点；
- 故障检测：节点定期交换状态，判断主节点是否下线，若下线则从节点升级为主节点；
- 扩容/缩容：通过
redis-trib.rb或redis-cli --cluster调整槽位分配。
六、高级操作与特性
1、事务（Transaction）
- 原理：通过
MULTI（开启事务）、EXEC（执行事务）、DISCARD（取消事务）、WATCH（监控Key，若被修改则事务取消）实现批量命令的原子执行（要么全执行，要么全不执行）。 - 注意：Redis事务不支持回滚（错误命令仅会被忽略，不会影响其他命令），需通过
WATCH规避并发问题。
2、Lua脚本
- 作用：将多个命令封装为脚本，由Redis原子执行（避免中间被其他命令打断），适合复杂业务逻辑（如分布式锁的释放）。
- 核心命令：
EVAL（执行脚本）、EVALSHA（通过脚本哈希值执行，避免重复传输）。 - 优势：减少网络往返、保证原子性、支持复杂逻辑（如条件判断）。
3、发布订阅（Pub/Sub）
- 原理：基于“频道（Channel）”的消息通信模式，发布者（Publisher）发送消息到频道，订阅者（Subscriber）接收频道消息（无持久化，消息实时性）。
- 核心命令：
PUBLISH（发布消息）、SUBSCRIBE（订阅频道）、UNSUBSCRIBE（取消订阅）。 - 场景：简单消息通知（如实时聊天、系统通知），但不适合可靠消息队列（无ACK、消息不持久）。
4、管道（Pipeline）
- 作用：将多个命令打包发送到Redis，减少网络往返次数（尤其高延迟场景），提升批量操作性能。
- 注意：管道命令非原子执行（中间可插入其他命令），但比单条发送效率高10倍以上。
七、客户端与连接管理
1、连接原理
- 客户端与Redis通过TCP连接通信（默认端口6379），每个连接对应一个文件描述符（FD）。
- 连接限制：通过
maxclients配置最大连接数（默认10000），超出则拒绝新连接。
2、连接池
- 作用：复用TCP连接，避免频繁创建/关闭连接的开销（尤其高并发场景）。
- 核心参数：最大连接数、最小空闲连接数、超时时间（如Java的JedisPool）。
3、客户端序列化
- 非字符串类型的Value（如对象）需序列化后存储（如JSON、Protobuf、Java的Serializable），需注意序列化效率和兼容性。
八、运维与监控
1、配置文件（redis.conf）
- 基础：
port（端口）、daemonize（是否后台运行）、pidfile（进程ID文件）； - 内存：
maxmemory（最大内存）、maxmemory-policy（淘汰策略）； - 持久化：
save（RDB配置）、appendonly（是否开启AOF）、appendfsync（AOF同步策略）； - 安全：
requirepass（密码认证）、rename-command（重命名危险命令，如KEYS→""禁用）。
2、常用工具
redis-cli：命令行客户端（支持交互、批量执行脚本）；redis-benchmark：性能测试工具（测试读写QPS、不同数据大小的性能）；redis-check-rdb/redis-check-aof：检查RDB/AOF文件完整性；redis-sentinel：哨兵进程启动工具。
3、监控指标
- 性能：
info stats中的instantaneous_ops_per_sec（每秒操作数）、keyspace_hits/misses（缓存命中率）； - 内存：
info memory中的used_memory（已用内存）、mem_fragmentation_ratio（内存碎片率）； - 连接：
info clients中的connected_clients（连接数）、blocked_clients（阻塞客户端数）； - 持久化：
info persistence中的rdb_last_save_time（最近RDB保存时间）、aof_last_rewrite_time（最近AOF重写时间）。
4、安全措施
- 密码认证：
requirepass <password>，客户端需通过AUTH <password>登录； - 限制IP：通过防火墙（如iptables）限制仅信任IP可连接；
- 禁用危险命令：
rename-command KEYS ""（禁用KEYS）、rename-command FLUSHALL ""（禁用清空数据库）； - 数据加密：传输加密（SSL/TLS，需配置
tls-port）、存储加密（Redis本身不支持，需业务层实现）。
九、缓存问题与解决方案
1、缓存穿透
- 问题：查询不存在的Key（如
id=-1），导致请求穿透缓存直接打数据库，压垮DB。 - 解决方案：缓存空值（
SET key "" EX 60）、布隆过滤器（提前过滤不存在的Key）。
2、缓存击穿
- 问题：热点Key过期瞬间，大量请求同时打数据库（如秒杀商品的库存Key）。
- 解决方案：互斥锁（查询时加锁，只让一个请求更新缓存）、热点Key永不过期（业务层手动更新）、定时预热（过期前主动更新）。
3、缓存雪崩
- 问题：大量Key同时过期，或缓存集群宕机，导致所有请求打数据库。
- 解决方案：过期时间加随机值（避免同时过期）、主从+哨兵（保证缓存可用性）、服务熔断/限流（保护数据库）、多级缓存（本地缓存+分布式缓存）。
4、数据一致性
- 问题：缓存与数据库数据不一致（如更新DB后未更新缓存）。
- 解决方案：
- 读操作：先查缓存，缓存未命中再查DB并更新缓存；
- 写操作：更新DB后删除缓存（Cache Aside Pattern），或先更新缓存再更新DB（需谨慎处理并发）；
- 最终一致性：接受短暂不一致，通过定时任务同步。
十、底层原理（深入理解必备）
1、数据结构底层实现
- String：简单动态字符串（SDS，记录长度、容量，避免C字符串的缺陷）；
- List：快速列表（quicklist，双向链表包裹压缩列表，平衡性能与内存）；
- Hash：哈希表（hashtable）+ 压缩列表（ziplist，小数据时）；
- Set：整数集合（intset，元素为整数且范围小时）+ 哈希表；
- ZSet：跳跃表（skiplist，支持范围查询）+ 哈希表（映射元素与分数）。
2、IO多路复用
- 原理：Redis通过
epoll（Linux）/kqueue（BSD）等机制，让单个线程同时监听多个客户端Socket的IO事件（读/写/连接），避免阻塞等待，提升并发处理能力。
3、事件驱动模型
- Redis的事件分为文件事件（Socket IO事件）和时间事件（定时任务，如过期Key删除、持久化触发），由事件循环（event loop）统一处理，保证高效调度。
掌握Redis需要从“用起来”到“理解透”：先熟练使用基础数据结构和命令，再深入学习持久化、主从、集群等核心特性，最后通过底层原理和实践问题（如缓存雪崩）的解决方案，形成完整的知识体系。同时，结合实际业务场景（如分布式锁、消息队列）的最佳实践，才能真正做到“完全掌握”。
扫一扫
4万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
