redis知识汇总

是什么

开源高性能非关系型数据库

键值对结构，key是字符串，键支持5种类型：字符串，列表、集合、散列表、有序集合

优缺点

优点

1）读写性能高

2）支持持久化：aof，rdb

3）支持事务：所有命令操作都是原子性的

4）支持多个命令合并打包（打包顺序执行，之间不执行别的命令、别的命令进入等待队列）

5）数据结构丰富：字符串，散列表，列表，集合，有序集合

6）支持主从复制，主机自动将数据同步给从，可进行读写分离

缺点

1）受物理内存限制，不能作为海量数据高速读写，redis适合的场景主要局限在较小数据量的高性能操作和运算上

2）不具备自动容错和恢复功能，主从机宕机会导致前端部分请求失败，需等待集群重启

3）主机宕机前，部分数据未同步到从，引起数据不一致和数据丢失

4）在线扩容难，集群容量达到上限时，再次扩容难度大

为什么要使用redis？

高性能：将用户访问的数据，热点数据存在缓存中

高并发：将数据库部分数据备份到缓存中，直接操作缓存能够承受的请求远远大于数据库

与map的对比

多实例情况下，各实例共用一份缓存数据，缓存具有一致性。缺点是需要保证redis高可用，程序上架构较为复杂

为什么快？

redis完全基于内存

数据结构简单，操作也简单

采用单线程设计，避免上下文切换和竞争条件

新版本有引入多线程操作，但是仅是针对一些删除操作，对于一些大key的删除，通过多线程非阻塞地释放内存空间，也能减少对redis主线程阻塞的时间，提高执行效率

使用多路IO复用模型，非阻塞IO

使用底层模型不同，他们直接底层实现方式与客户端之间的通信应用协议不一样。redis直接自己构建VM机制。因为一般的系统调用函数，会浪费一定时间去移动和请求

本地缓存和redis的区别

本地缓存存储在应用本地，读写快、延迟低，但不适合大规模数据，也无法持久化

Redis是分布式缓存，通过多节点分布式集群，实现了扩展性、高可用和持久化，因为有网络开销，会比本地缓存慢一点，但比数据库快很多，适合高并发场景。

应用场景

计数器，对string进行自增自减运算，适合存储频繁读写的计数量，如用户的访问次数，热点文章的点赞转发数量等

缓存（内容可失效），热点数据放到内存、数据库缓存、会话缓存

消息队列

list是个双向链表，可以通过lpush和rpop写入和读取消息

延迟队列，排行榜，积分，使用zset实现

分布式锁，支持setnx实现分布式锁，官方推荐使用redLock分布式锁

数据类型

基础数据类型

字符串、整数、浮点数

对字符串或字符串部分进行操作，可以对数据进行自增减操作

列表(list）

从两端压入或弹出元素，对单个或多个进行操作，保留一定范围的元素，如粉丝列表、文章评论列表

集合（无序）

添加、获取、移除单个元素，检查一个元素是否存在，计算交集、并集、差集，在集合里随机获取元素，比如共同关注、粉丝、喜好等

散列表（hash)

添加、获取、移除单个键值对，获取所有键值对，检查某个键是否存在

有序集合(zset)

获取、添加、删除，根据分值范围或成员获取，计算一个键的排名、延迟队列

特殊数据类型

地理位置

位存储

数据结构

1）SDS动态字符串：

• len记录字符串长度
• 空间不够，自动扩展空间
• 空间预分配和惰性释放，降低分配内存次数
• 二进制安全，写入什么就是什么，不做任何过滤和限制
• 可以保存图片，音频等信息，C++不能保存

理解

核心对比：

• C字符串，存长度不存，C：数到`\0`才算完

；SDS： 直接存了`len`属性

• 获取长度，C：遍历一遍，O(N) ；SDS：直接读`len`，O(1)
• 修改时会不会溢出，C：没检查，容易溢出；SDS：先检查空间，不够自动扩容
• 频繁修改效率，C：每次都要重新申请内存 ；SDS：预分配+惰性释放，减少内存操作

优势

1.获取长度快

C字符串要像数数一样遍历，SDS直接看'户口本'（len字段）

2.不会缓冲区溢出

C字符串修改时可能写爆，SDS会先检查'够不够地方'，不够就自动扩

3. 减少内存操作

SDS有两个绝招：空间预分配（多留点备用）、惰性释放（先不急着还），这样字符串变长变短时不用老找操作系统要内存。预分配是扩的时候多给点，惰性释放是缩的时候先不还

Redis用SDS代替C字符串，本质上是用多存几个字段（len/free），换取O(1)取长度、防溢出、减少内存分配次数三大好处，是典型的空间换时间。

2）ZSet

底层使用压缩表或跳表实现。

小数据用压缩列表，大数据用跳表。他能够根据元素个数和大小自动切换。

3）压缩表

元素个数小于128，每个元素大小小于64字节

省内存，紧凑存储。

zset，hash在元素较少时，使用压缩存储

压缩表采用连续内存空间，元素之间紧挨着没有空隙

4）跳表

查询快，支持范围操作

5）字典

相当于hash

6）跳跃表

多层有序链表，zset 底层

底层存储所有有序数据，上层存索引（下层节点的抽样索引），越高层节点越少，跨越度越大。

节点自带跨度span，用来快速算排名；还有双向指针，支持正反遍历

跳表用概率随机层高替代复杂平衡操作，实现接近二分查找的高效有序数据结构。

添加流程

1. 初始 level=1。

2. 循环：生成随机数，取该随机数的低16位；若 < 0.25×65535，level+1，否则退出。（16位，一共就是2的16次幂-1 = 65535)

3. 结果不超过最大层高 64。

查找过程

从最高层开始走，能往右就右、不能就下沉一层，直到底层定位元素，类似多层二分。

随机层高就是为了好维护、高效率、不旋转、不变色，用一点点概率换取巨大的实现简化！ 🎲🚀

增删只改相邻指针，O(1)复杂度

完美适合ZSet（有序集合）场景

支持排序和范围查找

7）快速列表

后面版本3.2用于代替ziplist，和list

是压缩列表和列表的结合

持久化

RDB(Redis database 缩写快照）

每5分钟，将内容以快照形式保存到硬盘中。fork子线程进行持久化，将数据写到临时文件，持久化结束替换上一个文件

优点

• 只有一个dump.rdb文件，方便持久化
• 容灾性好，一个文件可以保存在安全磁盘
• 数据量大的时候，恢复速度比aof 快
• 性能最大化，fork子线程完成写操作，主线程继续处理命令。保证IO性能

缺点

• 一定时间保存快照，保存之前宕机，数据就会丢失
• 数据量大时，fork子进程会耗时，可能会影响对正常业务的响应

AOF(append only file)

Redis每次写命令都记录到日志文件，每次重启就将持久化的日志文件回复。如果同时开启RDB和AOF，有效使用AOF。Rewrite 模式，将过大文件进行合并重写，删除其中的某些命令

redis提供3种同步策略

• always：每次命令写入都立即同步
• everysec：每秒同步一次
• no：系统决定时间同步

重写

检测AOF文件大小，fork子进程，子进程进行重写。主进程将写命令写入aof缓冲区、重写缓冲区。子进程完成重写，主进程将重写缓冲区内容写到AOF，替换旧文件

优点

• 数据安全，可以做到记录备份每一条数据。保存的数据集比RDB完整
• 通过append 模式写文件，中途遇到宕机，可以通过Redis-check-aof 工具解决数据一致性问题

缺点

• 文件大，恢复慢
• 重写aof文件时，会占用大量cpu 和内存资源。导致服务load过高，出现短暂服务暂停现象

混合持久化

在 AOF 重写之前，RDB 和 AOF 都是按照它们各自的持久化策略工作的。当 AOF 重写被触发时，混合持久化才开始发挥作用：将当前的数据集会首先以RDB 格式写入新 AOF 文件的顶部，然后再追加新的命令到文件的末尾。

过期淘汰

Redis的key过期了，redis 如何处理

• 定时过期

到了时间就移除，但是占用大量cpu资源去处理过期数据，消耗CPU，影响缓存响应时间和吞吐量

• 惰性过期

只有当访问一个key的时候，才判断是否过期，过期则删除

最大化节省cpu 资源，但是可能会导致大量过期key长时间没有被访问，而占用大量内存

• 定期过期

每隔100ms时间，在过期字典随机抽取key，检测是否过期，过期则删除 。

expires 字典，保存redis中所有key的过期时间

通过调整扫描间隔时间和每次扫描限定耗时，可以做到对cpu 和内存达到最优的平衡效果

Redis同时使用惰性和定期两种过期淘汰策略，但是，可能存在漏掉很多过期key的情况，导致大量过期key堆积在内存

为什么key过期不立即删除

过期key较多的情况下，删除会占用相当一部分cpu时间。

从节点的过期策略

从节点不会进行过期扫描，从节点对过期的处理是被动的。主节点在key到期时，会在AOF文件里增加一条del命令，同步到所有的从节点，从节点通过执行这条del指令来删除过期的key。

因为指令同步到从节点是异步进行的，所以如果主节点过期的key的del指令没有及时同步到从节点时，就会出现主从数据的不一致，主节点没有的数据在从节点里还存在。

内存淘汰策略

全局键选择性移除

• 内存不足，新写入操作报错，默认方式
• allkeys-lru ，移除最近最少使用的key
• allkeys-random ，随机移除

设置过期键选择性移除

• volatile-lru ，移除最近最少使用的key
• volatile -random ，随机移除
• volatile-ttl ，最接近淘汰时间的key

内存用完会发生什么

默认是达到上限，拒绝写入，读可以正常

设置了内存淘汰策略，则使用

如何做内存优化

利用好集合类型数据，很多很小的key ，可以用更紧凑的方式存到一起

尽量使用散列表，散列表存储数少，使用内存小。比如用户信息，不要分开key 去存，存到一个散列表里

数据库有2000w 条数据，redis 只能存20w，如何保证redis里的都是热点数据？

我会首先把 Redis 内存淘汰策略设为 allkeys-lru，限制内存刚好容纳20w条数据，靠原生LRU自动淘汰冷数据、保留最近访问热点；

同时业务侧做访问热度统计，定时主动清理长期不访问数据，上线时按历史访问TOP20w提前预热；再配合布隆过滤器、互斥锁解决穿透和击穿，保证有限缓存里永远是最热业务数据。

事务

redis可以将多条命令打包成一条，一次性、顺序性、排他性的执行，中间不会被其他命令所打断。它通过multi命令开启事务，将命令入队，exec执行事务。

redis事务不支持回滚，如果遇到语法错误，那么整个事务都不执行。但是运行时报错，其他正确命令仍然会继续执行。

因此它无法保证原子性，但能够保证隔离性，持久性（通过AOF保证）。

我们还可以通过LUA脚本实现事务，但是同样也不能回滚

集群

一、Redis整体定位

通过多节点实现高可用、数据可靠、海量存储、高并发，多节点并行服务提升性能与可用性，主要有主从复制、哨兵、Cluster集群三种模式。

二、主从复制

1. 适用场景

数据备份、读写分离，配置简单，故障需手动切换。

2. 原理与流程

主节点异步复制数据到从节点，不阻塞主节点；从节点复制时对外返回旧数据，加载新数据会短暂暂停服务。

从节点发送psync建立连接

主节点后台生成RDB快照，缓存写命令

发送快照+缓存命令，从节点加载执行

后续主节点实时同步写命令

3. 核心注意

master必须开启持久化，否则宕机重启数据丢失，从节点同步后数据也丢失。

4. 缺点&解决方案

主节点复制压力大：采用树状级联复制，主只同步上层从节点

从节点过期key异常：Redis4.0+开启slave-lazy-expire yes

主从数据不一致：同机房部署、监控偏移量告警、强一致性读主节点

全量复制开销大：调大复制缓冲区、开启无盘复制、低峰期同步

三、哨兵（Sentinel）

1. 定位

基于主从复制，独立进程，不存数据，负责监控、自动故障转移、通知客户端；不支持分片扩容。

2. 架构

至少3个哨兵保证自身高可用。

3. 故障转移流程

哨兵Ping监控主节点，超时标记主观下线

多数哨兵判定故障，标记客观下线

哨兵投票选出领头哨兵，执行故障转移

优先选偏移量大、优先级高的从节点升主

其余从节点同步新主，旧主重启后降级为从

发布订阅通知客户端切换主节点

4. 脑裂问题

网络分区导致新旧主同时写入，网络恢复后旧主清空数据，分区写入丢失；

解决：主节点配置参数，无合格从节点时拒绝写操作。

四、Cluster集群（官方分布式）

1. 核心原理：哈希槽

固定16384个哈希槽，分片规则：slot=CRC16(key)%16384，主节点分配连续槽位；槽位图仅2KB，扩缩容平滑，优于一致性哈希。

16384为2¹⁴，槽位图2KB，适配Gossip消息最优传输大小。

2. 故障转移（Raft算法）

故障检测：心跳超时→主观下线；半数主节点确认→客观下线

从节点筛选：断线≤160s、状态正常

主节点投票，偏移量最大的从节点获半数选票晋升主节点

接管槽位、广播配置、从节点重认主，旧主恢复后降级为从

客户端访问故障节点槽位时，集群返回重定向指令与新主地址

3. 通信机制

去中心化，节点两两TCP连接，Gossip协议同步状态、槽位、故障信息。

4. 特点&优缺点

• 优势：自动容灾、分片扩容、负载均衡、动态增减节点

• 限制：不支持跨槽多key（hash tag规避）、主从异步复制有丢数风险、过半主节点宕机集群不可用、扩容影响性能

5. 数据倾斜问题

6. 数据倾斜：大key拆分、巡检治理、规范单key大小；调整槽位、拆分热key

7. 请求倾斜：热点key多副本、客户端/二级缓存；读请求轮询从节点

五、分布式寻址算法对比

1. 哈希取模：简单；增删节点大量key重分布，缓存雪崩风险高

2. 一致性哈希：增删节点影响小；节点少易倾斜

3. 虚拟槽分区（Cluster）：固定槽位，扩缩容平滑均匀，Redis集群采用

4. 哈希槽+代理：Codis/Twemproxy，客户端无感知；Redis Cluster无代理、直连

六、生产部署方案

1. 主从+哨兵：数据＜100GB、中小并发，1主2从+3哨兵

2. Cluster集群：3主3从（最小生产架构），海量数据、高并发、需水平扩展

3. 云环境：优先云托管Redis

七、Redis单线程CPU利用率优化

单节点部署多Redis实例，通过客户端分区、代理分区实现；

缺点：不支持多key事务、大key难分区、扩容复杂。

八、模式选型

• 主从+哨兵：数据量小、需高可用（配置、会话存储）

• Cluster：海量数据、高并发（电商、社交、大数据缓存）

生产中redis 是如何部署的

生产环境Redis部署，核心是高可用+数据安全+可扩展，主流方案分哨兵（Sentinel）与集群（Cluster）两大类。

集群模式（Cluster，大规模/高并发）

• 标准架构：3主3从（最小生产集群，6节点）

• 核心原理：

◦ 数据分片：共16384个哈希槽，均匀分配给3个主节点，实现水平扩展

◦ 主从高可用：每个主节点配1个从节点，主挂了从自动升主

◦ 无中心P2P：节点间通过Gossip协议通信，客户端直连集群

适用场景：数据量＞100GB、高并发读写、需横向扩展、分布式系统

部署选型决策

• 数据量＜100GB、中小并发 → 1主2从+3哨兵（简单稳定）

• 数据量＞100GB、高并发、需扩展 → 3主3从Cluster（水平扩展）

• 云环境 → 优先云托管（如阿里云Redis、AWS ElastiCache），省心高可用

Redis最大节点个数

16384，为什么？

16384是2的14次幂。

16384 个槽：`16384 bit = 16384 / 8 = 2048 Byte = 2KB

（1 byte = 8 bit

1kb = 1024 byte )

为什么是16384个槽？哈希槽信息在Gossip消息中通过bitmap存储，16384个bit刚好是2KB，符合Gossip消息的最优传输大小，既保证了分片粒度足够细，又不会导致集群通信消息过大。

Redis是单线程的，如何提高cpu 利用率？

部署多个实例

分区

Redis是单线程应用，可以在一个节点，部署多个实例，提高cpu利用率

为什么

Redis能管理更多内存，它的计算能力，网络带宽随着计算机的增加而增加

哪些分区方案

客户端分区

客户端自己决定在哪个分区读写

代理分区

客户端把请求发到代理上，代理根据分区规则决定在哪个分区读写

缺点

涉及多个key 的操作不支持，比如两个key集合取交集

多个key同时操作，不能保证事务。

大key不能分区。集群的分区最小粒度是key，通过key取模决定在哪个节点，如果要持久化，进行操作，都需要跨节点，复杂

在线扩容缩容难

分布式锁

使用setnx 实现分布式锁

Set if not exsit

当且仅当key 不存在时，就设置给定的值。

使用setnx获取锁，设置成功返回1，否则返回0。

为了防止获取锁后程序发生异常，造成死锁，给锁设置一个合理的过期时间，使用del命令将锁数据删除。对于耗时的操作，涉及续期（看门狗）操作。

存在问题

主从模式下，master 宕机，锁失效 。故障转移后，其他线程就能拿到锁

setnx和expire分2步执行，非原子操作；若setnx执行成功，但expire执行失败，就可能出现死锁

delete命令存在误删除非当前线程持有的锁的可能

不支持阻塞等待、不可重入

Redlock

Redis官方提供的分布式锁。集群环境下依次给各个节点加锁 、超过半个以上的节点加锁成功就算成功。特征是

安全，互斥保证只有1个客户端能获取到锁

容错性，只要大部分节点存活，就能正常提供服务

redission

什么是redission

Redis客户端框架，工具包。用Java操作redis ，把Redis常用数据结构封装成Java对象，还自带分布式锁，队列，延迟队列等一堆开箱即用的功能。内部自动解决：

• 可重入锁
• 自动看门狗续期
• 安全删锁（Lua 脚本)
• 阻塞队列
• 公平锁，联锁

什么是分布式锁

服务通常部署在多个节点（多台服务器），本地锁只能控制单个节点内的线程，无法控制其他节点的线程访问共享资源。这个时候需要分布式锁，跨服务，跨节点的互斥机制，用于保证多个服务实例对共享资源的同步操作。

分布式锁需要满足以下特性

• 互斥性：同一时间只有一个实例能获取到锁
• 安全性：锁只能被持有锁的实例释放
• 防死锁：即使持有锁的实例崩溃，也能自动释放
• 可用性：获取锁释放锁的操作要高效，避免成为性能瓶颈
• 容错性：redis节点宕机，锁机制仍能正常工作

基于redis 实现的分布式锁存在的问题

• 原子性
• 不可重入
• 同一线程无法多次获取同一把锁
• 不可重试
• 获取锁只尝试一次就返回fasle 。可以在业务端重试
• 超时释放，如果业务耗时较长，超过设置的过期时间，锁也会被释放，存在安全隐患
• 主从一致，主从同步延迟，主机宕机，未来得及同步到其他机器，出现多线程获取锁的情况，线程不安全

Redisson实现加锁的原子性是依赖lua脚本来实现的

redission 分布式锁

Redis基于单线程指令执行，并且可以将key作为一个互斥的标记，来实现分布式锁。

如果仅仅使用key是否存在来做分布式锁，不能满足复杂业务，如可重入，可重试，锁续期等。

Redission 客户端在实现分布式锁的同时，封装了比较高级的功能，符合业务需求，保证高可用。

Redission 实现可重入锁

加锁与可重入机制

‌底层命令‌：使用 Redis 的 SETNX 命令结合‌Lua 脚本‌执行，确保加锁操作的原子性，避免并发问题 。

‌数据结构‌：锁信息存储在 Redis 的‌Hash 结构‌中，key 是锁名，field 是线程唯一标识（UUID+ 线程 ID），value 是重入次数 。

‌可重入实现‌：同一线程再次加锁时，重入次数 +1；解锁时 -1，直到次数为 0 才真正删除锁，允许同一线程重复获取锁 。‌‌‌

锁重试

锁重试并不是循环不断调用tryAcquire方法获取，这样容易造成cpu 浪费，而是通过等待锁释放，再去获取锁的方式实现可重试，利用信号量和发布订阅模式实现等待，唤醒、获取锁失败的重试机制

看门狗自动续期

‌默认过期时间‌：未指定锁过期时间时，默认‌30 秒‌自动释放，防止服务宕机导致锁悬挂 。

‌续期逻辑‌：启动后台线程，每‌10 秒检查一次‌锁是否仍被持有，若持有则续期至 30 秒，形成循环续约 。判断field 是否存在，存在就续期，并递归调用，生成下次的续期任务。

‌注意事项‌：如果手动设置了锁过期时间，看门狗机制会‌自动关闭‌，需自行控制锁时长

RedLock

Redission客户端提供的为了保证锁不丢失的方案。分布式加锁的时候，去不同的独立的集群加锁，超过半数以上，并且总耗时过期时间内，加锁成功才算加锁成功。释放锁也是向所有节点集群发起释放请求，超过半数以上解锁成功才算成功。即使部分节点宕机，只要多数节点存活，也能保证锁服务可用。

弊端：

1.性能差，网络开销大

2.极度依赖时钟，一旦某节点时间偏快，锁提前过期；新客户端直接加锁成功，多客户端同时持有锁，互斥性直接破

3.运维成本高

联锁

同时锁多个独立资源（多key原子加锁）

异常问题

击穿

大量请求的Key不存在缓存,导致请求直接到数据库，造成数据库压力

解决

• 接参数校验。校验不合法参数
• 缓存数据库中不存在的数据并设置过期时间，解决请求的key不频繁的情况。如果黑客攻击，构建不同key，会造成缓存大量无效key。就需要给key设置短一点的过期时间
• 采用布隆过滤器。将所有可能存在的数据哈希存到一个足够大的bit map中。一个不存在的数据会被bitmap拦截，避免数据库的查询压力

布隆过滤器

判断一个数据在集合中是否存在。

存在一定误判率。过滤器越长误判率越小

穿透

一个热点key，扛着大并发。大并发集中在一个时间访问这个key 时，缓存失效了。就会导致大并发请求打到数据库

解决

• 热点数据缓存不失效
• 加分布式锁，保证一个时间只有1个线程访问数据库，将数据缓存到redis

雪崩

某一时间段，缓存集中过期。致命的雪崩在于，缓存某个节点宕机 或断网

解决

• redis 高可用

缓存降级，缓存失效后通过加锁或队列对读数据库，写缓存的线程数量，比如对某个key只允许一个线程去数据库获取数据写进缓存，其他线程等待。

• 缓存预热

正式部署前，将数据预先访问一遍，加载到缓存中。

即将发生大并发之前，将数据缓存，并设置不同过期时间，使得失效时间尽量均匀

如何保证数据库缓存双写一致

先更新数据库，再删除缓存。可能会出现暂时不一致的情况。但是发生几率小

• 延迟双写，写数据前后都删除缓存，设置合理的超时时间，超时时间考虑redis 数据主从同步耗时，确保读请求结束，在读逻辑的耗时上，加几百毫米
• 使用读写锁

一个字符串的值能存储最大容量是多少

512M

如何做大量数据插入

使用pipeline 。一次性发送多条命令，执行完后一次性打包返回。减少客户端与redis通信次数，降低往返延迟时间。

底层是队列，默认同步个数是53个，命令数量累计到达53，就把数据提交

Redis需要在所有命令执行完之前缓存执行结果。

具体能容忍的操作个数与缓冲区大小和返回数据大小有关。

每个Redis服务能够接受的pipeline连接数，是有限的，跟服务的物理内存，网络接口的缓冲能力有关

有10w个key是以某个固定的已知的前缀开头的，如何全部找到他们

Keys命令，扫出指定模式的key列表

但是如果此时redis正在给线上业务提供服务，keys 会阻塞线程一段时间，那么线上业务会停顿，直到命令执行完，才恢复

可以使用scan，可以无阻塞取出key 的所有列表。但是会有重复率，需要去重。

redis异步队列

使用list 类型。rpush ，lpop 。当lpop 没有消息时，可以先sleep 一段时间。或者使用blpop ，没有消息会一直阻塞。

使用pub/sub订阅模式实现生产者消费者

延迟队列

使用sorted set ，score 存时间戳，key存消息内容。通过zadd 生产消息，zrangeByScore获取n秒前的数据轮询处理

大key

影响

• 持久化

AOF，存在很大大key，很快就会触发重写aof ，重写时会阻塞主线程

RDB，fork子线程会阻塞主线程，因为主线程页表太大，复制会耗时。

• 其他

还会引起客户端超时阻塞，网络阻塞，每次获取大key 产生的网络流量都很大

• 删除大key会阻塞线程。
• 集群模式下，slot分布均匀，存在大key的节点占用太多内存，会导致数据倾斜。

解决

• 拆分key
• 删除不使用del，使用unlink