Redis - Redis常见问题总结 - 《Java 后端知识点总结》

1. 简单介绍一下Redis
2. 分布式缓存常见的技术选型方案有哪些？
3. 说一下Redis和Memcached的区别和共同点？
4. 缓存数据的处理流程
5. 为什么要用Redis/为什么要用缓存？
6. Redis常见数据结构及应用场景分析
7. Redis单线程模型讲解
8. Redis没有使用多线程？为什么不使用多线程？
9. Redis 6.0为什么要引入多线程呢？
10. Redis 6.0是否默认开启多线程？
11. Redis给缓存数据设置过期时间有什么用？
12. Redis是如何判断数据是否过期的呢？
13. 过期的数据的删除策略了解吗？
14. Redis内存淘汰机制了解吗？
15. Redis持久化机制(怎么保证Redis挂掉后再重启数据可以进行恢复)
16. Redis事务
17. 缓存穿透
- 17.1 什么是缓存穿透？
- 17.2 解决办法
18. 缓存雪崩
- 18.1 什么是缓存雪崩？
- 18.2 解决办法
19. Redis中的LRU算法

1. 简单介绍一下Redis

Redis 就是一个使用 C 语言开发的数据库，不过与传统数据库不同的是 Redis 的数据是存在内存中的 ，也就是它是内存数据库，所以读写速度非常快，因此 Redis 被广泛应用于缓存方向。
另外，Redis 除了做缓存之外，Redis 也经常用来做分布式锁，甚至是消息队列。Redis 提供了多种数据类型来支持不同的业务场景。Redis 还支持事务、持久化、Lua 脚本、多种集群方案。

2. 分布式缓存常见的技术选型方案有哪些？

分布式缓存的话，使用的比较多的主要是 Memcached 和 Redis。Memcached 是分布式缓存最开始兴起的那会，比较常用的。后来，随着 Redis 的发展，大家慢慢都转而使用更加强大的 Redis 了。分布式缓存主要解决的是单机缓存的容量受服务器限制并且无法保存通用的信息。因为，本地缓存只在当前服务里有效，比如如果你部署了两个相同的服务，他们两者之间的缓存数据是无法共通的。

3. 说一下Redis和Memcached的区别和共同点？

共同点 ：

都是基于内存的数据库，一般都用来当做缓存使用。
都有过期策略。
两者的性能都非常高。

区别：

Redis 支持更丰富的数据类型（支持更复杂的应用场景）。Redis 不仅仅支持简单的 k/v 类型的数据，同时还提供 list，set，zset，hash 等数据结构的存储。Memcached 只支持最简单的 k/v 数据类型。
Redis 支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用，而 Memecache 把数据全部存在内存之中。
Redis 有灾难恢复机制。 因为可以把缓存中的数据持久化到磁盘上。
Redis 在服务器内存使用完之后，可以将不用的数据放到磁盘上。但是，Memcached 在服务器内存使用完之后，就会直接报异常。
Memcached 没有原生的集群模式，需要依靠客户端来实现往集群中分片写入数据；但是 Redis 目前是原生支持 cluster 模式的.
Memcached 是多线程，非阻塞 IO 复用的网络模型；Redis 使用单线程的多路 IO 复用模型。（Redis 6.0 引入了多线程 IO ）
Redis 支持发布订阅模型、Lua 脚本、事务等功能，而 Memcached 不支持。并且，Redis 支持更多的编程语言。
Memcached 过期数据的删除策略只用了惰性删除，而 Redis 同时使用了惰性删除与定期删除。
4. 缓存数据的处理流程

简单来说就是:

如果用户请求的数据在缓存中就直接返回。
缓存中不存在的话就看数据库中是否存在。
数据库中存在的话就更新缓存中的数据。
数据库中不存在的话就返回空数据。
5. 为什么要用Redis/为什么要用缓存？
主要从“高性能”和“高并发”来看待这个问题：

高性能

假设用户第一次访问数据库中的某些数据的话，这个过程是比较慢的，毕竟是从内盘中读取。但是如果说，用户访问的数据属于高频数据并且不会经常改变的话，我们就可以放心地将该用户访问的数据放在缓存中。
这样有什么好处呢？那就是保证用户下一次再访问这些数据的时候就可以直接从缓存中获取了。操作缓存就是直接操作内存，所以速度相当快。不过，要保持数据库和缓存中的数据的一致性。如果数据库中的对应数据改变的之后，同步改变缓存中相应的数据即可！

高并发

一般像 MySQL 这类的数据库的 QPS(query for second) 大概都在 1w 左右（4 核 8g），但是使用 Redis 缓存之后很容易达到 10w+，甚至最高能达到 30w+（就单机 redis 的情况，redis 集群的话会更高）。所以，直接操作缓存能够承受的数据库请求数量是远远大于直接访问数据库的，所以我们可以考虑把数据库中的部分数据转移到缓存中去，这样用户的一部分请求会直接到缓存这里而不用经过数据库。进而，我们也就提高的系统整体的并发。

6. Redis常见数据结构及应用场景分析

6.1 string

介绍：string 数据结构是简单的 key-value 类型。虽然 Redis 是用 C 语言写的，但是 Redis 并没有使用 C 的字符串表示，而是自己构建了一种 简单动态字符串（simple dynamic string，SDS）。相比于 C 的原生字符串，Redis 的 SDS 不光可以保存文本数据还可以保存二进制数据，并且获取字符串长度复杂度为 O(1)（C 字符串为 O(N)）,除此之外,Redis 的 SDS API 是安全的，不会造成缓冲区溢出。
常用命令：set,get,strlen,exists,decr,incr,setex 等等。
应用场景 ：一般常用在需要计数的场景，比如用户的访问次数、热点文章的点赞转发数量等等。

普通字符串的基本操作：

127.0.0.1:6379> set key value #设置 key-value 类型的值
OK
127.0.0.1:6379> get key # 根据 key 获得对应的 value
"value"
127.0.0.1:6379> exists key  # 判断某个 key 是否存在
(integer) 1
127.0.0.1:6379> strlen key # 返回 key 所储存的字符串值的长度。
(integer) 5
127.0.0.1:6379> del key # 删除某个 key 对应的值
(integer) 1
127.0.0.1:6379> get key
(nil)

批量设置：

127.0.0.1:6379> mset key1 value1 key2 value2 # 批量设置 key-value 类型的值
OK
127.0.0.1:6379> mget key1 key2 # 批量获取多个 key 对应的 value
1) "value1"
2) "value2"

计数器（字符串的内容为整数的时候可以使用）：

127.0.0.1:6379> set number 1
OK
127.0.0.1:6379> incr number # 将 key 中储存的数字值增一
(integer) 2
127.0.0.1:6379> get number
"2"
127.0.0.1:6379> decr number # 将 key 中储存的数字值减一
(integer) 1
127.0.0.1:6379> get number
"1"

过期：

127.0.0.1:6379> expire key  60 # 数据在 60s 后过期
(integer) 1
127.0.0.1:6379> setex key 60 value # 数据在 60s 后过期 (setex:[set] + [ex]pire)
OK
127.0.0.1:6379> ttl key # 查看数据还有多久过期
(integer) 56

6.2 list

介绍：list 即是链表。链表是一种非常常见的数据结构，特点是易于数据元素的插入和删除并且且可以灵活调整链表长度，但是链表的随机访问困难。许多高级编程语言都内置了链表的实现比如 Java 中的 LinkedList，但是 C 语言并没有实现链表，所以 Redis 实现了自己的链表数据结构。Redis 的 list 的实现为一个 双向链表，即可以支持反向查找和遍历，更方便操作，不过带来了部分额外的内存开销。
常用命令：rpush、lpop、lpush、rpop、lrange、llen 等。
应用场景：发布与订阅或者说消息队列、慢查询。

通过 rpush/lpop 实现队列：

127.0.0.1:6379> rpush myList value1 # 向 list 的头部（右边）添加元素
(integer) 1
127.0.0.1:6379> rpush myList value2 value3 # 向list的头部（最右边）添加多个元素
(integer) 3
127.0.0.1:6379> lpop myList # 将 list的尾部(最左边)元素取出
"value1"
127.0.0.1:6379> lrange myList 0 1 # 查看对应下标的list列表， 0 为 start,1为 end
1) "value2"
2) "value3"
127.0.0.1:6379> lrange myList 0 -1 # 查看列表中的所有元素，-1表示倒数第一
1) "value2"
2) "value3"

通过 rpush/rpop 实现栈：

127.0.0.1:6379> rpush myList2 value1 value2 value3
(integer) 3
127.0.0.1:6379> rpop myList2 # 将 list的头部(最右边)元素取出
"value3"

Redis常见问题总结 - 图3
通过 llen 查看链表长度：

127.0.0.1:6379> llen myList
(integer) 3

6.3 hash

介绍：hash 类似于 JDK1.8 前的 HashMap，内部实现也差不多(数组 + 链表)。不过，Redis 的 hash 做了更多优化。另外，hash 是一个 string 类型的 field 和 value 的映射表，特别适合用于存储对象，后续操作的时候，你可以直接仅仅修改这个对象中的某个字段的值。比如我们可以 hash 数据结构来存储用户信息，商品信息等等。
常用命令： hset,hmset,hexists,hget,hgetall,hkeys,hvals 等。

应用场景: 系统中对象数据的存储。

127.0.0.1:6379> hmset userInfoKey name "xkd" description "dev" age "24"
OK
127.0.0.1:6379> hexists userInfoKey name # 查看 key 对应的 value中指定的字段是否存在。
(integer) 1
127.0.0.1:6379> hget userInfoKey name # 获取存储在哈希表中指定字段的值。
"xkd"
127.0.0.1:6379> hget userInfoKey age
"24"
127.0.0.1:6379> hgetall userInfoKey # 获取在哈希表中指定 key 的所有字段和值
1) "name"
2) "xkde"
3) "description"
4) "dev"
5) "age"
6) "24"
127.0.0.1:6379> hkeys userInfoKey # 获取 key 列表
1) "name"
2) "description"
3) "age"
127.0.0.1:6379> hvals userInfoKey # 获取 value 列表
1) "guide"
2) "dev"
3) "24"
127.0.0.1:6379> hset userInfoKey name "xkdjava" # 修改某个字段对应的值
127.0.0.1:6379> hget userInfoKey name
"xkdjava"

6.4 set

介绍： set 类似于 Java 中的 HashSet 。Redis 中的 set 类型是一种无序集合，集合中的元素没有先后顺序。当你需要存储一个列表数据，又不希望出现重复数据时，set 是一个很好的选择，并且 set 提供了判断某个成员是否在一个 set 集合内的重要接口，这个也是 list 所不能提供的。可以基于 set 轻易实现交集、并集、差集的操作。比如：你可以将一个用户所有的关注人存在一个集合中，将其所有粉丝存在一个集合。Redis 可以非常方便的实现如共同关注、共同粉丝、共同喜好等功能。这个过程也就是求交集的过程。
常用命令： sadd、spop、smembers、sismember、scard、sinterstore、sunion 等。

应用场景: 需要存放的数据不能重复以及需要获取多个数据源交集和并集等场景

127.0.0.1:6379> sadd mySet value1 value2 # 添加元素进去
(integer) 2
127.0.0.1:6379> sadd mySet value1 # 不允许有重复元素
(integer) 0
127.0.0.1:6379> smembers mySet # 查看 set 中所有的元素
1) "value1"
2) "value2"
127.0.0.1:6379> scard mySet # 查看 set 的长度
(integer) 2
127.0.0.1:6379> sismember mySet value1 # 检查某个元素是否存在set 中，只能接收单个元素
(integer) 1
127.0.0.1:6379> sadd mySet2 value2 value3
(integer) 2
127.0.0.1:6379> sinterstore mySet3 mySet mySet2 # 获取 mySet 和 mySet2 的交集并存放在 mySet3 中
(integer) 1
127.0.0.1:6379> smembers mySet3
1) "value2"

6.5 sorted set

介绍： 和 set 相比，sorted set 增加了一个权重参数 score，使得集合中的元素能够按 score 进行有序排列，还可以通过 score 的范围来获取元素的列表。有点像是 Java 中 HashMap 和 TreeSet 的结合体。
常用命令： zadd、zcard、zscore、zrange、zrevrange、zrem 等。

应用场景： 需要对数据根据某个权重进行排序的场景。比如在直播系统中，实时排行信息包含直播间在线用户列表，各种礼物排行榜，弹幕消息（可以理解为按消息维度的消息排行榜）等信息。

127.0.0.1:6379> zadd myZset 3.0 value1 # 添加元素到 sorted set 中 3.0 为权重
(integer) 1
127.0.0.1:6379> zadd myZset 2.0 value2 1.0 value3 # 一次添加多个元素
(integer) 2
127.0.0.1:6379> zcard myZset # 查看 sorted set 中的元素数量
(integer) 3
127.0.0.1:6379> zscore myZset value1 # 查看某个 value 的权重
"3"
127.0.0.1:6379> zrange  myZset 0 -1 # 顺序输出某个范围区间的元素，0 -1 表示输出所有元素
1) "value3"
2) "value2"
3) "value1"
127.0.0.1:6379> zrange  myZset 0 1 # 顺序输出某个范围区间的元素，0 为 start  1 为 stop
1) "value3"
2) "value2"
127.0.0.1:6379> zrevrange  myZset 0 1 # 逆序输出某个范围区间的元素，0 为 start  1 为 stop
1) "value1"
2) "value2"

6.6 bitmap

介绍：bitmap 存储的是连续的二进制数字（0 和 1），通过 bitmap, 只需要一个 bit 位来表示某个元素对应的值或者状态，key 就是对应元素本身。我们知道 8 个 bit 可以组成一个 byte，所以 bitmap 本身会极大的节省储存空间。
常用命令： setbit 、getbit 、bitcount、bitop
应用场景: 适合需要保存状态信息（比如是否签到、是否登录…）并需要进一步对这些信息进行分析的场景。比如用户签到情况、活跃用户情况、用户行为统计（比如是否点赞过某个视频）。
```
# SETBIT 会返回之前位的值（默认是 0）这里会生成 7 个位
127.0.0.1:6379> setbit mykey 7 1
(integer) 0
127.0.0.1:6379> setbit mykey 7 0
(integer) 1
127.0.0.1:6379> getbit mykey 7
(integer) 0
127.0.0.1:6379> setbit mykey 6 1
(integer) 0
127.0.0.1:6379> setbit mykey 8 1
(integer) 0
# 通过 bitcount 统计被被设置为 1 的位的数量。
127.0.0.1:6379> bitcount mykey
(integer) 2
```
7. Redis单线程模型讲解
Redis 基于 Reactor 模式来设计开发了自己的一套高效的事件处理模型 （Netty 的线程模型也基于 Reactor 模式，Reactor 模式不愧是高性能 IO 的基石），这套事件处理模型对应的是 Redis 中的文件事件处理器（file event handler）。由于文件事件处理器（file event handler）是单线程方式运行的，所以我们一般都说 Redis 是单线程模型。
既然是单线程，那怎么监听大量的客户端连接呢？
Redis 通过IO 多路复用程序 来监听来自客户端的大量连接（或者说是监听多个 socket），它会将感兴趣的事件及类型(读、写）注册到内核中并监听每个事件是否发生。
这样的好处非常明显： I/O 多路复用技术的使用让 Redis 不需要额外创建多余的线程来监听客户端的大量连接，降低了资源的消耗（和 NIO 中的 Selector 组件很像）。
另外， Redis 服务器是一个事件驱动程序，服务器需要处理两类事件： 1. 文件事件; 2. 时间事件。时间事件不需要多花时间了解，我们接触最多的还是 文件事件（客户端进行读取写入等操作，涉及一系列网络通信）。

Redis 基于 Reactor 模式开发了自己的网络事件处理器：这个处理器被称为文件事件处理器（file event handler）。文件事件处理器使用 I/O 多路复用（multiplexing）程序来同时监听多个套接字，并根据套接字目前执行的任务来为套接字关联不同的事件处理器。当被监听的套接字准备好执行连接应答（accept）、读取（read）、写入（write）、关闭（close）等操作时，与操作相对应的文件事件就会产生，这时文件事件处理器就会调用套接字之前关联好的事件处理器来处理这些事件。虽然文件事件处理器以单线程方式运行，但通过使用 I/O 多路复用程序来监听多个套接字，文件事件处理器既实现了高性能的网络通信模型，又可以很好地与 Redis 服务器中其他同样以单线程方式运行的模块进行对接，这保持了 Redis 内部单线程设计的简单性。

可以看出，文件事件处理器（file event handler）主要是包含 4 个部分：

多个 socket（客户端连接）
IO 多路复用程序（支持多个客户端连接的关键）
文件事件分派器（将 socket 关联到相应的事件处理器）
事件处理器（连接应答处理器、命令请求处理器、命令回复处理器）

Redis常见问题总结 - 图4

8. Redis没有使用多线程？为什么不使用多线程？

一般来说 Redis 的瓶颈并不在 CPU，而在内存和网络。如果要使用 CPU 多核，可以搭建多个 Redis 实例来解决。
其实，Redis 4.0 开始就有多线程的概念了，比如 Redis 通过多线程方式在后台删除对象、以及通过 Redis 模块实现的阻塞命令等。
使用了单线程后，可维护性高。多线程模型虽然在某些方面表现优异，但是它却引入了程序执行顺序的不确定性，带来了并发读写的一系列问题，增加了系统复杂度、同时可能存在线程切换、甚至加锁解锁、死锁造成的性能损耗。Redis 通过 AE 事件模型以及 IO 多路复用等技术，处理性能非常高，因此没有必要使用多线程。单线程机制使得 Redis 内部实现的复杂度大大降低，Hash 的惰性 Rehash、Lpush 等等 “线程不安全” 的命令都可以无锁进行。

9. Redis 6.0为什么要引入多线程呢？

之前的段落说了，Redis 的瓶颈并不在 CPU，而在内存和网络。
内存不够的话，可以加内存或者做数据结构优化和其他优化等，但网络的性能优化才是大头，网络 IO 的读写在 Redis 整个执行期间占用了大部分的 CPU 时间，如果把网络处理这部分做成多线程处理方式，那对整个 Redis 的性能会有很大的提升。
优化方向：

提高网络 IO 性能，典型的实现比如使用 DPDK 来替代内核网络栈的方式。
使用多线程充分利用多核，典型的实现比如 Memcached。

所以总结起来，Redis 支持多线程主要就是两个原因：

可以充分利用服务器 CPU 资源，目前主线程只能利用一个核。
多线程任务可以分摊 Redis 同步 IO 读写负荷。

10. Redis 6.0是否默认开启多线程？
否，在redis.conf文件进行配置：
```
io-threads-do-reads yes
```
开启多线程后，还需要设置线程数，否则是不生效的。同样需要修改 redis 配置文件 redis.conf：
```
io-threads 4
```
官方建议：4 核的机器建议设置为 2 或 3 个线程，8 核的建议设置为 6 个线程，线程数一定要小于机器核数，尽量不超过8个。

11. Redis给缓存数据设置过期时间有什么用？
一般情况下，我们设置保存的缓存数据的时候都会设置一个过期时间。为什么呢？
因为内存是有限的，如果缓存中的所有数据都是一直保存的话，分分钟直接 Out of memory。Redis 自带了给缓存数据设置过期时间的功能，比如：
```
127.0.0.1:6379> exp key  60 # 数据在 60s 后过期
(integer) 1
127.0.0.1:6379> setex key 60 value # 数据在 60s 后过期 (setex:[set] + [ex]pire)
OK
127.0.0.1:6379> ttl key # 查看数据还有多久过期
(integer) 56
```
注意：Redis 中除了字符串类型有自己独有设置过期时间的命令 setex 外，其他方法都需要依靠 expire 命令来设置过期时间。另外， persist 命令可以移除一个键的过期时间
过期时间除了有助于缓解内存的消耗，还有什么其他用么？
很多时候，我们的业务场景就是需要某个数据只在某一时间段内存在，比如我们的短信验证码可能只在 1 分钟内有效，用户登录的 token 可能只在 1 天内有效。
如果使用传统的数据库来处理的话，一般都是自己判断过期，这样更麻烦并且性能要差很多。

12. Redis是如何判断数据是否过期的呢？
Redis 通过一个叫做过期字典（可以看作是 hash 表）来保存数据过期的时间。过期字典的键指向 Redis 数据库中的某个 key(键)，过期字典的值是一个 long long 类型的整数，这个整数保存了 key 所指向的数据库键的过期时间（毫秒精度的 UNIX 时间戳）。

过期字典是存储在 redisDb 这个结构里的：
```
typedef struct redisDb {
  ...
  dict *dict;     //数据库键空间,保存着数据库中所有键值对
  dict *expires   // 过期字典,保存着键的过期时间
  ...
} redisDb;
```
13. 过期的数据的删除策略了解吗？
如果假设你设置了一批 key 只能存活 1 分钟，那么 1 分钟后，Redis 是怎么对这批 key 进行删除的呢？常用的过期数据的删除策略就两个：

惰性删除：只会在取出 key 的时候才对数据进行过期检查。这样对 CPU 最友好，但是可能会造成太多过期 key 没有被删除。
定期删除 ：每隔一段时间抽取一批 key 执行删除过期 key 操作。并且，Redis 底层会通过限制删除操作执行的时长和频率来减少删除操作对 CPU 时间的影响。

定期删除对内存更加友好，惰性删除对 CPU 更加友好。两者各有千秋，所以 Redis 采用的是 定期删除+惰性/懒汉式删除。但是，仅仅通过给 key 设置过期时间还是有问题的。因为还是可能存在定期删除和惰性删除漏掉了很多过期 key 的情况。这样就导致大量过期 key 堆积在内存里，然后就 Out of memory 了。
怎么解决这个问题呢？答案就是：Redis内存淘汰机制。

14. Redis内存淘汰机制了解吗？

相关问题：MySQL 里有 2000w 数据，Redis 中只存 20w 的数据，如何保证 Redis 中的数据都是热点数据?

Redis 提供 6 种数据淘汰策略：

volatile-lru（least recently used）：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰
volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰
volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰
allkeys-lru（least recently used）：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的 key（这个是最常用的）
allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰
no-eviction：禁止驱逐数据，也就是说当内存不足以容纳新写入数据时，新写入操作会报错。这个应该没人使用吧！

4.0 版本后增加以下两种：

volatile-lfu（least frequently used）：从已设置过期时间的数据集(server.db[i].expires)中挑选最不经常使用的数据淘汰
allkeys-lfu（least frequently used）：当内存不足以容纳新写入数据时，在键空间中，移除最不经常使用的 key
15. Redis持久化机制(怎么保证Redis挂掉后再重启数据可以进行恢复)
很多时候我们需要持久化数据也就是将内存中的数据写入到硬盘里面，大部分原因是为了之后重用数据（比如重启机器、机器故障之后恢复数据），或者是为了防止系统故障而将数据备份到一个远程位置。
Redis 不同于 Memcached 的很重要一点就是，Redis 支持持久化，而且支持两种不同的持久化操作。Redis 的一种持久化方式叫快照（snapshotting，RDB），另一种方式是只追加文件（append-only file, AOF）。这两种方法各有千秋，下面我会详细这两种持久化方法是什么，怎么用，如何选择适合自己的持久化方法。

快照（snapshotting）持久化（RDB）

Redis 可以通过创建快照来获得存储在内存里面的数据在某个时间点上的副本。Redis 创建快照之后，可以对快照进行备份，可以将快照复制到其他服务器从而创建具有相同数据的服务器副本（Redis 主从结构，主要用来提高 Redis 性能），还可以将快照留在原地以便重启服务器的时候使用。
快照持久化是 Redis 默认采用的持久化方式，在 Redis.conf 配置文件中默认有此下配置：

save 900 1           #在900秒(15分钟)之后，如果至少有1个key发生变化，Redis就会自动触发BGSAVE命令创建快照。
save 300 10          #在300秒(5分钟)之后，如果至少有10个key发生变化，Redis就会自动触发BGSAVE命令创建快照。
save 60 10000        #在60秒(1分钟)之后，如果至少有10000个key发生变化，Redis就会自动触发BGSAVE命令创建快照。

AOF(append-only file)持久化

与快照持久化相比，AOF 持久化的实时性更好，因此已成为主流的持久化方案。默认情况下 Redis 没有开启 AOF（append only file）方式的持久化，可以通过 appendonly 参数开启：

appendonly yes

开启 AOF 持久化后每执行一条会更改 Redis 中的数据的命令，Redis 就会将该命令写入硬盘中的 AOF 文件。AOF 文件的保存位置和 RDB 文件的位置相同，都是通过 dir 参数设置的，默认的文件名是 appendonly.aof。
在 Redis 的配置文件中存在三种不同的 AOF 持久化方式，它们分别是：

appendfsync always    #每次有数据修改发生时都会写入AOF文件,这样会严重降低Redis的速度
appendfsync everysec  #每秒钟同步一次，显示地将多个写命令同步到硬盘
appendfsync no        #让操作系统决定何时进行同步

为了兼顾数据和写入性能，用户可以考虑 appendfsync everysec 选项，让 Redis 每秒同步一次 AOF 文件，Redis 性能几乎没受到任何影响。而且这样即使出现系统崩溃，用户最多只会丢失一秒之内产生的数据。当硬盘忙于执行写入操作的时候，Redis 还会优雅的放慢自己的速度以便适应硬盘的最大写入速度。
写的很好的一篇文章：https://blog.csdn.net/ll594317566/article/details/109215575

16. Redis事务

Redis 可以通过 MULTI，EXEC，DISCARD 和 WATCH 等命令来实现事务(transaction)功能。
使用 MULTI命令后可以输入多个命令。Redis 不会立即执行这些命令，而是将它们放到队列，当调用了EXEC命令将执行所有命令。
这个过程是这样的：

开始事务（MULTI）。
命令入队(批量操作 Redis 的命令，先进先出（FIFO）的顺序执行)。
执行事务(EXEC)。

你也可以通过 DISCARD 命令取消一个事务，它会清空事务队列中保存的所有命令。
WATCH 命令用于监听指定的键，当调用 EXEC 命令执行事务时，如果一个被 WATCH 命令监视的键被修改的话，整个事务都不会执行，直接返回失败。
Redis 官网相关介绍 https://redis.io/topics/transactions 如下：
Redis常见问题总结 - 图6
但是，Redis 的事务和我们平时理解的关系型数据库的事务不同。我们知道事务具有四大特性：1. 原子性，2. 隔离性，3. 持久性，4. 一致性。

原子性（Atomicity）： 事务是最小的执行单位，不允许分割。事务的原子性确保动作要么全部完成，要么完全不起作用；
隔离性（Isolation）： 并发访问数据库时，一个用户的事务不被其他事务所干扰，各并发事务之间数据库是独立的；
持久性（Durability）： 一个事务被提交之后。它对数据库中数据的改变是持久的，即使数据库发生故障也不应该对其有任何影响。
一致性（Consistency）： 执行事务前后，数据保持一致，多个事务对同一个数据读取的结果是相同的；

Redis 是不支持 roll back 的，因而不满足原子性的（而且不满足持久性）。
Redis 官网也解释了自己为啥不支持回滚。简单来说就是 Redis 开发者们觉得没必要支持回滚，这样更简单便捷并且性能更好。Redis 开发者觉得即使命令执行错误也应该在开发过程中就被发现而不是生产过程中。
Redis常见问题总结 - 图7
你可以将 Redis 中的事务就理解为：Redis 事务提供了一种将多个命令请求打包的功能。然后，再按顺序执行打包的所有命令，并且不会被中途打断。

17. 缓存穿透

17.1 什么是缓存穿透？

缓存穿透说简单点就是大量请求的 key 根本不存在于缓存中，导致请求直接到了数据库上，根本没有经过缓存这一层。举个例子：某个黑客故意制造我们缓存中不存在的 key 发起大量请求，导致大量请求落到数据库。
这里需要注意和缓存击穿的区别，缓存击穿，是指一个key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个屏障上凿开了一个洞。

17.2 解决办法

布隆过滤器

布隆过滤器（Bloom Filter）是1970年由布隆提出的。它实际上是一个很长的二进制向量和一系列随机映射函数。布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难。
基本概念：
如果想判断一个元素是不是在一个集合里，一般想到的是将集合中所有元素保存起来，然后通过比较确定。链表、树、散列表（又叫哈希表，Hash table）等等数据结构都是这种思路。但是随着集合中元素的增加，我们需要的存储空间越来越大。同时检索速度也越来越慢，上述三种结构的检索时间复杂度分别为：O(n)，O(log n)，O(1)。
布隆过滤器的原理是，当一个元素被加入集合时，通过K个Hash函数将这个元素映射成一个位数组中的K个点，把它们置为1。检索时，我们只要看看这些点是不是都是1就（大约）知道集合中有没有它了：如果这些点有任何一个0，则被检元素一定不在；如果都是1，则被检元素很可能在。这就是布隆过滤器的基本思想。
Redis常见问题总结 - 图8
Redis常见问题总结 - 图9
那这个布隆过滤器是如何解决redis中的缓存穿透呢？很简单首先也是对所有可能查询的参数以hash形式存储，当用户想要查询的时候，使用布隆过滤器发现不在集合中，就直接丢弃，不再对持久层查询。加入布隆过滤器后的缓存处理流程图如下：
Redis常见问题总结 - 图10

但是，需要注意的是布隆过滤器可能会存在误判的情况。总结来说就是： 布隆过滤器说某个元素存在，小概率会误判。布隆过滤器说某个元素不在，那么这个元素一定不在。
为什么会出现误判的情况呢? 我们还要从布隆过滤器的原理来说！
我们先来看一下，当一个元素加入布隆过滤器中的时候，会进行哪些操作：

使用布隆过滤器中的哈希函数对元素值进行计算，得到哈希值（有几个哈希函数得到几个哈希值）。
根据得到的哈希值，在位数组中把对应下标的值置为 1。

我们再来看一下，当我们需要判断一个元素是否存在于布隆过滤器的时候，会进行哪些操作：

对给定元素再次进行相同的哈希计算；
得到值之后判断位数组中的每个元素是否都为 1，如果值都为 1，那么说明这个值在布隆过滤器中，如果存在一个值不为 1，说明该元素不在布隆过滤器中。

然后，一定会出现这样一种情况：不同的字符串可能哈希出来的位置相同。 （可以适当增加位数组大小或者调整我们的哈希函数来降低概率）

18. 缓存雪崩

18.1 什么是缓存雪崩？

缓存雪崩是指缓存中数据大批量到过期时间，而查询数据量巨大，引起数据库压力过大甚至down机。和缓存击穿不同的是，缓存击穿指并发查同一条数据，缓存雪崩是不同数据都过期了，很多数据都差不大从而查数据库。

18.2 解决办法

针对Redis服务不可用的情况：
- 采用Redis集群，避免单机出现问题整个缓存服务都没办法使用
- 限流，避免同时处理大量的请求
针对热点缓存失效的情况：
- 设置不同的失效时间比如随即设置缓存的失效时间
- 缓存永不失效
  19. Redis中的LRU算法
  
  翻译自：https://redis.io/topics/lru-cache

当Redis被用作缓存时，当你添加新数据时，让它自动清除旧数据通常是很方便的。这种行为在开发人员社区中非常有名，因为它是流行的memcached系统的默认行为。
LRU(Least Recently Used)实际上只是支持的驱逐方法之一。这个页面涵盖了更一般的主题，Redis maxmemory指令是用来限制内存使用到一个固定的数量，它也涵盖了深入的LRU算法使用的Redis，这实际上是一个精确的LRU的近似。
从Redis 4.0版本开始，引入了一个新的LFU(Least Frequently Used)回收策略。

- Maxmemory 配置指令

maxmemory配置指令用于配置Redis为数据集使用指定数量的内存。可以使用redis.conf文件设置配置指令，或者稍后在运行时使用CONFIG SET命令。
例如，为了配置100兆字节的内存限制，可以在redis.conf文件中使用以下指令：

maxmemory 100mb

将maxmemory设置为0将导致没有内存限制。这是64位系统的默认行为，而32位系统使用隐式内存限制3GB。
当达到指定的内存量时，可以在称为策略(policies)的不同行为中进行选择。Redis可以返回导致更多的内存被使用的错误命令，或者每次新数据被添加时，它可以移除一些旧的数据，以便返回到指定的限制。

- Evicition policies

当达到maxmemory限制时，Redis遵循的确切行为是使用maxmemory-policy配置指令配置的。
有以下策略可以选择：

noeviction: 当达到内存限制，客户端试图执行可能导致使用更多内存的命令时返回错误(大多数写命令，除了DEL)。
allkeys-lru: 首先尝试删除最近使用较少的(LRU)键，以便为添加的新数据腾出空间。
volatile-lru: 首先尝试删除最近使用较少的(LRU)键，但只在有过期设置的键之间删除，以便为添加的新数据腾出空间。
allkeys-random: 为了给添加的新数据腾出空间，随机地清除键。
volatile-random: 为了为添加的新数据腾出空间，随机地取消键，但只取消设置了过期的键。
volatile-ttl: 删除设置了过期时间的键，并首先尝试删除生存时间较短的键，以便为添加的新数据腾出空间。

如果没有合适的key，volatile-lru、volatile-random、volatile-ttl表现和noeviction相同。
根据应用程序的访问模式选择正确的回收策略是很重要的，但是你可以在应用程序运行时重新配置策略，并使用Redis INFO输出监控缓存错过和命中的数量，以调整你的设置。
按经验来说：

当您希望请求的受欢迎程度呈幂律分布时，即希望访问元素子集的频率远高于其他元素时，请使用allkeys-lru策略。如果你不确定，这是一个很好的选择。
如果您有一个循环访问，其中所有的键都是连续扫描的，或者当您希望分布是均匀的(所有元素可能以相同的概率访问)，则使用allkeys-random。
如果你想通过使用不同的过期时间向Redis提供关于过期的合适候选，使用volatile-ttl

volatile-lru和volatile-random策略在希望使用单个实例进行缓存并拥有一组持久键时非常有用。然而，运行两个Redis实例来解决这样的问题通常是一个更好的主意。
另外值得注意的是，为键设置过期时间会消耗内存，因此使用allkeys-lru这样的策略会更有效地利用内存。

- 淘汰机制实现流程

淘汰流程如下：

客户端运行一个新命令，导致添加更多数据。
Redis检查内存使用情况，如果大于maxmemory限制，则根据策略收回键。
执行一个新命令，等等。

我们不断地跨越内存限制的边界，通过越过它，然后通过淘汰键返回到限制下。如果一个命令导致大量内存被使用(比如一个大的交集存储到一个新键中)一段时间，那么内存限制可能会被明显超出。

- 近似LRU算法

Redis的LRU算法并不是一个精确的实现。这意味着Redis无法选择最佳的淘汰候选。相反，它将尝试运行LRU算法的近似，通过抽样少量的密钥，并从抽样的密钥中剔除最佳的(存取时间最长的)密钥。
然而，自从Redis 3.0以来，该算法也得到了改进，从而也为淘汰提供了候选池。这提高了算法的性能，使其能够更接近真实LRU算法的行为。
对于Redis LRU算法来说，重要的是你可以通过改变每次淘汰的样本数量来调整算法的精度。这个参数由下面的配置指令控制：

maxmemory-samples 5

Redis不使用真正的LRU实现的原因是它需要更多的内存。下面是Redis使用的LRU近似与真实LRU的对比图。
Redis常见问题总结 - 图11
生成上述图表的测试用给定数量的键填充了Redis服务器。key是从第一个访问到最后一个，因此第一个key是使用LRU算法淘汰的最佳候选密钥。后来又增加了50%的key，以迫使一半的旧钥匙被驱逐。
可以在图中看到三种不同的点，形成三个不同的条带：

浅灰色带是被驱逐的物体。
灰色带是没有被驱逐的对象。
绿色的条带是添加的对象。

在理论上的LRU实现中，我们预计在旧密钥中，前一半将过期。Redis LRU算法只会概率性将旧的密钥过期。正如你所看到的，与Redis 2.8相比，Redis 3.0在5个样本中做得更好，但是大多数最新访问的对象仍然被Redis 2.8保留。在Redis 3.0中使用10个样本大小的近似非常接近理论性能。
注意，LRU只是一个模型，用于预测给定密钥在未来被访问的可能性。此外，如果数据访问模式非常类似于幂次定律，那么大多数访问将在一组密钥中进行，LRU近似算法将能够很好地处理这些密钥。

- 新的lFU模式

从Redis 4.0开始，提供一个新的最少使用的(Least Frequently Used)模式。在某些情况下，这种模式可能会工作得更好(提供更好的命中/错过率)，因为使用LFU Redis将尝试跟踪条目的访问频率，这样使用很少的item将被驱逐，而使用的item通常有更高的机会留在内存中。
以下policies可供选择：

volatile-lfu
allkeys-lfu

LFU与LRU类似：它使用一个叫做Morris计数器的概率计数器，以估算每个对象使用几个比特的对象访问频率，并结合一个衰减周期，这样计数器就会随着时间而减少。
与LRU不同的是，LFU有某些可调参数：例如，如果一个频繁item不再被访问，它的排名应该下降多快?为了更好地使算法适应特定的用例，还可以调整Morris计数器范围。

Redis常见问题总结