# 第一部分 | 基础概念 ## 1. Redis 的数据类型有哪些 1. String：存文本、数字、二进制。常用来存用户信息、Session、查询结果、阅读量、点赞数 2. List：有序列表，底层使用 quicklist，可以用作简单的消息队列 3. Hash：键值对集合，把多个字段和值存在同一个 key 下面 4. Set：无序不重复，适用于标签系统 5. ZSet：类似于 Set，底层使用跳表+哈希表，每个元素都携带一个分数用来排序，常用于排行榜、热搜榜等场景 6. BitMap：用位来存数据，每个 bit 只有 0/1，常用于签到场景（setbit 设置状态，getbit 读取状态） ```bash SETBIT user:sign:202409 12345 1 # 用户 12345 在 9 月签到 GETBIT user:sign:202409 12345 # 查询签到状态 ``` 7. HyperLogLog：一种概率性去重算法，通过牺牲极小的精度（约 0.81％），换取固定且极小的内存开销（固定 12KB），适用于独立访客（UV）这种对精度要求不高但数据量巨大的场景 ```bash PFADD page:uv user1 user2 user3 # 记录访问用户 PFCOUNT page:uv # 估算独立用户数 ``` 8. GEO：存地理位置信息，支持经纬度存储和空间查询，底层使用 ZSet，经纬度会被编码成 score，典型场景就是“附近的人”、外卖配送距离计算 ```bash GEOADD riders 116.403 39.915 "rider001" # 存骑手位置 GEORADIUS riders 116.4 39.9 5 km # 查 5 公里内的骑手 ``` 9. Stream：专为消息队列设计，相比 List 更适合做消息队列，支持消息 ID，消费组、消息确认和失败重试 ## 2. Redis 的数据结构有哪些 1. 简单动态字符串（SDS）：不是使用 C 语言原生的 char 数组，而是 Redis 自己实现的字符串结构。可以直接获取长度、存二进制。SDS 有三个核心字段，len 记录当前长度；alloc 记录可分配空间；buf 存储数据。扩容后小于 1M 翻倍，大于 1M 加 1M。当值是 long 范围内的整数使用 int 编码；<=44 字节使用 embstr 编码；>44 字节使用 raw 编码 2. 哈希表（HashTable）：数组+链表，精确查找 O(1)，但内存分散指针开销大 3. 整数集合（IntSet）：本质是一个有序整数数组+元信息，内存连续、有序不重复、不存指针 4. 压缩列表（ZipList）：一块连续的内存，把所有元素紧凑的放到一起，省内存但不适合存大量数据。开头zlbytes 记录整个链表占多少字节，zltail 记录最后一个节点的偏移量用于快速定位尾部，zllen 记录节点个数，中间是一个个 entry 节点紧密排列，最后用 zlend（0xFF）标记结束 5. 紧凑列表（ListPack）：Redis 7 及之后 ziplist 的替代品【其实是 5.0 引入的，只是那时只用于 stream】。内存连续无指针开销，顺序查找 O(n)，解决了 ZipList 的级联更新问题（ziplist 每个 entry 存了前一个entry 的长度，这个 pre_entry_length 是变长的，前一个 entry 小于 254 字节时占 1 字节，大于 254 就占5 字节，如果有一串 entry 都为 253 字节，在前面插入一个 260 字节的新 entry 时，后面记录长度的字段就要从 1 字节变为 5 字节，一路传递；listpack 改成只存当前节点的长度，往前遍历的时候，先读当前节点的element-tot-len，就能算出这个节点的起始位置，跳转到前一个元素） 6. QuickList：Redis 3.2 之后 List 的默认实现，本质是双向链表穿起来一些小的 ziplist，每个 ziplist 控制在一定大小，级联更新最多影响一小块不会波及整个链表（Redis7 时 ziplist 就变为 listpack 了） 7. 跳表（SkipList）：本质就是多层链表，最底层存放所有元素，往上依次是相邻下层链表的子集。并且 Redis 中的跳表多了回退指针（只在最底层）。查找：从最上层开始，逐层向下进行查找，如果在该层得到数据，直接返回，否则确定查找元素的范围继续进行下一层查找，时间复杂度 O(logn)。插入：查询所要插入的位置，随机决定新节点的层数（25％往上加一层），插入节点并更新指针。删除：查询所要删除的位置，删除节点并更新指针 ## 3. 数据类型与数据结构的对应关系 1. String：用 SDS，支持 O(1) 获取长度、存二进制 2. List：使用 QuickList 3. Hash：数据量小用 listpack 存储节省内存（Redis 7 之前使用的是 ziplist）【字段数 ≤ 512 且单个值 ≤ 64 字节】；数据量大用 hashtable 查询效率为 O(1) 4. Set：数据量小且元素都是整数时，用 intset 存储节省内存【元素个数 ≤ 512】；数据量大或出现非整数元素时，自动转换为 hashtable，支持 O(1) 的增删查 5. ZSet：数据量小用 listpack 存储节省内存（Redis 7 之前使用的是 ziplist）【元素个数 ≤ 128 且每个元素长度 ≤ 64字节】；数据量大用 skiplist+hashtable（跳表用来存储数据和快速查找，哈希表用来存储成员与其分数的映射） ## 4. Redis 数据过期后的删除策略有哪些 1. 惰性删除：被动触发，每次读写某个 key 之前，先判断一下是否过期，过期了就删掉返回空 - 优点：不占用额外的 CPU 去扫描 - 缺点：如果 key 过期了一直没人访问，会一直存在，导致内存泄漏 2. 定期删除：每隔一定时间抽取一批（20个）设置了过期时间的 key，将过期的 key 删掉，如果本次过期比例超过 25％，就会继续取下一批进行操作，如果过期低于 25％，结束本轮。每轮启动的时候会计时，达到 25ms 直接强制结束 - 优点：25％阈值保证在过期 key 多的情况下加速清理，25ms 限制避免清理动作影响正常请求处理 - 缺点：可能清理不完全 3. 所以一般是两种策略配合使用（惰性删除+定期删除） 4. Redis 维护了一个专门存放设置了过期时间 key 的字典，key 指向实际的 key 对象，value 是过期时间的毫秒级 unix 时间戳。检查 key 是否过期就是拿当前时间和字典里存的时间戳对比。惰性删除是每次访问 key 前检查，定期删除是在字典里随机抽样检查 5. 在主从场景下，从节点不会主动删除自己过期的 key，而是读到过期 key 就返回空（注意 3.2 版本之前依然能读取过期的 key ），等主节点同步过来 del 命令再执行删除 ## 5. Redis 的内存淘汰策略有哪些 1. 有 8 种淘汰策略 - noeviction：Redis 默认策略，内存满了直接报错拒绝写入 - volatile-lru：最近最少使用的先淘汰（设置了过期时间的 key） - volatile-lfu：使用频率最低的先淘汰（设置了过期时间的 key） - volatile-random：随机淘汰（设置了过期时间的 key） - volatile-ttl：剩余存活时间短的先淘汰（设置了过期时间的 key） - allkeys-lru：最近最少使用的先淘汰（所有 key） - allkeys-lfu：使用频率最低的先淘汰（所有 key） - allkeys-random：随机淘汰（所有 key） 2. 关于 LRU 和 LFU 的缺点：LRU-某段时间有大量冷数据被扫描，真正的热点数据会被挤出去；LFU-如果历史访问了多次，近期内都不访问，也不会删除（4.0 对 LFU 进行了优化，访问计数会随时间缩减，避免“僵尸热点”） 3. noeviction 一般用于消息队列、allkeys-lru 适用于大多数场景、allkeys-lfu 适用于有明确的热点数据 4. 注意：如果没有任何 key 设置过期时间，那么用 volatile 毫无作用，跟没设置一样 5. LRU/LFU 并不是精确算法，而是默认采样 5 个 key，选一个符合条件的淘汰。将这个值调大能提高淘汰精度，但会增加 CPU 开销，一般 5-10 个就行 ## 6. Redis 的持久化机制有哪些 1. RDB：快照持久化，某个时间点将整份内存数据转储为一个二进制文件，文件体积小，恢复速度快，适合做备份和灾难恢复。但是如果两次备份期间 Redis 挂了，就丢失了这段时间的数据 - 方式：bgsave，通过 fork 子进程来生成快照，fork 期间会阻塞主进程，之后主进程继续处理请求，子进程把内存数据写到临时文件，写完后替换掉旧的 dump.rdb 文件（还有一种就是 save 命令，但它是用主进程生成 RDB，期间 Redis 会阻塞，不推荐） - 流程：检查是否有正在执行的 AOF/RDB 子进程，有的话直接报错--->调用 rdbSaveBackground 触发持久化--->fork 子进程生成 RDB，主进程继续处理请求--->新文件替换旧文件 - 注意：子进程创建时并不是真的复制一份内存而是复制页表（页表里存的是物理内存地址），父子进程共享一块内存，只有当某个进程要修改数据时，才会把对应的内存页复制一份出来单独修改 2. AOF：日志持久化，将每条写命令追加到文件里，最多丢失 1s 数据，但是文件体积大，恢复速度慢 - 三种策略：always-每条命令执行完立刻写入；everysec-每秒写一次（默认）；no-让操作系统决定什么时候刷盘 - AOF重写：随着时间推移，有很多命令执行，但最终有意义的只有少数，所以重写来生成新的精简的AOF文件 - 重写流程：fork 出子进程--->子进程生成新的 AOF 文件，期间主进程写的新命令追加到旧 AOF 和重写缓冲区--->子进程写完后，主进程将重写缓冲区内容追加到新的 AOF 文件--->新文件替换旧文件 3. 混合持久化（4.0 之后引入）：AOF 重写时先写 RDB 快照，后面的增量命令用 AOF 追加。恢复时先加载RDB 部分，再加载 AOF 部分，恢复速度和安全性提高 4. 为了解决重复数据导致的内存、CPU、磁盘浪费问题，7.0 引入了 MP-AOF 机制，将单个 AOF 拆为基础文件、增量文件和清单文件。重写期间写命令添加到新的增量文件，子进程生成新的基础文件，重写完成后更新清单文件（增量文件+基础文件） ## 7. 缓存击穿/穿透/雪崩 1. 缓存击穿：请求一个不存在的数据，无法进行缓存，每次都打到数据库 - 解决方案：参数合法性校验/布隆过滤器/缓存空值（推荐三者结合使用） 2. 缓存穿透：某个 key 过期的瞬间，大量请求同时涌进来，全部打到数据库（一个） - 解决方案：互斥锁/热点数据永不过期 3. 缓存雪崩：一批 key 同时过期，请求全部打到数据库上（一片）；还有一种可能就是 Redis 挂掉 - 解决方案：设置随机过期时间；对于 Redis 方面而言，可以考虑主从+哨兵、本地缓存兜底、熔断降级等措施 4. 详细说说布隆过滤器：可以使用 Redis 自带的 RedisBloom 模块，把所有合法的 key 预先加载进去，请求来了先问布隆过滤器看看这个 key 存不存在，如果不存在直接返回。布隆过滤器可能会误判，但只会误判存在，不会误判不存在（位数组越大、哈希函数越多，误判率就越低。但内存占用和计算开销也会变高。一般把误判率控制在 1％以内就可以了） 5. 关于热点数据永不过期的方案：第一种就是不设置过期时间；第二种是在 value 中存一个过期时间戳，后台起一个线程定期检查，快过期了就刷新一下 # 第二部分 | 主从集群 ## 1. Redis 主从复制的实现原理是什么 1. 从节点连接主节点时会发送 psync 命令、runid、offset（首次：psync、?、-1），主节点收到命令判断为全量同步，返回 fullresync、master runid、offset，从节点保存 master runid 和 offset 2. 主节点生成一份 rdb 快照发给从节点，从节点拿到后先清空自己的数据，然后加载这份快照（在生成和发送快照这段时间，主节点收到新的写命令会存在`Replication Buffer`的缓冲区内，等快照发完后，再将这个缓冲区的命令发送给从节点） 3. 全量同步完成后，会在主从之间建立长连接，主节点收到命令后会异步发给从节点（期间也会进行心跳检测） 4. 如果从节点断线重连，会告诉主节点自己当前的偏移量，主节点拿着这个偏移量去`repl_backlog_buffer`环形缓冲区查找，如果找到执行增量同步，将断线这段时间的命令发给从节点；如果找不到，说明缓冲区数据已经被覆盖了，只能进行全量同步（环形缓冲区的大小默认 1m，可适当调大） 5. 注意点：从节点加载 rdb 时无法对外服务；主节点发送数据是异步的，自己写完不管从节点是否成功，直接返回，可以使用 wait 命令等待指定数量的从节点同步完成 ## 2. Redis 主从复制延迟的常见原因有哪些，如何解决 1. 网络层面：带宽不足、网络抖动、跨机房部署延迟高 - 解决方案：监控流量、检查网络稳定性、主从节点同机房部署 2. 主节点瓶颈：写入 QPS 过高、生成 RDB/AOF 重写占用资源、大 key 写入阻塞 - 解决方案：分片、关掉主节点的持久化、大 key 拆为小 key 3. 从节点瓶颈：机器配置低、磁盘 IO 跟不上、从节点数量太多 - 解决方案：升级硬件、使用 SSD、限制从节点数量考虑级联复制 4. 复制机制：复制积压缓冲区配置过小，导致从节点频繁进行全量复制 - 解决方案：增加环形缓冲区大小 5. 如果一定要读最新的数据（写入立刻读），可以采用：关键业务读主库；使用版本号/时间戳，如果从库数据太旧就读主库；使用 wait 命令，等至少一个从节点同步完成在返回，但性能大幅降低 # 第三部分 | 分布式锁 ## 1. 如何使用 Redis 实现分布式锁 1. 核心就是加锁时使用`set key value ex seconds nx`，nx 保证互斥，ex 设置过期时间防止死锁；解锁时使用 Lua 脚本先校验再删除，保证原子性 2. 加锁流程：执行`set key uuid ex 30 nx`，Redis 检查该 key 是否存在，不存在则加锁成功；存在则返回 nil，加锁失败 3. 解锁流程：执行 Lua 脚本，先获取当前 key 的值，判断值是否等于自己的 uuid，相等则进行解锁，否则锁不是自己的 ```java public class RedisLock { private Jedis jedis; private String lockKey; private String uuid; private int expireTime = 30; // 秒 public boolean tryLock() { uuid = UUID.randomUUID().toString(); String result = jedis.set(lockKey, uuid, SetParams.setParams().nx().ex(expireTime)); return "OK".equals(result); } public void unlock() { String script = "if redis.call('get', KEYS[1]) == ARGV[1] then " + "return redis.call('del', KEYS[1]) else return 0 end"; jedis.eval(script, Collections.singletonList(lockKey), Collections.singletonList(uuid)); } } ``` ## 2. Redis 实现分布式锁需要注意哪些问题 1. 锁过期但业务没跑完：锁过期自动释放，其他线程就能拿到锁，可能导致数据不一致 - 解决方案：使用Redisson 提供的看门狗机制，锁自动续期 2. 误删别人的锁：锁过期，另一个请求拿到锁，之前的请求执行完后删的锁就是新请求的锁了 - 解决方案：每次加锁带上唯一标识，使用 Lua 脚本先判断再删除 3. 主从同步延迟：主节点刚写入锁就挂了，数据还没来得及同步到从节点，新主上来后锁就丢失了 - 解决方案：使用 RedLock，加锁时向所有实例申请加锁，超过一半的实例加锁成功才能真正拿到锁，但这种是并列实例，不适用于主从延迟 - 正确方案：做幂等校验或者使用 zookeeper/etcd 这种强一致性系统 4. 时钟漂移：多节点的系统时间不一致，ttl判断不准确，锁可能提前释放或延迟释放 - 配置NTP（Network Time Protocol，网络时间协议）服务同步时间，将时钟偏差控制在毫秒级 5. 锁不可重入：同一线程想要再次获取同一把锁，被拒绝了，比如递归场景 - 解决方案：使用 Hash 类型，key 是锁名，field 是客户端标识+线程 ID，value 是重入次数，减到 0 才真正删除锁 ## 3. RedLock 是什么 1. RedLock 专门用来解决主从架构下锁丢失问题：主节点加锁成功，还没同步到从节点就挂了，从节点晋升为主节点但锁的数据没有同步过来，另一个客户端来加锁也能成功，此时就会有两个客户端同时操作临界区资源，可能导致数据不一致 2. RedLock 实现思路是独立部署多台Redis实例（一般 5 台），通过投票的方式判断加锁是否成功。不需要主从复制，也不需要哨兵，完全独立 3. 加锁流程：记录当前时间 t1--->向所有 Redis 实例发送加锁命令--->统计成功加锁的实例数量以及当前时间 t2 --->只有成功数量≥半数以上且加锁总耗时 < 锁过期时间（t2-t1）才算加锁成功--->否则向所有实例发送解锁命令 4. 不足：时钟漂移、STW 等场景可能导致锁被释放，另一个客户端就能拿到锁，同时操作临界区资源，造成数据不一致。所以 RedLock 不能保证 100％可靠；并且 RedLock 需要部署多台实例，访问多个节点，增大了资源开销与延迟 5. 所以大多数场景还是采用主从+哨兵方案，配合 Redisson 看门狗机制续期，以及幂等性校验；如果需要强一致性的分布式锁，可以考虑 zookeeper 或 etcd ## 4. Redisson 分布式锁的原理 1. 核心就是使用 Redis 的 Hash 结构+ Lua 脚本保证原子性+后台线程自动续期 2. 加锁流程 - 如果锁不存在，直接创建 Hash 结构，field 是线程标识，value 设为 1，设置过期时间，加锁成功 - 如果锁存在且 field 是当前线程，说明是重入，将 value 加1，刷新过期时间，加锁成功 - 如果 field 不匹配，说明锁被占用，返回这个锁的剩余存活时间，加锁失败。等收到消息或者到达返回的剩余存活时间再重新加锁 3. 解锁流程 - 锁不存在或者 field 不匹配当前线程，直接返回 - field 匹配，value 减 1，如果减完 value 依然大于 0，说明还有重入没退出，刷新锁的过期时间 - value 减到 0，删除 key，推送消息通知其他等待的线程 4. Redisson 锁的类型 - 可重入锁：同一线程可多次获取同一把锁 - 公平锁：按顺序排队，先到先得 - 读写锁：读锁共享，写锁独占 # 第四部分 | 看门狗机制 ## 1. 说一说 Redisson 的看门狗机制 1. 看门狗机制是用来解决分布式场景下锁的续期问题。比如业务逻辑没执行完锁就到期释放了，别的线程拿到锁，两个线程同时操作临界资源，造成数据不一致 2. 看门狗的实现原理是：如果不指定过期时间，Redisson 会启动一个定时任务，每隔 10s 向 Redis 发一次请求，如果任务还没结束，就通过 Lua 脚本将锁的过期时间重置为 30s，所以只要任务没结束，锁就不会释放（期间如果出现客户端宕机等问题，定时任务也就没了，到了 30s 会自动释放锁） 3. 续期间隔设置为锁过期时间的 1/3 的原因：在续期频率和网络开销取了个平衡值，太频繁对 Redis 压力大； 1/3 的过期时间也保证了出现网络抖动等问题续期失败后，还有机会重新续期 4. 注意：看门狗机制不一定 100％解决冲突问题，如果某些原因打断了锁的自动续期，到了时间锁就释放了，这时候任务还在跑着，另一个线程拿到锁就会同时操作临界区资源了。所以关键业务必须保证幂等和进行数据校验 5. 注意：如果业务代码出现死循环，看门狗就会一直对锁进行续期，锁永远不会释放。所以一定要保证 unlock在 finally 里调用；或者使用 try-with-resources；或者放弃看门狗，主动设置过期时间等机制 ## 2. Redisson 看门狗机制的进一步探究 1. 续期主要涉及来个方法：获取续期任务（scheduleExpirationRenewal）、定期刷新过期时间（renewExpiration） 2. scheduleExpirationRenewal：客户端拿到锁之后调用，将当前锁注册到续期 map 里，然后启动定时任务 - 创建一个 entry 对象存锁的过期时间 - 使用 putIfAbsent 往 map 里塞，如果已经有了就把当前线程 ID 加进去 - 否则，调用 renewExpiration 启动定时任务；如果线程被中断，调用 cancelExpirationRenewal 取消续期 3. renewExpiration：通过 Netty 时间轮创建定时任务 - 从 map 里拿 entry，如果拿不到说明锁已经释放，直接返回 - 检查里面有没有线程 ID，没有就说明没人持有锁，直接返回 - 调用 renewExpirationAsync 异步续期，续期成功就重新调度自己，失败就取消续期 4. renewExpirationAsync 的逻辑其实很简单，就是检查锁是不是自己的，是的话就续期 5. cancelExpirationRenewal 的逻辑是移除线程 ID，然后判断是否还有任务，没有的话就取消定时任务并移除 entry 6. 使用 Netty 时间轮的原因：添加和取消任务都是 O(1)，并且 Redisson 底层通信依赖 Netty，直接复用 Netty 的时间轮也避免引入额外的线程池 # 第五部分 | 事务 ## 1. Redis 是否支持事务，如果支持如何实现 1. Redis 是支持事务的，但和 Mysql 中的事务不同，Redis 只保证将命令打包执行不被其他客户端插队，不支持回滚（因为 Redis 命令只有语法错误/类型错误的情况下才会执行出错，属于程序方面的问题，应该在开发阶段修正） 2. Redis 通过 multi、exec、watch、discard 这四个命令实现事务 - multi 用来开启事务，之后的命令不会立刻执行，而是进入一个队列排队。可以放多条命令，Redis 会回复 queued 表示入队成功 - exec 会一次性把队列中的任务全部执行，期间不会被其他客户端的命令打断 - 如果不想执行了，使用 discard 丢弃队列 - watch 则用来在 multi 前监视某些 key，如果这些 key 在 exec 前被改了，整个事务作废 3. Redis 会在入队阶段做语法检查，如果有问题（比如参数个数不对），入队会报错，后续 exec 会拒绝执行整个事务；如果是类型错误，则会成功入队，但在执行时这条命令会报错，其他命令正常执行 4. 再说一说 watch 这个命令，它类似于乐观锁，watch 之后的 key 如果被别的客户端改了，exec 时会返回 nil表示事务被放弃，需要重新读取 key 的值重试。底层实现就是 Redis 给每个被 watch 的 key 维护一个客户端列表，key 被修改时标记这些客户端的事务为失效状态 5. 在实际开发中，要想实现多条命令原子执行，还是推荐 Lua 脚本。Lua 脚本在 Redis 中执行是原子性的，并且可以写判断逻辑，比事务更灵活，并且网络往返只需一次 ## 2. Redis 的 Pipeline 是什么，与事务、Lua 脚本、原生批处理命令有什么区别 1. pipeline 可以让客户端将多条不同类型的命令打包一次性发给 Redis，减少网络往返次数。但是它不能保证原子性，批量执行命令的时候，失败不会回滚，而是继续执行；执行过程中可能穿插其他客户端的命令；底层原理是把命令的收发放到内存缓冲区，如果命令数量太多会导致两边内存占用增加。如果涉及多个节点，需要客户端先进行处理 2. 而事务使用 multi/exec 包裹命令，虽然也不支持回滚，但是具有原子性，这批命令执行期间不会穿插其他客户端的命令 3. Lua 脚本在 Redis 中执行是原子性的并且支持条件判断，脚本一次性执行，其他客户端没法穿插命令，但是同样不支持回滚 4. mget/mset 等原生处理命令只能用于同一种数据类型，天生具有原子性，中间不会被插入其他命令。如果涉及多个节点，需要客户端手动处理 # 第六部分 | 性能优化 ## 1. 如何解决热点 key 的问题 1. 首先明确热点 key 的定义：访问频率占比大、带宽占比大、CPU 使用时间占比大等场景 2. 其次是发现热点 key - 业务预判：提前预判哪些 key 可能成为热点，但无法应对突发情况，适用于可预期的活动 - Redis 自带的命令`redis-cli-hotkeys`：扫描慢，非实时，适用于临时排查 - monitor 命令：监控所有命令执行，配合脚本统计 key 的频次，但会损失 50％的性能，生产环境慎用！ - 客户端埋点：在 Redis 客户端 SDK 加统计逻辑，进行上报监控，但是改造成本高，适用于有统一 SDK 的场景 - proxy 层收集：客户端无感，但是需要部署代理，适用于已有代理架构的场景 3. 最后针对性的解决热点 key 的问题 - 拆分 key：将 key 放到不同节点（全量复制/分片存储） - 多级缓存：在 Redis 前加 cdn/本地缓存 - 读写分离：一主多从，主节点只负责写，读请求发到从节点 - 限流降级：当某个 key 访问频率过高，进行限流，必要时返回降级的数据或空值 ## 2. Redis 达到性能瓶颈后应该如何处理 1. 分析瓶颈点 - 内存不足：频繁淘汰数据，响应时间飙升 - CPU 打满：耗时操作、大 key 操作等 - 网络带宽：比如传输一个达到最大限制的 512M 的数据 - 持久化阻塞：AOF 重写或生成 RDB 快照的时候，fork 子进程会拷贝页表，内存越大 fork 越慢，这段时间主进程是卡死的 2. 解决方案 - 垂直扩容：看单机资源有没有用满，如果还有资源就加内存 - 读写分离：比如一主三从，读请求全部路由到从节点，QPS 直接翻 3 倍 - Redis 集群分片：数据量太大或者写请求压力大，就要使用分片集群，16384 个槽位分散到多个主节点，横向拓展写能力 - 多级缓存：加一层本地缓存（Caffeine/Guava Cache），热点数据放本地，减少向 Redis 请求的次数（本地缓存的时间调小一点，减小不一致的窗口期时间；如果对实时性要求高，可以使用发布订阅或者消息队列广播消息清空本地缓存） - 实际项目中这几种策略往往结合使用：读写分离+集群分片+多级缓存 - 对于 RDB 持久化的优化：控制内存大小增加 fork 的速度、使用混合持久化减少 RDB 的频率等 ## 3. Redis 中的内存碎片是什么，如何处理 1. Redis 默认使用 jemalloc 做内存分配器（在多线程环境下碎片率低，虽然 Redis 是单线程，但后台有 IO 线程和持久化线程，jemalloc 综合表现更好），按固定大小分配内存，比如实际只需要 8KB，分配器却给了 12KB，多出来的 4KB 就浪费了，这就是内存碎片 2. 并且经过频繁的创建、删除，内存块的大小和位置会变得不连续，碎片化越来越多 3. 可以通过查看操作系统层面 Redis 的内存（used_memory_rss）占用和 Redis 真实的内存（used_memory）占用计算出碎片率（used_memory_rss/used_memory）。一般来说 1-1.5 算正常；超过 1.5 就应该考虑清理一下；小于 1 说明 Redis 内存不够用，已经在进行 swap 了，性能大幅度下跌（物理内存不够，把内存数据暂时放到磁盘上，这块磁盘空间就叫做 swap） 4. 碎片整理的方案 1. 重启 Redis：最简单，重启后内存会重新分配，碎片自然就没了。但服务会中断，生产环境慎用 2. 使用 activedefrag 自动碎片整理：4.0 引入，会在运行时自动整理碎片，增量式处理，每次处理一小部分。但会消耗额外资源 ```bash # 开启自动碎片整理 activedefrag yes # 碎片占用的字节数超过 100MB 时才开始整理 active-defrag-ignore-bytes 100mb # 碎片率达到多少百分比才触发 active-defrag-threshold-lower 10 active-defrag-threshold-upper 100 # CPU 使用率控制，避免整理影响正常请求 active-defrag-cycle-min 1 active-defrag-cycle-max 25 ``` 3. 手动触发：手动执行`memory purge`，期间会阻塞主线程，生产环境慎用 5. 预防方案：让 key 的大小固定或接近；给 key 设置过期时间让 Redis 自己清理；7.0 版本将 ziplist 换成了 liskpack，内存利用率更高，从源头减少了碎片 # 第八部分 | 其他 ## 1. Redis 快的原因有哪些 1. 基于内存：访问内存的速度比访问 SSD 磁盘快了将近 1000 倍 2. 单线程+ IO 多路复用：Redis 采用单线程执行，没有锁竞争和上下文切换；采用多路复用，一个线程监听多个连接 3. 高效的数据结构：比如 String 底层是 SDS，O(1) 获取长度；Hash 小数据量用 listzip 省内存，大数据量用hashtable 保证 O(1) 查询；ZSe t使用跳表，插入查询都是 O(logN) 4. Redis 6.0 引入了多线程来处理网络 IO，命令执行还是单线程的 ## 2. Redis 的适用场景有哪些 1. 作缓存提升性能：常用 String 类型来存储用户信息、Session、查询结果，查询时直接操作内存，速度快 2. 作分布式锁解决并发问题：Redis 是单线程，天生能保证原子性，谁先拿到锁谁先执行。可以使用 Redis 的setnx 命令或者使用 Redisson 框架（使用 setnx 时需要注意锁要设置过期时间、用 set ex nx这种原子命令、释放锁要检查是不是自己的） 3. 作计数器与限流：比如阅读量、点赞数，如果让这些数据都去操作数据库，锁竞争太大了。Redis 基于内存，并且单线程原子性，incr 自增，性能高且不会算错 4. 作排行榜：需要获取实时排名的情况，用数据库会经常全表扫描，开销太大；Redis 中的 ZSet 数据类型，会自动进行排序（zadd/zrange） 5. 作消息队列：如果只是做简单的异步处理，或者其他原因不想单独引入 mq，就可以用 Redis 的 List 数据类型实现简单的任务队列（lpush/brpop）[Redis 5.0 引入了 Stream，支持消费者组、消息 ID、ACK 确认、消费失败重新处理] ## 3. Java 中有哪些 Redis 客户端 1. Jedis：同步阻塞、API 简单直接、线程不安全需要连接池 2. Lettuce：异步非阻塞、基于 Netty、线程安全可共享链接（SpringBoot 2.x 之后默认客户端） 3. Redisson：异步非阻塞、高级封装、提供分布式锁、限流器等开箱即用的组件（RLock 分布式锁、RReadWriteLock 读写锁、RSemaphore 信号量、RRateLimiter 限流器、RBloomFilter 布隆过滤器、RDelayedQueue 延迟队列） ## 4. 保证缓存和数据库一致性的方案有哪些 1. 先更新数据库，再删缓存：但有个临界问题，如果此时缓存刚好过期，且此次读操作慢于更新数据库删除缓存，那么旧数据又被写回缓存了，但这种情况出现概率极低 2. 缓存双删：先删缓存，再更新数据库，一段时间后再删缓存。解决“先删缓存，再更新数据库”的并发问题。但延迟时间不好确定 3. Binlog 异步更新：只写数据库，canal 伪装成数据库的从节点，订阅 binlog，解析出变更事件，发送到消息队列，由消费者负责删除缓存，这样即使失败了也能重试，可以保证最终一致性（但要保证顺序消费！幂等处理） 4. 强一致性方案：使用分布式读写锁，读读不互斥，读写/写写互斥，但会导致性能下降 ## 5. 聊一聊 Lua 脚本 1. Lua 脚本的特性：在Redis中是原子性的、减少网络往返次数、封装复杂操作等特性，超过了单个 Redis 命令的能力 2. 典型场景是分布式锁：在分布式锁场景下，释放锁前要判断锁是不是自己的，是的话再删除。由于判断和删除不是原子的，可能会误删别人的锁（比如刚判断完这个锁就过期了，另一个请求拿到锁，那么接下来删除的就是新请求的锁了），Lua 脚本把判断和删除放在一起，解决了这个问题 3. 在 Redis 中还有预加载功能：如果每次执行都要把完整的脚本发给 Redis，脚本传输会有网络开销，因此可以先把脚本缓存到 Redis，返回一个 sha1 哈希值，以后直接发送哈希值就行，省掉脚本内容传输的开销，生产环境建议使用这种方式（注意 Redis 重启后脚本缓存会丢失，所以要在代码里处理对应错误，重新加载一次） 4. Lua 脚本超时逻辑：默认 5s 超时，超时后不会立刻停止，而是接受客户端的 kill 命令，如果脚本还没执行写操作，会直接终止掉；如果已经写了一部分，再想停止，只能重启 Redis。所以 Lua 脚本不要太复杂 ## 6. 如何使用 Redis 实现布隆过滤器 1. 布隆过滤器用于判断某个元素存不存在，可能会误判，但只会误判存在的，不存在就一定不存在。实现方式主要有两种，一种是位图手动实现，另一种是用官方的 RedisBloom 模块 - 位图手动实现：自己管理哈希函数和位数组，主要通过 Redis 的 setbit/getbit 命令，将位置设为 1 或者获取对应位置的值 - RedisBloom：官方提供，只需要指定误判率和容量，自动算出最优的位数组大小和哈希函数个数；支持 Cuckoo Filter 用来删除；支持动态扩容 2. 本质：由一个位数组和多个哈希函数组成。添加元素时通过 k 个哈希函数计算出 k 个位置，将这些位置设为 1；查询时同样使用 k 哈希函数计算 k 个位置，如果全为 1 则可能存在，有一个为 0 一定不存在 3. 还有一点就是布隆过滤器是单向的，只能新增不能删除。因为位数组里某个位可能是多个元素共同设置的，如果为了一个元素变更状态，其他元素也会收到影响。当然后续也出现了很多变种，允许删除 4. 适用于数据量大、允许误判、只需判断存在性的场景：缓存击穿、垃圾邮件过滤、推荐系统去重 ## 7. 说一下 Redis 的哨兵机制 1. 使用 Redis sentinel 来对 Reids 主从进行监控、故障转移、通知；此时客户端会先向哨兵询问主节点的地址，拿到地址后再去连接 Redis 2. 奇数个(>=3)哨兵组成一个集群，可以相互通信，每个哨兵监控所有 Reids 的状态 3. 哨兵判断节点下线分为两步，主观下线和客观下线。每个哨兵每隔 1s 向所有 Redis 发送 ping，如果指定时间没收到 pong，则这个哨兵会认为该节点主观下线。如果是主节点，为了避免是因为网络抖动而未收到响应，这时这个哨兵会向其他哨兵询问并投票，如果票数达到指定值，则会认为主节点客观下线，开始走故障转移流程（这个值一般配置为哨兵总数/2+1） 4. 确定主节点客观下线了，会选出一个哨兵来主持故障转移，选举策略是：第一个发现主节点挂掉的哨兵先投自己一票，然后让其他哨兵投票，每个哨兵只有一票，并且谁先来就投谁，候选者拿到一半以上的票就成为Leader（可能会出现同票的情况，那么过一段时间会重新投票，所以最好哨兵设置为奇数个） 5. 然后选举主节点，哨兵 Leader 会从剩下的从节点选出一个来当主节点，选举策略是：先看优先级（0 表示不参选，值越小优先级越高），优先级相同就选 offset 大的那个，offset 还相同就选 runid 最小的那个 6. 最后 Leader 哨兵会给新主节点发送`slavof no one`成为主节点，给其他从节点发送新节点 IP 和端口，与新节点同步。如果原来的主节点恢复了，也是成为新主节点的从节点

redis笔记2