什么是redis

Redis 是一种基于内存的数据库，对数据的读写操作都是在内存中完成，因此读写速度非常快，常用于缓存，消息队列、分布式锁等场景。

Redis 提供了多种数据类型来支持不同的业务场景，比如 String (字符串)、Hash (哈希)、 List (列表)、Set (集合)、Zset (有序集合)、Bitmaps（位图）、HyperLogLog（基数统计）、GEO（地理信息）、Stream（流），并且对数据类型的操作都是原子性的，因为执行命令由单线程负责的，不存在并发竞争的问题。

除此之外，Redis 还支持事务 、持久化、Lua 脚本、多种集群方案（主从复制模式、哨兵模式、切片机群模式）、发布 / 订阅模式，内存淘汰机制、过期删除机制等等。

Redis和Memcached有什么区别

共同点

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

区别

  • Redis 支持的数据类型更丰富（String、Hash、List、Set、ZSet），而 Memcached 只支持最简单的 key-value 数据类型；
  • Redis 支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用，而 Memcached 没有持久化功能，数据全部存在内存之中，Memcached 重启或者挂掉后，数据就没了；
  • Redis 原生支持集群模式，Memcached 没有原生的集群模式，需要依靠客户端来实现往集群中分片写入数据；
  • Redis 支持发布订阅模型、Lua 脚本、事务等功能，而 Memcached 不支持

为什么用Redis作为MySQL的缓存

Redis具有高性能

假如用户第一次访问 MySQL 中的某些数据。这个过程会比较慢，因为是从硬盘上读取的。将该用户访问的数据缓存在 Redis 中，这样下一次再访问这些数据的时候就可以直接从缓存中获取了，操作 Redis 缓存就是直接操作内存，所以速度相当快。

Redis具备高并发

单台设备的 Redis 的 QPS（Query Per Second，每秒钟处理完请求的次数） 是 MySQL 的 10 倍，Redis 单机的 QPS 能轻松破 10w，而 MySQL 单机的 QPS 很难破 1w。

所以，直接访问 Redis 能够承受的请求是远远大于直接访问 MySQL 的，所以我们可以考虑把数据库中的部分数据转移到缓存中去，这样用户的一部分请求会直接到缓存这里而不用经过数据库

Redis数据类库及使用场景

key

常见的有五种数据类型：String（字符串），Hash（哈希），List（列表），Set（集合）、Zset（有序集合）。随着 Redis 版本的更新，后面又支持了四种数据类型： BitMap（2.2 版新增）、HyperLogLog（2.8 版新增）、GEO（3.2 版新增）、Stream（5.0 版新增）。

  • String：缓存对象，常规计数，分布式锁，共享session信息
  • List：消息队列（需要自己实现全局唯一ID）
  • Hash：缓存对象，购物车
  • Set：聚合计算（并集、交集、差集）场景，比如点赞、共同关注、抽奖活动等
  • ZSet：排序场景，比如排行榜，电话和姓名排序
  • BitMap：二值状态统计的场景，比如签到、判断用户登录状态
  • HyperLogLog：海量数据基数统计的场景，比如百万级网页 UV 计数等
  • GEO：存储地理位置信息的场景，比如滴滴叫车
  • Stream：消息队列

五种常见Redis数据类型底层实现

9fa26a74965efbf0f56b707a03bb9b7f

String

由SDS实现。SDS不仅可以保存文本数据，还可以保存二进制数据；SDS获取字符串长度的时间复杂度是O(1)；SDS拼接字符串不会导致缓冲区溢出

List

由quicklist实现，替代了原先的双向链表和压缩列表

Hash

由listpack实现，替代了原先的压缩列表和哈希表

Set

  • 如果集合中的元素都是整数且元素个数小于 512 （默认值，set-maxintset-entries 配置）个，Redis 会使用整数集合作为 Set 类型的底层数据结构；
  • 如果集合中的元素不满足上面条件，则 Redis 使用哈希表作为 Set 类型的底层数据结构。

Zset

由listpack实现，替代了原先的压缩列表和跳表。

Redis是单线程吗

Redis 单线程指的是「接收客户端请求 -> 解析请求 -> 进行数据读写等操作 -> 发送数据给客户端」这个过程是由一个线程（主线程）来完成的，这也是我们常说 Redis 是单线程的原因。

但是，Redis 程序并不是单线程的，Redis 在启动的时候，是会启动后台线程（BIO）的。

后台线程相当于一个消费者，生产者把耗时任务丢到任务队列中，消费者（BIO）不停轮询这个队列，拿出任务就去执行对应的方法即可。

Redis单线程模式是怎样的

Redis 基于 Reactor 模式开发了自己的网络事件处理器：这个处理器被称为文件事件处理器（file event handler）。

  • 文件事件处理器使用 I/O 多路复用（multiplexing）程序来同时监听多个套接字，并根据套接字目前执行的任务来为套接字关联不同的事件处理器。
  • 当被监听的套接字准备好执行连接应答（accept）、读取（read）、写入（write）、关 闭（close）等操作时，与操作相对应的文件事件就会产生，这时文件事件处理器就会调用套接字之前关联好的事件处理器来处理这些事件。

虽然文件事件处理器以单线程方式运行，但通过使用 I/O 多路复用程序来监听多个套接字，文件事件处理器既实现了高性能的网络通信模型，又可以很好地与 Redis 服务器中其他同样以单线程方式运行的模块进行对接，这保持了 Redis 内部单线程设计的简单性。

Redis采用单线程为什么还这么快

  1. Redis的大部分操作都在内存中完成，并且采用了高效的数据结构，CPU不是瓶颈
  2. 单线程避免了多线程之间的竞争，省去了多线程切换带来的时间和性能上的开销，而且也不会导致死锁问题
  3. Redis 采用了 I/O 多路复用机制处理大量的客户端 Socket 请求，IO 多路复用机制是指一个线程处理多个 IO 流

6.0之后为什么引入了多线程

随着网络硬件的性能提升，Redis的性能瓶颈有时会出现在网络IO的处理上。所以为了提高网络 I/O 的并行度，Redis 6.0 对于网络 I/O 采用多线程来处理。但是对于命令的执行，Redis 仍然使用单线程来处理，所以大家不要误解 Redis 有多线程同时执行命令。

Redis如何实现数据不丢失

Redis 的读写操作都是在内存中，所以 Redis 性能才会高，但是当 Redis 重启后，内存中的数据就会丢失，那为了保证内存中的数据不会丢失，Redis 实现了数据持久化的机制，这个机制会把数据存储到磁盘，这样在 Redis 重启就能够从磁盘中恢复原有的数据。

Redis 共有三种数据持久化的方式：

  • AOF 日志：每执行一条写操作命令，就把该命令以追加的方式写入到一个文件里；
  • RDB 快照：将某一时刻的内存数据，以二进制的方式写入磁盘；
  • 混合持久化方式：Redis 4.0 新增的方式，集成了 AOF 和 RBD 的优点；

AOF日志如何实现

Redis 在执行完一条写操作命令后，就会把该命令以追加的方式写入到一个文件里，然后 Redis 重启时，会读取该文件记录的命令，然后逐一执行命令的方式来进行数据恢复。

先执行再写日志的优缺点

  • 避免额外的检查开销「语法一定是正确的」
  • 不会阻塞当前写操作命令的执行
  • 数据可能会丢失。执行写操作命令和记录日志是两个过程，那当 Redis 在还没来得及将命令写入到硬盘时，服务器发生宕机了，这个数据就会有丢失的风险
  • 可能阻塞其他操作

AOF写回策略

98987d9417b2bab43087f45fc959d32a-20230309232253633

AOF日志过大，会触发重写机制

AOF 日志是一个文件，随着执行的写操作命令越来越多，文件的大小会越来越大。 如果当 AOF 日志文件过大就会带来性能问题。

AOF 重写机制是在重写时，读取当前数据库中的所有键值对，然后将每一个键值对用一条命令记录到「新的 AOF 文件」，等到全部记录完后，就将新的 AOF 文件替换掉现有的 AOF 文件。

重写AOF日志的过程

Redis 的重写 AOF 过程是由后台子进程 bgrewriteaof 来完成的。

触发重写机制后，主进程就会创建重写 AOF 的子进程，此时父子进程共享物理内存，重写子进程只会对这个内存进行只读，重写 AOF 子进程会读取数据库里的所有数据，并逐一把内存数据的键值对转换成一条命令，再将命令记录到重写日志（新的 AOF 文件）。

但是重写过程中，祝进程依然可以正常处理命令，这会导致数据不一致。为了解决该问题，Redis 设置了一个 AOF 重写缓冲区，在重写 AOF 期间，当 Redis 执行完一个写命令之后，它会同时将这个写命令写入到 「AOF 缓冲区」和 「AOF 重写缓冲区」。

当子进程完成AOF重写工作后，会向主进程发送一个信号，主进程会将AOF 重写缓冲区中的所有内容追加到新的 AOF 的文件中。

RDB快照是如何实现的

RDB 快照就是记录某一个瞬间的内存数据，记录的是实际数据，而 AOF 文件记录的是命令操作的日志，而不是实际的数据。

因此在 Redis 恢复数据时， RDB 恢复数据的效率会比 AOF 高些，因为直接将 RDB 文件读入内存就可以，不需要像 AOF 那样还需要额外执行操作命令的步骤才能恢复数据。

RDB做快照时会阻塞线程吗

Redis 提供了两个命令来生成 RDB 文件，分别是 save 和 bgsave，他们的区别就在于是否在「主线程」里执行：

  • 执行了 save 命令，就会在主线程生成 RDB 文件，由于和执行操作命令在同一个线程，所以如果写入 RDB 文件的时间太长，会阻塞主线程；
  • 执行了 bgsave 命令，会创建一个子进程来生成 RDB 文件，这样可以避免主线程的阻塞

RDB和AOF对比

AOF优点是丢失数据少，但是数据恢复不快。

RDB优点是数据恢复速度快，但是快照的频率不好把握。频率太低，丢失的数据就会比较多；频率太高，就会影响性能。

混合持久化

使用了混合持久化，AOF 文件的前半部分是 RDB 格式的全量数据，后半部分是 AOF 格式的增量数据。这样的好处在于，由于前半部分是RDB内容，加载的时候速度会快很多。

加载完 RDB 的内容后，才会加载后半部分的 AOF 内容，这里的内容是 Redis 后台子进程重写 AOF 期间，主线程处理的操作命令，可以使得数据更少的丢失。

当然也有缺点，一是会使AOF文件的可读性变得很差，二是开启混合持久化后兼容性会变差。

主从复制

主从复制是 Redis 高可用服务的最基础的保证，实现方案就是将从前的一台 Redis 服务器，同步数据到多台从 Redis 服务器上，即一主多从的模式，且主从服务器之间采用的是「读写分离」的方式。

主服务器可以进行读写操作，当发生写操作时自动将写操作同步给从服务器，而从服务器一般是只读，并接受主服务器同步过来写操作命令，然后执行这条命令。也就是说，所有的数据修改只在主服务器上进行，然后将最新的数据同步给从服务器，这样就是的主从服务器的数据是一致的。

主从服务器之间的命令复制是异步进行的，所以数据不一致时难以避免的。

哨兵模式

在 Redis 的主从架构中，由于主从模式是读写分离的，如果主节点（master）挂了，那么将没有主节点来服务客户端的写操作请求，也没有主节点给从节点（slave）进行数据同步了。

哨兵机制的作用是实现主从节点故障转移。它会检测主节点是否存活，如果发现主节点挂了，它就会选举一个从节点切换为主节点，并且吧新主节点的相关信息通知给从节点和客户端。

切片集群模式

当 Redis 缓存数据量大到一台服务器无法缓存时，就需要使用 Redis 切片集群（Redis Cluster ）方案，它将数据分布在不同的服务器上，以此来降低系统对单主节点的依赖，从而提高 Redis 服务的读写性能。

什么是脑裂

在 Redis 主从架构中，部署方式一般是「一主多从」，主节点提供写操作，从节点提供读操作。 如果主节点的网络突然发生了问题，它与所有的从节点都失联了，但是此时的主节点和客户端的网络是正常的，这个客户端并不知道 Redis 内部已经出现了问题，还在照样的向这个失联的主节点写数据（过程 A），此时这些数据被旧主节点缓存到了缓冲区里，因为主从节点之间的网络问题，这些数据都是无法同步给从节点的。

这时，哨兵也发现主节点失联了，它就认为主节点挂了（但实际上主节点正常运行，只是网络出问题了），于是哨兵就会在「从节点」中选举出一个 leader 作为主节点，这时集群就有两个主节点了 —— 脑裂出现了。

然后，网络突然好了，哨兵因为之前已经选举出一个新主节点了，它就会把旧主节点降级为从节点（A），然后从节点（A）会向新主节点请求数据同步，因为第一次同步是全量同步的方式，此时的从节点（A）会清空掉自己本地的数据，然后再做全量同步。所以，之前客户端在过程 A 写入的数据就会丢失了，也就是集群产生脑裂数据丢失的问题。

Redis使用的过期删除策略是什么

Redis 是可以对 key 设置过期时间的，因此需要有相应的机制将已过期的键值对删除，而做这个工作的就是过期键值删除策略。

每当我们对一个 key 设置了过期时间时，Redis 会把该 key 带上过期时间存储到一个过期字典（expires dict）中，也就是说「过期字典」保存了数据库中所有 key 的过期时间。

当我们查询一个 key 时，Redis 首先检查该 key 是否存在于过期字典中：

  • 如果不在，则正常读取键值；
  • 如果存在，则会获取该 key 的过期时间，然后与当前系统时间进行比对，如果比系统时间大，那就没有过期，否则判定该 key 已过期。

Redis 使用的过期删除策略是「惰性删除 + 定期删除」这两种策略配和使用。

惰性删除

不主动删除过期键，每次从数据库访问key时，都检测key是否过期。对CPU时间友好，对内存不友好。

定期删除

每隔一段时间「随机」从数据库中取出一定数量的key进行检查，并删除其中的过期key。

能够减少过期键对空间的无效占用，但是难以确定删除操作执行的时长和频率。

持久化对过期键如何处理

RDB分为两个阶段，生成阶段和加载阶段。

生成阶段过期的键不会被保存到新的RDB文件中。加载阶段主服务器中，过期键不会被载入到数据库中；从服务器会被载入到数据库中「一般影响不大」

AOF分为写入阶段和重写阶段。

  • 写入阶段：如果数据库某个过期键还没被删除，那么AOF文件会保留此过期键。删除后Redis会向AOF追加一条DEL命令显式地删除该键值。
  • 重写阶段：已过期的键不会被保存到重写后的AOF文件中

主从模式下对过期键如何处理

从库不会进行过期扫描，从库对处理的过期是被动的。

从库的过期键处理依靠主服务器控制，主库在 key 到期时，会在 AOF 文件里增加一条 del 指令，同步到所有的从库，从库通过执行这条 del 指令来删除过期的 key。

Redis内存淘汰策略

在Redis的运行内存达到了某个阈值，就会触发内存淘汰机制。

Redis 内存淘汰策略共有八种，这八种策略大体分为「不进行数据淘汰」和「进行数据淘汰」两类策略。

  • noeviction（Redis3.0 之后，默认的内存淘汰策略） ：它表示当运行内存超过最大设置内存时，不淘汰任何数据，而是不再提供服务，直接返回错误。
  • volatile-random：随机淘汰设置了过期时间的任意键值；
  • volatile-ttl：优先淘汰更早过期的键值。
  • volatile-lru（Redis3.0 之前，默认的内存淘汰策略）：淘汰所有设置了过期时间的键值中，最久未使用的键值；
  • volatile-lfu（Redis 4.0 后新增的内存淘汰策略）：淘汰所有设置了过期时间的键值中，最少使用的键值；
  • allkeys-random：随机淘汰任意键值；
  • allkeys-lru：淘汰整个键值中最久未使用的键值；
  • allkeys-lfu（Redis 4.0 后新增的内存淘汰策略）：淘汰整个键值中最少使用的键值。

Redis如何实现LRU算法

当 Redis 进行内存淘汰时，会使用随机采样的方式来淘汰数据，它是随机取 5 个值（此值可配置），然后淘汰最久没有使用的那个。

优点是节省了空间占用，提升了缓存性能。缺点是无法解决缓存污染问题，比如应用一次读取了大量的数据，而这些数据只会被读取这一次，那么这些数据会留存在 Redis 缓存中很长一段时间，造成缓存污染。

Redis如何实现LFU算法

LFU 全称是 Least Frequently Used 翻译为最近最不常用的，LFU 算法是根据数据访问次数来淘汰数据的，它的核心思想是 “如果数据过去被访问多次，那么将来被访问的频率也更高”。

所以， LFU 算法会记录每个数据的访问次数。当一个数据被再次访问时，就会增加该数据的访问次数。这样就解决了偶尔被访问一次之后，数据留存在缓存中很长一段时间的问题，相比于 LRU 算法也更合理一些。

LFU 算法相比于 LRU 算法的实现，多记录了「数据的访问频次」的信息。

如何避免缓存雪崩

当大量缓存数据在同一时间过期时，如果此时有大量的用户请求，都无法在Redis中处理，于是全部请求都直接访问数据库。这回导致数据库压力骤增，从而形成一系列连锁反应，这就是缓存雪崩。

  • 将缓存失效时间随机打散： 我们可以在原有的失效时间基础上增加一个随机值（比如 1 到 10 分钟）这样每个缓存的过期时间都不重复了，也就降低了缓存集体失效的概率。
  • 设置缓存不过期： 我们可以通过后台服务来更新缓存数据，从而避免因为缓存失效造成的缓存雪崩，也可以在一定程度上避免缓存并发问题。

如何避免缓存击穿

我们的业务通常会有几个数据会被频繁地访问，比如秒杀活动，这类被频地访问的数据被称为热点数据。

如果缓存中的某个热点数据过期了，此时大量的请求访问了该热点数据，就无法从缓存中读取，直接访问数据库，数据库很容易就被高并发的请求冲垮，这就是缓存击穿的问题。

  • 互斥锁方案（Redis 中使用 setNX 方法设置一个状态位，表示这是一种锁定状态），保证同一时间只有一个业务线程请求缓存，未能获取互斥锁的请求，要么等待锁释放后重新读取缓存，要么就返回空值或者默认值。
  • 不给热点数据设置过期时间，由后台异步更新缓存，或者在热点数据准备要过期前，提前通知后台线程更新缓存以及重新设置过期时间

如何避免缓存穿透

当用户访问的数据，既不在缓存中，也不在数据库中，导致请求在访问缓存时，发现缓存缺失，再去访问数据库时，发现数据库中也没有要访问的数据，没办法构建缓存数据，来服务后续的请求。那么当有大量这样的请求到来时，数据库的压力骤增，这就是缓存穿透的问题。

发生时一般是这两种状况：

  • 业务误操作
  • 黑客恶意攻击，故意大量访问某些读取不存在数据的业务

常见的解决方案有三种：

  • 对非法请求进行限制。在 API 入口处我们要判断求请求参数是否合理，如果判断出是恶意请求就直接返回错误
  • 设置空值或默认值
  • 设置布隆过滤器。我们可以在写入数据库数据时，使用布隆过滤器做个标记，然后在用户请求到来时，业务线程确认缓存失效后，可以通过查询布隆过滤器快速判断数据是否存在，如果不存在，就不用通过查询数据库来判断数据是否存在，即使发生了缓存穿透，大量请求只会查询 Redis 和布隆过滤器，而不会查询数据库，保证了数据库能正常运行

设计一个动态缓存热点数据的策略

热点数据动态缓存的策略总体思路：通过数据最新访问时间来做排名，并过滤掉不常访问的数据，只留下经常访问的数据。

  • 先通过缓存系统做一个排序队列（比如存放 1000 个商品），系统会根据商品的访问时间，更新队列信息，越是最近访问的商品排名越靠前；
  • 同时系统会定期过滤掉队列中排名最后的 200 个商品，然后再从数据库中随机读取出 200 个商品加入队列中；
  • 这样当请求每次到达的时候，会先从队列中获取商品 ID，如果命中，就根据 ID 再从另一个缓存数据结构中读取实际的商品信息，并返回。

常见的缓存更新策略

常见的缓存更新策略共有 3 种：

  • Cache Aside（旁路缓存）策略；
  • Read/Write Through（读穿 / 写穿）策略；
  • Write Back（写回）策略；

实际开发中，用的是Cache Aside「旁路缓存」。

6e3db3ba2f829ddc14237f5c7c00e7ce-20230309232338149

写策略的步骤

先更新数据库中的数据，再删除缓存中的数据。顺序不得颠倒！

读策略的步骤

如果命中缓存，直接返回数据；如果没有命中，先从数据库中读取数据，然后将数据写入到缓存，并且返回给用户。

旁路缓存策略适合读多写少的场景，不适合写多的场景。

参考文章：小林coding