跳至主要內容

Redis 常见面试题

Redis 基础

Redis是什么？

Redis（Remote Dictionary Server）是一个使用 C 语言编写的，高性能非关系型的键值对数据库。与传统数据库不同的是，Redis 的数据是存在内存中的，所以读写速度非常快，被广泛应用于缓存方向。Redis可以将数据写入磁盘中，保证了数据的安全不丢失，而且Redis的操作是原子性的。

Redis优缺点？

优点：

  1. 基于内存操作，内存读写速度快。
  2. 支持多种数据类型，包括String、Hash、List、Set、ZSet等。
  3. 支持持久化。Redis支持RDB和AOF两种持久化机制，持久化功能可以有效地避免数据丢失问题。
  4. 支持事务。Redis的所有操作都是原子性的，同时Redis还支持对几个操作合并后的原子性执行。
  5. 支持主从复制。主节点会自动将数据同步到从节点，可以进行读写分离。
  6. Redis命令的处理是单线程的。Redis6.0引入了多线程，需要注意的是，多线程用于处理网络数据的读写和协议解析，Redis命令执行还是单线程的。

缺点：

  1. 对结构化查询的支持比较差。
  2. 数据库容量受到物理内存的限制，不适合用作海量数据的高性能读写，因此Redis适合的场景主要局限在较小数据量的操作。
  3. Redis 较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。

Redis为什么这么快？

详情请查看：Redis为什么这么快

  • 基于内存：Redis是使用内存存储，没有磁盘IO上的开销。数据存在内存中，读写速度快。
  • 单线程：省去了很多上下文切换的时间以及CPU消耗，不存在竞争条件，不用去考虑各种锁的问题，不存在加锁释放锁操作，也不会出现死锁而导致的性能消耗。
  • IO多路复用模型：Redis 采用 IO 多路复用技术。Redis 使用单线程来轮询描述符，将数据库的操作都转换成了事件，不在网络I/O上浪费过多的时间。
  • 高效的数据结构：Redis 每种数据类型底层都做了优化，目的就是为了追求更快的速度。

讲讲Redis的线程模型？

Redis基于Reactor模式开发了网络事件处理器，这个处理器被称为文件事件处理器。它的组成结构为4部分：多个套接字、IO多路复用程序、文件事件分派器、事件处理器。因为文件事件分派器队列的消费是单线程的，所以Redis才叫单线程模型。

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

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

为什么Redis是单线程？

这里我们强调的单线程，指的是网络请求模块使用一个线程来处理，即一个线程处理所有网络请求，其他模块仍用了多个线程。

那为什么使用单线程呢？官方答案是：因为CPU不是Redis的瓶颈，Redis的瓶颈最有可能是机器内存或者网络带宽。既然单线程容易实现，而且CPU不会成为瓶颈，那就顺理成章地采用单线程的方案了。

但是，我们使用单线程的方式是无法发挥多核CPU 性能，不过我们可以通过在单机开多个Redis 实例来解决这个问题

Redis6.0 之前为什么一直不使用多线程？

Redis使用单线程的可维护性高。多线程模型虽然在某些方面表现优异，但是它却引入了程序执行顺序的不确定性，带来了并发读写的一系列问题，增加了系统复杂度、同时可能存在线程切换、甚至加锁解锁、死锁造成的性能损耗。

Redis6.0 为什么要引入多线程呢？

因为Redis的瓶颈不在内存，而是在网络I/O模块带来CPU的耗时，所以Redis6.0的多线程是用来处理网络I/O这部分，充分利用CPU资源，减少网络I/O阻塞带来的性能损耗。

多线程模式下，是否存在线程并发安全问题？

  • 从Redis 服务端层面分析：

在redis的多线程模式下，获取、解析命令，以及输出结果着两个过程，可以配置成多线程执行的，因为它毕竟是我们定位到的主要耗时点，但是命令的执行，也就是内存操作，依然是单线程运行的。所以，Redis 的多线程部分只是用来处理网络数据的读写和协议解析，执行命令仍然是单线程顺序执行，也就不存在并发安全问题。

  • 从Redis客户端层面分析。

虽然Redis Server中的指令执行是原子的，但是如果有多个Redis客户端同时执行多个指令的时候，就无法保证原子性。当然，对于客户端层面的线程安全性问题，解决方法有很多，比如尽可能的使用Redis里面的原子指令，或者对多个客户端的资源访问加锁，或者通过Lua脚本来实现多个指令的操作等等。

既然Redis那么快，为什么不用它做主数据库，只用它做缓存？

虽然Redis非常快，但它也有一些局限性，不能完全替代主数据库。有以下原因：

  • 事务处理：Redis只支持简单的事务处理，对于复杂的事务无能为力，比如跨多个键的事务处理。
  • 数据持久化：Redis是内存数据库，数据存储在内存中，如果服务器崩溃或断电，数据可能丢失。虽然Redis提供了数据持久化机制，但有一些限制。
  • 数据处理：Redis只支持一些简单的数据结构，比如字符串、列表、哈希表等。如果需要处理复杂的数据结构，比如关系型数据库中的表，那么Redis可能不是一个好的选择。
  • 数据安全：Redis没有提供像主数据库那样的安全机制，比如用户认证、访问控制等等。

因此，虽然Redis非常快，但它还有一些限制，不能完全替代主数据库。所以，使用Redis作为缓存是一种很好的方式，可以提高应用程序的性能，并减少数据库的负载。

Redis应用场景有哪些？

Redis作为一种优秀的基于key/value的缓存，有非常不错的性能和稳定性，无论是在工作中，还是面试中，都经常会出现。

下面来聊聊Redis的常见的8种应用场景。

  1. 缓存热点数据，缓解数据库的压力。例如：热点数据缓存（例如报表、明星出轨），对象缓存、全页缓存、可以提升热点数据的访问数据。
  2. 计数器。利用 Redis 原子性的自增操作，可以实现计数器的功能，内存操作，性能非常好，非常适用于这些计数场景，比如统计用户点赞数、用户访问数等。为了保证数据实时效，每次浏览都得给+1，并发量高时如果每次都请求数据库操作无疑是种挑战和压力。
  3. 分布式会话。集群模式下，在应用不多的情况下一般使用容器自带的session复制功能就能满足，当应用增多相对复杂的系统中，一般都会搭建以Redis等内存数据库为中心的session服务，session不再由容器管理，而是由session服务及内存数据库管理。
  4. 分布式锁。在分布式场景下，无法使用单机环境下的锁来对多个节点上的进程进行同步。可以使用 Redis 自带的 SETNX（SET if Not eXists） 命令实现分布式锁，除此之外，还可以使用官方提供的 RedLock 分布式锁实现。
  5. 简单的消息队列，消息队列是大型网站必用中间件，如ActiveMQ、RabbitMQ、Kafka等流行的消息队列中间件，主要用于业务解耦、流量削峰及异步处理实时性低的业务。可以使用Redis自身的发布/订阅模式或者List来实现简单的消息队列，实现异步操作。
  6. 限速器，可用于限制某个用户访问某个接口的频率，比如秒杀场景用于防止用户快速点击带来不必要的压力。
  7. 社交网络，点赞、踩、关注/被关注、共同好友等是社交网站的基本功能，社交网站的访问量通常来说比较大，而且传统的关系数据库类型不适合存储这种类型的数据，Redis提供的哈希、集合等数据结构能很方便的的实现这些功能。
  8. 排行榜。很多网站都有排行榜应用的，如京东的月度销量榜单、商品按时间的上新排行榜等。Redis提供的有序集合数据类构能实现各种复杂的排行榜应用。

Memcached和Redis的区别？

现在公司一般都是用 Redis 来实现缓存，而且 Redis 自身也越来越强大了！不过，了解 Redis 和 Memcached 的区别和共同点，有助于我们在做相应的技术选型的时候，能够做到有理有据！

共同点：

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

区别：

  1. 数据类型：Redis 支持更丰富的数据类型（支持更复杂的应用场景）。Redis 不仅仅支持简单的 k/v 类型的数据，同时还提供 list，set，zset，hash 等数据结构的存储。Memcached 只支持最简单的 k/v 数据类型。
  2. 数据持久化：Redis 支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用，而 Memcached 把数据全部存在内存之中。也就是说，Redis 有灾难恢复机制而 Memcached 没有。
  3. 集群模式支持：Memcached 没有原生的集群模式，需要依靠客户端来实现往集群中分片写入数据；但是 Redis 自 3.0 版本起是原生支持集群模式的。
  4. 线程模型：Memcached 是多线程，非阻塞 IO 复用的网络模型；Redis 使用单线程的多路 IO 复用模型。 （Redis 6.0 针对网络数据的读写引入了多线程）
  5. 特性支持：Redis 支持发布订阅模型、Lua 脚本、事务等功能，而 Memcached 不支持。并且，Redis 支持更多的编程语言。
  6. 过期数据删除：Memcached 过期数据的删除策略只用了惰性删除，而 Redis 同时使用了惰性删除与定期删除。

为什么要用 Redis 而不用 map/guava 做缓存?

使用自带的 map 或者 guava 实现的是本地缓存，最主要的特点是轻量以及快速，生命周期随着 jvm 的销毁而结束，并且在多实例的情况下，每个实例都需要各自保存一份缓存，缓存不具有一致性。

使用 redis 或 memcached 之类的称为分布式缓存，在多实例的情况下，各实例共用一份缓存数据，缓存具有一致性。

Redis 数据类型

Redis 数据类型有哪些？

详细可以查看：数据类型及其应用场景

基本数据类型：

  1. String：最常用的一种数据类型，String类型的值可以是字符串、数字或者二进制，但值最大不能超过512MB。
  2. Hash：Hash 是一个键值对集合。
  3. Set：无序去重的集合。Set 提供了交集、并集等方法，对于实现共同好友、共同关注等功能特别方便。
  4. List：有序可重复的集合，底层是依赖双向链表实现的。
  5. SortedSet：有序Set。内部维护了一个score的参数来实现。适用于排行榜和带权重的消息队列等场景。

特殊的数据类型：

  1. Bitmap：位图，可以认为是一个以位为单位数组，数组中的每个单元只能存0或者1，数组的下标在 Bitmap 中叫做偏移量。Bitmap的长度与集合中元素个数无关，而是与基数的上限有关。
  2. Hyperloglog。HyperLogLog 是用来做基数统计的算法，其优点是，在输入元素的数量或者体积非常非常大时，计算基数所需的空间总是固定的、并且是很小的。典型的使用场景是统计独立访客。
  3. Geospatial ：主要用于存储地理位置信息，并对存储的信息进行操作，适用场景如定位、附近的人等。

SortedSet和List异同点？

相同点：

  1. 都是有序的；
  2. 都可以获得某个范围内的元素。

不同点：

  1. 列表基于链表实现，获取两端元素速度快，访问中间元素速度慢；
  2. 有序集合基于散列表和跳跃表实现，访问中间元素时间复杂度是OlogN；
  3. 列表不能简单的调整某个元素的位置，有序列表可以（更改元素的分数）；
  4. 有序集合更耗内存。

Redis 怎么实现消息队列？

BLPOP queue 0  //0表示不限制等待时间

BLPOP和LPOP命令相似，唯一的区别就是当列表没有元素时BLPOP命令会一直阻塞连接，直到有新元素加入。

redis可以通过pub/sub主题订阅模式实现一个生产者，多个消费者，当然也存在一定的缺点，当消费者下线时，生产的消息会丢失。

PUBLISH channel1 hi
SUBSCRIBE channel1
UNSUBSCRIBE channel1 //退订通过SUBSCRIBE命令订阅的频道。

PSUBSCRIBE channel?* 按照规则订阅。
PUNSUBSCRIBE channel?* 退订通过PSUBSCRIBE命令按照某种规则订阅的频道。其中订阅规则要进行严格的字符串匹配，PUNSUBSCRIBE *无法退订channel?*规则。

Redis 怎么实现延时队列

使用sortedset，拿时间戳作为score，消息内容作为key，调用zadd来生产消息，消费者用zrangebyscore指令获取N秒之前的数据轮询进行处理。

Redis 的有序集合底层为什么要用跳表，而不用平衡树、红黑树或者 B+树？

这道面试题很多大厂比较喜欢问，难度还是有点大的。

  • 平衡树 vs 跳表：平衡树的插入、删除和查询的时间复杂度和跳表一样都是 O(log n)。对于范围查询来说，平衡树也可以通过中序遍历的方式达到和跳表一样的效果。但是它的每一次插入或者删除操作都需要保证整颗树左右节点的绝对平衡，只要不平衡就要通过旋转操作来保持平衡，这个过程是比较耗时的。跳表诞生的初衷就是为了克服平衡树的一些缺点。跳表使用概率平衡而不是严格强制的平衡，因此，跳表中的插入和删除算法比平衡树的等效算法简单得多，速度也快得多。

  • 红黑树 vs 跳表：相比较于红黑树来说，跳表的实现也更简单一些，不需要通过旋转和染色（红黑变换）来保证黑平衡。并且，按照区间来查找数据这个操作，红黑树的效率没有跳表高。

  • B+树 vs 跳表：B+树更适合作为数据库和文件系统中常用的索引结构之一，它的核心思想是通过尽可能少的 IO 定位到尽可能多的索引来获得查询数据。对于 Redis 这种内存数据库来说，它对这些并不感冒，因为 Redis 作为内存数据库它不可能存储大量的数据，所以对于索引不需要通过 B+树这种方式进行维护，只需按照概率进行随机维护即可，节约内存。而且使用跳表实现 zset 时相较前者来说更简单一些，在进行插入时只需通过索引将数据插入到链表中合适的位置再随机维护一定高度的索引即可，也不需要像 B+树那样插入时发现失衡时还需要对节点分裂与合并。

Redis中的跳表是两步两步跳的吗？

如果采用新增节点或者删除节点时，来调整跳表节点以维持比例2：1的方法的话，显然是会带来额外开销的。

跳表在创建节点时候，会生成范围为[0-1]的一个随机数，如果这个随机数小于 0.25（相当于概率 25%），那么层数就增加 1 层，然后继续生成下一个随机数，直到随机数的结果大于 0.25 结束，最终确定该节点的层数。因为随机数取值在[0,0.25）范围内概率不会超过25%，所以这也说明了增加一层的概率不会超过25%。这样的话，当插入一个新结点时，只需修改前后结点的指针，而其它结点的层数就不需要随之改变了，这样就降低插入操作的复杂度。

// #define ZSKIPLIST_P 0.25
int zslRandomLevel(void) {
    static const int threshold = ZSKIPLIST_P*RAND_MAX;
    int level = 1; //初始化为一级索引
    while (random() < threshold)
        level += 1;//随机数小于 0.25就增加一层
	//如果level 没有超过最大层数就返回，否则就返回最大层数
    return (level<ZSKIPLIST_MAXLEVEL) ? level : ZSKIPLIST_MAXLEVEL;
}

Redis遇到哈希冲突怎么办？

当有两个或以上数量的键被分配到了哈希表数组的同一个索引上面时， 我们称这些键发生了冲突（collision）。

关于解决hash冲突问题可以看这篇文章：解决哈希冲突的三种方法

而redis是先通过拉链法解决，再通过rehash来解决hash冲突问题的，即再hash法

rehash原理？

渐进式 rehash 步骤如下：

  1. 先给哈希表 2分配空间；
  2. 在 rehash 进行期间，每次哈希表元素进行新增、删除、查找或者更新操作时，Redis 除了会执行对应的操作之外，还会顺序将哈希表 1中索引位置上的所有 key-value 迁移到哈希表 2上；
  3. 随着处理客户端发起的哈希表操作请求数量越多，最终在某个时间点会把哈希表 1的所有 key-value 迁移到哈希表 2，从而完成 rehash 操作。

这样就把一次性大量数据迁移工作的开销，分摊到了多次处理请求的过程中，避免了一次性 rehash 的耗时操作。

在进行渐进式 rehash 的过程中，会有两个哈希表，所以在渐进式 rehash 进行期间，哈希表元素的删除、查找、更新等操作都会在这两个哈希表进行。比如，在渐进式 rehash 进行期间，查找一个 key 的值的话，先会在哈希表 1里面进行查找，如果没找到，就会继续到哈希表 2 里面进行找到。新增一个 key-value 时，会被保存到哈希表 2里面，而哈希表 1则不再进行任何添加操作，这样保证了哈希表 1的 key-value 数量只会减少，随着 rehash 操作的完成，最终哈希表 1就会变成空表。

rehash的触发条件？

负载因子 = 哈希表已保存节点数量/哈希表大小

触发 rehash 操作的条件，主要有两个：

  • 当负载因子大于等于 1 ，并且 Redis 没有在执行 bgsave 命令或者 bgrewiteaof 命令，也就是没有执行 RDB 快照或没有进行 AOF 重写的时候，就会进行 rehash 操作。
  • 当负载因子大于等于 5 时，此时说明哈希冲突非常严重了，不管有没有有在执行 RDB 快照或 AOF 重写，都会强制进行 rehash 操作

一个REDIS实例最多能存放多少KEYS

redis 的每个实例最多可以存放约 2^32 - 1 个keys，即大约 42 亿个keys。这是由 Redis 内部使用的哈希表实现决定的，它使用 32 位有符号整数作为索引。Redis 使用的哈希函数和负载因子等因素也会影响实际可存放键的数量。

需要注意的是，尽管 Redis 允许存储数量庞大的键，但在实践中，存储过多的键可能会导致性能下降和内存消耗增加。因此，在设计应用程序时，需要根据实际需求和硬件资源来合理规划键的数量，避免过度使用 Redis 实例造成负担。如果需要存储更多的键值对，可以考虑使用 Redis 集群或分片技术，以扩展整体存储容量。

Redis事务

与关系型数据库事务的区别

Redis事务是指将多条命令加入队列，一次批量执行多条命令，每条命令会按顺序执行，事务执行过程中不会被其他客户端发来的命令所打断。也就是说，Redis事务就是一次性、顺序性、排他性的执行一个队列中的一系列命令。

Redis事务和关系型数据库的事务不太一样，它不保证原子性，也没有隔离级别的概念。

事务不保证原子性，但是Redis命令本身是原子性的

  1. Redis事务没有隔离级别的概念：批量操作在发送 EXEC 命令前被放入队列缓存，并不会被实际执行，也就不存在事务里的查询要看到本事务的更新或其它事务的修改更新操作的问题。（Mysql里的事务的语句不是放入队列，而是直接执行）
  2. Redis不保证原子性：Redis中，单条命令是原子性执行的，但事务不保证原子性，且没有回滚。事务中任意命令执行失败，其余的命令仍会被执行。

WATCH命令

WATCH命令可以监控一个或多个键，一旦其中有一个键被修改，之后的事务就不会执行（类似于乐观锁）。执行EXEC命令之后，就会自动取消监控。

127.0.0.1:6379> watch name
OK
127.0.0.1:6379> set name 1
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set name 2
QUEUED
127.0.0.1:6379> set gender 1
QUEUED
127.0.0.1:6379> exec
(nil)
127.0.0.1:6379> get gender
(nil)

比如上面的代码中：

  1. watch name开启了对name这个key的监控
  2. 修改name的值
  3. 开启事务a
  4. 在事务a中设置了name和gender的值
  5. 使用EXEC命令进提交事务
  6. 使用命令get gender发现不存在，即事务a没有执行

使用UNWATCH可以取消WATCH命令对key的监控，所有监控锁将会被取消。

Redis事务支持隔离性吗？

Redis 是单进程程序，并且它保证在执行事务时，不会对事务进行中断，事务可以运行直到执行完所有事务队列中的命令为止。因此，Redis 的事务是总是带有隔离性的。

Redis事务保证原子性吗，支持回滚吗？

Redis单条命令是原子性执行的，但事务不保证原子性，且没有回滚。事务中任意命令执行失败，其余的命令仍会被执行。

持久化机制

详细可以查看：持久化技术

持久化就是把内存的数据写到磁盘中，防止服务宕机导致内存数据丢失。

Redis支持两种方式的持久化，一种是RDB的方式，一种是AOF的方式。前者会根据指定的规则定时将内存中的数据存储在硬盘上，而后者在每次执行完命令后将命令记录下来。一般将两者结合使用。

RDB方式

RDB是 Redis 默认的持久化方案。RDB持久化时会将内存中的数据写入到磁盘中，在指定目录下生成一个dump.rdb文件。Redis 重启会加载dump.rdb文件恢复数据。

bgsave是主流的触发 RDB 持久化的方式，执行过程如下：

  • 执行BGSAVE命令
  • Redis 父进程判断当前是否存在正在执行的子进程，如果存在，BGSAVE命令直接返回。
  • 父进程执行fork操作创建子进程，fork操作过程中父进程会阻塞。
  • 父进程fork完成后，父进程继续接收并处理客户端的请求，而子进程开始将内存中的数据写进硬盘的临时文件；
  • 当子进程写完所有数据后会用该临时文件替换旧的 RDB 文件。

Redis启动时会读取RDB快照文件，将数据从硬盘载入内存。通过 RDB 方式的持久化，一旦Redis异常退出，就会丢失最近一次持久化以后更改的数据。

触发 RDB 持久化的方式：

  1. 手动触发：用户执行SAVE或BGSAVE命令。SAVE命令执行快照的过程会阻塞所有客户端的请求，应避免在生产环境使用此命令。BGSAVE命令可以在后台异步进行快照操作，快照的同时服务器还可以继续响应客户端的请求，因此需要手动执行快照时推荐使用BGSAVE命令。

  2. 被动触发：

    • 根据配置规则进行自动快照，如SAVE 100 10，100秒内至少有10个键被修改则进行快照。
    • 如果从节点执行全量复制操作，主节点会自动执行BGSAVE生成 RDB 文件并发送给从节点。
    • 默认情况下执行shutdown命令时，如果没有开启 AOF 持久化功能则自动执行·BGSAVE·。

优点：

  1. Redis 加载 RDB 恢复数据远远快于 AOF 的方式。
  2. 使用单独子进程来进行持久化，主进程不会进行任何 IO 操作，保证了 Redis 的高性能。

缺点：

  1. RDB方式数据无法做到实时持久化。因为BGSAVE每次运行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本比较高。
  2. RDB 文件使用特定二进制格式保存，Redis 版本升级过程中有多个格式的 RDB 版本，存在老版本 Redis 无法兼容新版 RDB 格式的问题。

AOF方式

AOF（append only file）持久化：以独立日志的方式记录每次写命令，Redis重启时会重新执行AOF文件中的命令达到恢复数据的目的。AOF的主要作用是解决了数据持久化的实时性，AOF 是Redis持久化的主流方式。

默认情况下Redis没有开启AOF方式的持久化，可以通过appendonly参数启用：appendonly yes。开启AOF方式持久化后每执行一条写命令，Redis就会将该命令写进aof_buf缓冲区，AOF缓冲区根据对应的策略向硬盘做同步操作。

默认情况下系统每30秒会执行一次同步操作。为了防止缓冲区数据丢失，可以在Redis写入AOF文件后主动要求系统将缓冲区数据同步到硬盘上。可以通过appendfsync参数设置同步的时机。

appendfsync always //每次写入aof文件都会执行同步，最安全最慢，不建议配置
appendfsync everysec  //既保证性能也保证安全，建议配置
appendfsync no //由操作系统决定何时进行同步操作

接下来看一下 AOF 持久化执行流程：

  1. 所有的写入命令会追加到 AOP 缓冲区中。
  2. AOF 缓冲区根据对应的策略向硬盘同步。
  3. 随着 AOF 文件越来越大，需要定期对 AOF 文件进行重写，达到压缩文件体积的目的。AOF文件重写是把Redis进程内的数据转化为写命令同步到新AOF文件的过程。
  4. 当 Redis 服务器重启时，可以加载 AOF 文件进行数据恢复。

优点：

  1. AOF可以更好的保护数据不丢失，可以配置 AOF 每秒执行一次fsync操作，如果Redis进程挂掉，最多丢失1秒的数据。
  2. AOF以append-only的模式写入，所以没有磁盘寻址的开销，写入性能非常高。

缺点：

  1. 对于同一份文件AOF文件比RDB数据快照要大。
  2. 数据恢复比较慢。

RDF和AOF的区别？

  1. 记录的数据不一样：
    • RDB 快照就是记录某一个瞬间的内存数据，记录的是实际数据，而 AOF 文件记录的是命令操作的日志
    • AOF 文件的内容是操作命令；RDB 文件的内容是二进制数据。
  2. 恢复数据和执行频率：
    • RDB是全量快照，恢复数据更快，AOF则需要额外执行操作命令，相对更慢。
    • RDB是全量快照，不宜频繁执行，而AOF数据文件更新比较及时，比RDB保存更完整的数据，这样在数据恢复时能够恢复尽量完整的数据，降低丢失数据的风险。因此发生故障时，RDB丢失的数据会比 AOF 持久化的方式更多
  3. 是否影响主进程
    • AOF的Always写回策略是主进程执行的，总是调用fsync函数；Everysec异步执行，不影响主线程；No则redis不控制写回，最终交给操作系统决定何时写回；不影响主线程。
    • RDB可以将工作交给子进程来做，此时Redis主线程还可以继续处理操作命令。

如果同时存在RDB文件和AOF文件，Redis会优先使用AOF文件进行数据恢复。

RDB和AOF如何选择？

RDB 比 AOF 的数据恢复速度快，但是快照的频率不好把握：

  • 如果频率太低，两次快照间一旦服务器发生宕机，就可能会比较多的数据丢失；
  • 如果频率太高，频繁写入磁盘和创建子进程会带来额外的性能开销。

因此可以使用混合持久化，混合持久化就是混合使用 AOF 日志和RDB

混合持久化工作在 AOF日志重写过程中：
会把 Redis 的持久化数据，以 RDB 的格式写入到 AOF 文件的开头，之后写时复制时修改数据再以 AOF 的格式化追加的文件的末尾，写入完成后再新的含有 RDB 格式和 AOF 格式的 AOF 文件替换旧的的 AOF 文件。

也就是说，使用了混合持久化，AOF 文件的前半部分是 RDB 格式的全量数据，后半部分是 AOF 格式的增量数据。

优点：

  • 混合持久化结合了 RDB 和 AOF 持久化的优点，开头为 RDB 的格式，使得 Redis 可以更快的恢复数据，同时结合 AOF 的优点，减低了大量数据丢失的风险。

缺点：

  • AOF 文件中添加了 RDB 格式的内容，使得 AOF 文件的可读性变得很差；
  • 兼容性差，如果开启混合持久化，那么此混合持久化 AOF 文件，就不能用在 Redis 4.0 之前版本了。

高可用

Redis有哪些部署方案？

  • 单机版*：单机部署，单机redis能够承载的 QPS 大概就在上万到几万不等。这种部署方式很少使用。存在的问题：1、内存容量有限 2、处理能力有限 3、无法高可用。
  • 主从模式：一主多从，主负责写，并且将数据复制到其它的 slave 节点，从节点负责读。所有的读请求全部走从节点。这样也可以很轻松实现水平扩容，支撑读高并发。master 节点挂掉后，需要手动指定新的 master，可用性不高，基本不用。
  • 哨兵模式：主从复制存在不能自动故障转移、达不到高可用的问题。哨兵模式解决了这些问题。通过哨兵机制可以自动切换主从节点。master 节点挂掉后，哨兵进程会主动选举新的 master，可用性高，但是每个节点存储的数据是一样的，浪费内存空间。数据量不是很多，集群规模不是很大，需要自动容错容灾的时候使用。
  • Redis cluster：服务端分片技术，3.0版本开始正式提供。Redis Cluster并没有使用一致性hash，而是采用slot(槽)的概念，一共分成16384个槽。将请求发送到任意节点，接收到请求的节点会将查询请求发送到正确的节点上执行。主要是针对海量数据+高并发+高可用的场景，如果是海量数据，如果你的数据量很大，那么建议就用Redis cluster，所有主节点的容量总和就是Redis cluster可缓存的数据容量。

主从架构

单机的 redis，能够承载的 QPS 大概就在上万到几万不等。对于缓存来说，一般都是用来支撑读高并发的。因此架构做成主从(master-slave)架构，一主多从，主负责写，并且将数据复制到其它的 slave 节点，从节点负责读。所有的读请求全部走从节点。这样也可以很轻松实现水平扩容，支撑读高并发。

Redis的复制功能是支持多个数据库之间的数据同步。主数据库可以进行读写操作，当主数据库的数据发生变化时会自动将数据同步到从数据库。从数据库一般是只读的，它会接收主数据库同步过来的数据。一个主数据库可以有多个从数据库，而一个从数据库只能有一个主数据库。

主从复制的原理？

详情请查看：主从复制

  1. 当启动一个从节点时，它会发送一个 PSYNC 命令给主节点；
  2. 如果是从节点初次连接到主节点，那么会触发一次全量复制。此时主节点会启动一个后台线程，开始生成一份 RDB 快照文件；
  3. 同时还会将从客户端 client 新收到的所有写命令缓存在内存中。RDB 文件生成完毕后， 主节点会将RDB文件发送给从节点，从节点会先将RDB文件写入本地磁盘，然后再从本地磁盘加载到内存中；
  4. 接着主节点会将内存中缓存的写命令发送到从节点，从节点同步这些数据；
  5. 如果从节点跟主节点之间网络出现故障，连接断开了，会自动重连，连接之后主节点仅会将部分缺失的数据同步给从节点。

主从复制存在的问题

Redis的主从模式重点在于解决整体的承压能力，利用从节点分担读取操作的压力。但是其在容错恢复等可靠性层面欠缺明显，不具备自动的故障转移与恢复能力：

  • 如果slave从节点宕机，整个redis依旧可以正常提供服务，待slave节点重新启动后，可以恢复从master节点的数据同步、然后继续提供服务。
  • 如果master主节点宕机，则redis功能受损，无法继续提供写服务，直到手动修复master节点方可恢复。

当然，master节点故障后，也可以手动将其中一个从节点切换为新的master节点来恢复故障。而原先的master节点恢复后，需要手动将其降级为slave节点，对外提供只读服务。

实际使用的时候，手动故障恢复的时效无法得到保证，为了支持自动的故障转移与恢复能力，Redis在主从模式的基础上进行优化增强，提供了哨兵（Sentinel）架构模式。

那么就需要有一个机制，能够监测主节点是否存活，如果发现主节点挂了，就选举一个从节点切换为主节点，并且把新主节点的相关信息通知给从节点和客户端。这就是哨兵机制

哨兵Sentinel工作原理？

详情请查看：哨兵机制

  • 每个Sentinel以每秒钟一次的频率向它所知道的Master，Slave以及其他 Sentinel 实例发送一个 PING命令。
  • 如果一个实例距离最后一次有效回复 PING 命令的时间超过指定值， 则这个实例会被 Sentine 标记为主观下线。
  • 如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master是否真正进入主观下线状态。
  • 当有足够数量的 Sentinel（大于等于配置文件指定值）在指定的时间范围内确认Master的确进入了主观下线状态， 则Master会被标记为客观下线 。若没有足够数量的 Sentinel 同意 Master 已经下线， Master 的客观下线状态就会被解除。 若 Master重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除。
  • 哨兵节点会选举出哨兵 leader，负责故障转移的工作。
  • 哨兵 leader 会推选出某个表现良好的从节点成为新的主节点，然后通知其他从节点更新主节点信息。

Redis cluster

详情请查看：集群

哨兵模式解决了主从复制不能自动故障转移、达不到高可用的问题，但还是存在主节点的写能力、容量受限于单机配置的问题。而cluster模式实现了Redis的分布式存储，每个节点存储不同的内容，解决主节点的写能力、容量受限于单机配置的问题。

Redis cluster集群节点最小配置6个节点以上（3主3从），其中主节点提供读写操作，从节点作为备用节点，不提供请求，只作为故障转移使用。

Redis cluster采用虚拟槽分区，所有的键根据哈希函数映射到0～16383个整数槽内，每个节点负责维护一部分槽以及槽所映射的键值数据。

工作原理：

  1. 通过哈希的方式，将数据分片，每个节点均分存储一定哈希槽(哈希值)区间的数据，默认分配了16384 个槽位
  2. 每份数据分片会存储在多个互为主从的多节点上
  3. 数据写入先写主节点，再同步到从节点(支持配置为阻塞同步)
  4. 同一分片多个节点间的数据不保持一致性
  5. 读取数据时，当客户端操作的key没有分配在该节点上时，redis会返回转向指令，指向正确的节点
  6. 扩容时时需要需要把旧节点的数据迁移一部分到新节点

在 redis cluster 架构下，每个 redis 要放开两个端口号，比如一个是 6379，另外一个就是 加1w 的端口号，比如 16379。

16379 端口号是用来进行节点间通信的，也就是 cluster bus 的东西，cluster bus 的通信，用来进行故障检测、配置更新、故障转移授权。cluster bus 用了另外一种二进制的协议，gossip 协议，用于节点间进行高效的数据交换，占用更少的网络带宽和处理时间。

优点：

  • 无中心架构，支持动态扩容；
  • 数据按照slot存储分布在多个节点，节点间数据共享，可动态调整数据分布；
  • 高可用性。部分节点不可用时，集群仍可用。集群模式能够实现自动故障转移（failover），节点之间通过gossip协议交换状态信息，用投票机制完成Slave到Master的角色转换。

缺点：

  • 不支持批量操作（pipeline）。
  • 数据通过异步复制，不保证数据的强一致性。
  • 事务操作支持有限，只支持多key在同一节点上的事务操作，当多个key分布于不同的节点上时无法使用事务功能。
  • key作为数据分区的最小粒度，不能将一个很大的键值对象如hash、list等映射到不同的节点。
  • 不支持多数据库空间，单机下的Redis可以支持到16个数据库，集群模式下只能使用1个数据库空间。
  • 只能使用0号数据库。

哈希分区算法有哪些？

  • 节点取余分区。
    使用特定的数据，如Redis的键或用户ID，对节点数量N取余：hash（key）%N计算出哈希值，用来决定数据映射到哪一个节点上。

优点是简单性。扩容时通常采用翻倍扩容，避免数据映射全部被打乱导致全量迁移的情况。

  • 一致性哈希分区。

为系统中每个节点分配一个token，范围一般在0~232，这些token构成一个哈希环。数据读写执行节点查找操作时，先根据key计算hash值，然后顺时针找到第一个大于等于该哈希值的token节点。

这种方式相比节点取余最大的好处在于加入和删除节点只影响哈希环中相邻的节点，对其他节点无影响。

  • 虚拟Hash槽分区

所有的键根据哈希函数映射到0~16383整数槽内，计算公式：slot=CRC16（key）&16383。每一个节点负责维护一部分槽以及槽所映射的键值数据。Redis Cluser采用虚拟槽分区算法。

为什么redis集群采用“hash槽”来解决数据分配问题，而不采用“一致性hash”算法呢？

  • 一致性哈希的节点分布基于圆环，无法很好的手动控制数据分布，比如有些节点的硬件差，希望少存一点数据，这种很难操作（还得通过虚拟节点映射，总之较繁琐）。
  • 而redis集群的槽位空间是可以用户手动自定义分配的，类似于 windows 盘分区的概念，可以手动控制大小。
  • 其实，无论是 “一致性哈希” 还是 “hash槽” 的方式，在增减节点的时候，都会对一部分数据产生影响，都需要我们迁移数据。当然，redis集群也提供了相关手动迁移槽数据的命令。

为什么 Redis 集群的最大槽数是 16384 个？

Redis Cluster 采用数据分片机制，定义了 16384个 Slot槽位，集群中的每个Redis 实例负责维护一部分槽以及槽所映射的键值数据。

Redis每个节点之间会定期发送ping/pong消息（心跳包包含了其他节点的数据），用于交换数据信息。

Redis集群的节点会按照以下规则发ping消息：

  1. 每秒会随机选取5个节点，找出最久没有通信的节点发送ping消息
  2. 每100毫秒都会扫描本地节点列表，如果发现节点最近一次接受pong消息的时间大于cluster-node-timeout/2 则立刻发送ping消息

心跳包的消息头里面有个myslots的char数组，是一个bitmap，每一个位代表一个槽，如果该位为1，表示这个槽是属于这个节点的。

接下来，解答为什么 Redis 集群的最大槽数是 16384 个，而不是65536 个。

  1. 如果采用 16384 个插槽，那么心跳包的消息头占用空间 2KB （16384/8）；如果采用 65536 个插槽，那么心跳包的消息头占用空间 8KB (65536/8)。可见采用 65536 个插槽，发送心跳信息的消息头达8k，比较浪费带宽。
  2. 一般情况下一个Redis集群不会有超过1000个master节点，太多可能导致网络拥堵。
  3. 哈希槽是通过一张bitmap的形式来保存的，在传输过程中，会对bitmap进行压缩。bitmap的填充率越低，压缩率越高。其中bitmap 填充率 = slots / N (N表示节点数)。所以，插槽数越低， 填充率会降低，压缩率会提高。

REDIS集群会有写操作丢失吗？为什么

在Redis集群中，由于采用了主从复制模型的异步复制机制，写操作有一定的丢失风险。

当客户端向主节点发送写操作时，主节点会立即返回成功响应，而不等待所有从节点执行复制。如果主节点在执行完写操作后出现故障或网络问题，导致从节点无法及时接收到复制操作，那么这些未复制的写操作将会丢失。

为了减少写操作丢失的可能性，可以采取以下措施：

  • 定期监测集群状态，确保主从节点之间的复制正常进行；
  • 设置合理的持久化策略，将数据写入磁盘或使用AOF模式以便数据恢复；
  • 在应用程序层实施数据确认机制，检查写操作是否成功。

Redis内存管理

Redis的内存用完了会怎样？

如果达到设置的上限，Redis的写命令会返回错误信息（但是读命令还可以正常返回）。

也可以配置内存淘汰机制，当Redis达到内存上限时会冲刷掉旧的内容。

Redis如何做内存优化？

可以好好利用Hash,list,sorted set,set等集合类型数据，因为通常情况下很多小的Key-Value可以用更紧凑的方式存放到一起。尽可能使用散列表（hashes），散列表（是说散列表里面存储的数少）使用的内存非常小，所以你应该尽可能的将你的数据模型抽象到一个散列表里面。比如你的web系统中有一个用户对象，不要为这个用户的名称，姓氏，邮箱，密码设置单独的key，而是应该把这个用户的所有信息存储到一张散列表里面。

过期key的删除策略？

详情请查看：过期删除策略

  1. 惰性删除。在访问key时，如果发现key已经过期，那么会将key删除。
  2. 定时删除。定时清理key，每次清理会依次遍历所有DB，从db随机取出20个key，如果过期就删除，如果其中有5个key过期，那么就继续对这个db进行清理，否则开始清理下一个db。

定期删除策略原理？

Redis内部维护一个定时任务，默认每秒进行10次(也就是每隔100毫秒一次)过期扫描，过期扫描不会遍历过期字典中所有的 key，而是采用了一种简单的贪心策略。

  1. 从过期字典中随机取出20个key
  2. 删除这 20 个 key 中已经过期的 key；
  3. 如果这20个key中过期key的比例超过了25%，则重复步骤1

为了保证过期扫描不会出现循环过度，导致线程卡死现象，算法还增加了扫描时间的上限，默认不会超过 25ms。

为什么定期删除不是把所有过期 key 都删除呢？

这样会对性能造成太大的影响。如果我们 key 数量非常庞大的话，挨个遍历检查是非常耗时的，会严重影响性能。Redis 设计这种策略的目的是为了平衡内存和性能。

过期key对持久化的影响

RDB：

  • 生成rdb文件：生成时，程序会对key进行检查，过期key不放入rdb文件。
  • 载入rdb文件：载入时，如果以主服务器模式运行，程序会对文件中保存的key进行检查，未过期的key会被载入到数据库中，而过期key则会忽略；如果以从服务器模式运行，无论键过期与否，均会载入数据库中，过期key会通过与主服务器同步而删除。

AOF：

  • 当服务器以AOF持久化模式运行时，如果数据库中的某个key已经过期，但它还没有被惰性删除或者定期删除，那么AOF文件不会因为这个过期key而产生任何影响
  • 当过期key被惰性删除或者定期删除之后，程序会向AOF文件追加一条DEL命令，来显示的记录被该key已经发被删除
  • 在执行AOF重写的过程中，程序会对数据库中的key进行检查，已过期的key不会被保存到重写后的AOF文件中

主从复制：当服务器运行在复制模式下时，从服务器的过期删除动作由主服务器控制：

  • 主服务器在删除一个过期key后，会显式地向所有从服务器发送一个del命令，告知从服务器删除这个过期key;
  • 从服务器在执行客户端发送的读命令时，即使碰到过期key也不会将过期key删除，而是继续像处理未过期的key一样来处理过期key;
  • 从服务器只有在接到主服务器发来的del命令后，才会删除过期key。

内存淘汰策略有哪些？

当Redis的内存超过最大允许的内存之后，Redis 会触发内存淘汰策略，删除一些不常用的数据，以保证Redis服务器正常运行。

  • volatile-lru：针对设置了过期时间的key，使用lru算法进行淘汰。
  • allkeys-lru：针对所有key使用lru算法进行淘汰。
  • volatile-lfu：针对设置了过期时间的key，使用lfu算法进行淘汰。
  • allkeys-lfu：针对所有key使用lfu算法进行淘汰。
  • volatile-random：针对设置了过期时间的key中使用随机淘汰的方式进行淘汰。
  • allkeys-random：针对所有key使用随机淘汰机制进行淘汰。
  • volatile-ttl：针对设置了过期时间的key，越早过期的越先被淘汰。

Redis对随机淘汰和LRU策略进行的更精细化的实现，支持将淘汰目标范围细分为全部数据和设有过期时间的数据，这种策略相对更为合理一些。因为一般设置了过期时间的数据，本身就具备可删除性，将其直接淘汰对业务不会有逻辑上的影响；而没有设置过期时间的数据，通常是要求常驻内存的，往往是一些配置数据或者是一些需要当做白名单含义使用的数据（比如用户信息，如果用户信息不在缓存里，则说明用户不存在），这种如果强行将其删除，可能会造成业务层面的一些逻辑异常。

内存淘汰策略可以通过配置文件来修改，相应的配置项是maxmemory-policy，默认配置是noeviction。

缓存常见问题

MySQL 与 Redis 如何保证数据一致性？

具体看这篇文章：缓存和数据库一致性问题

缓存雪崩

在使用缓存时，通常会对缓存设置过期时间，一方面目的是保持缓存与数据库数据的一致性，另一方面是减少冷缓存占用过多的内存空间。

那么，当大量缓存数据在短时间集体失效或者 Redis 故障宕机时，请求全部转发到数据库，从而导致数据库压力骤增，甚至宕机，从而形成一系列连锁反应，造成整个系统崩溃，这就是缓存雪崩的问题。

所以，发生缓存雪崩的场景通常有两个：

  • 大量热点key同时过期；
  • 缓存服务故障；

大量热点key同时过期

针对大量数据同时过期而引发的缓存雪崩问题，常见的应对方法有下面这几种：

  1. 均匀失效（建议）：将key的过期时间后面加上一个随机数（比如随机1-5分钟）
    • 如果要给缓存数据设置过期时间，应该避免将大量的数据设置成同一个过期时间。就可以给这些数据的过期时间加上一个随机数，这样就保证数据不会在同一时间过期。
  2. 考虑用队列或者互斥锁的方式，保证缓存单线程写，但这种方案可能会影响并发量，不建议。
    • 当业务线程在处理用户请求时，如果发现访问的数据不在 Redis 里，就加个互斥锁，保证同一时间内只有一个请求来构建缓存（从数据库读取数据，再将数据更新到 Redis 里。也就不会有大量的热点数据需要从数据库读取数据了），即保证缓存单线程写。
    • 实现互斥锁的时候，最好设置超时时间，防止线程出现意外一直阻塞导致其它请求也无法获取锁。
  3. 可以让热点数据永久有效（不推荐，一般都会要求必须设置过期时间），后台异步更新缓存，适用于不严格要求缓存一致性的场景。
    • 事实上即使数据永久有效，数据也不一定会一直在内存中，这是因为 Redis的内存淘汰策略 ，当系统内存紧张的时候，有些缓存数据会被“淘汰”。如果此时用户读取的是淘汰数据，那就有可能会返回空值，误以为数据丢失了。解决方式：
    • 后台频繁地检测缓存是否有效，如果检测到缓存失效了，那就从数据库读取数据，并更新到缓存。但这个频繁 的时间不好掌握，总会有时间间隔，间隔时间内就有可能导致空值的返回；
    • 用户读取数据时，发现数据不在Redis中，则通知后台线程更新缓存。后台线程收到消息后，发现数据不存在就读取数据库数据，并将数据加载到缓存。
  4. 双key策略，主key设置过期时间，备key不设置过期时间，当主key失效时，直接返回备key值。
    • 这个只是 key 不一样，但是 value 值是一样的，相当于给缓存数据做了个副本。但是在更新缓存时，需要同时更新「主 key 」和「备 key 」的数据。
    • 双 key 策略的好处是，当主 key 过期了，有大量请求获取缓存数据的时候，直接返回备 key 的数据，这样可以快速响应请求。而不用因为 key 失效而导致大量请求被锁阻塞住（采用了互斥锁，仅一个请求来构建缓存），后续再通知后台线程，重新构建主 key 的数据。
    • 但是需要同时存储两份数据，增大了内存开销

缓存服务故障

  1. 构建缓存高可用集群（针对缓存服务故障情况）。
    • 如果 Redis 缓存的主节点故障宕机，从节点可以切换成为主节点，继续提供缓存服务，避免了由于 Redis 故障宕机而导致的缓存雪崩问题
  2. 当缓存雪崩发生时，可以实行服务熔断、限流、降级等措施进行保障。
    • 服务熔断机制，就是暂停业务应用对缓存服务的访问，直接返回错误，也就不用再继续访问数据库，从而降低对数据库的访问压力，保证数据库系统的正常运行，然后等到 Redis 恢复正常后，再允许业务应用访问缓存服务。这种方式就是暂停了业务访问
    • 请求限流机制，就是只将少部分请求发送到数据库进行处理，再多的请求就在入口直接拒绝服务，等到 Redis 恢复正常并把缓存预热完后，再解除请求限流的机制。

缓存击穿

缓存雪崩是指大量热点key同时失效的情况，如果是单个热点key，一直都有着大并发访问，那么在这个key失效的瞬间，这个大并发请求就会击破缓存，直接请求到数据库，好像蛮力击穿一样。这种情况就是缓存击穿（Cache Breakdown）。

缓存击穿和前面提到的缓存雪崩产生的原因其实很相似。区别点在于：

  • 缓存雪崩是大面积的缓存失效导致大量请求涌入数据库。
  • 缓存击穿是少量缓存失效的时候恰好失效的数据遭遇大并发量的请求，导致这些请求全部涌入数据库中。

因此可以将缓存击穿视为缓存雪崩的子集，应对方案也是缓存雪崩说到的方案。

解决方案：

  1. 过期时间续期：比如每次请求的时候自动将过期时间续期一下

  2. 使用互斥锁（Mutex Key）：当缓存不可用时，仅持锁的线程负责从数据库中查询数据并写入缓存中，其余请求重试时先尝试从缓存中获取数据，避免所有的并发请求全部同时打到数据库上。步骤如下：

    1. 没有命中缓存的时候，先请求获取分布式锁，获取到分布式锁的线程，执行DB查询操作，然后将查询结果写入到缓存中；

    2. 没有抢到分布式锁的请求，原地自旋等待一定时间后进行再次重试；

    3. 未抢到锁的线程，再次重试的时候，先尝试去缓存中获取下是否能获取到数据，如果可以获取到数据，则直接取缓存已有的数据并返回；否则重复上述1、2、3步骤。

  3. 逻辑过期：热点数据不设置过期时间，后台异步更新缓存，适用于不严格要求缓存一致性的场景。

对于业务中最常使用的旁路型缓存而言，通常会先读取缓存，如果不存在则去数据库查询，并将查询到的数据添加到缓存中，这样就可以使得后面的请求继续命中缓存。

但是这种常规操作存在个“漏洞”，因为大部分缓存容量有限制，且很多场景会基于LRU策略进行内存中热点数据的淘汰，假如有个恶意程序(比如爬虫)一直在刷历史数据，容易将内存中的热点数据变为历史数据，导致真正的用户请求被打到数据库层。

针对这种场景，在缓存的设计时，需要考虑到对这种冷数据的加热机制进行一些额外处理，如设定一个门槛，如果指定时间段内对一个冷数据的访问次数达到阈值，则将冷数据加热，添加到热点数据缓存中，并设定一个独立的过期时间，来解决此类问题。

比如可以约定同一秒内对某条冷数据的请求超过10次，则将此条冷数据加热作为临时热点数据存入缓存，设定缓存过期时间为30天。通过这样的机制，来解决冷数据的突然窜热对系统带来的不稳定影响。

缓存穿透

缓存穿透（cache penetration）是用户访问的数据既不在缓存当中，也不在数据库中。出于容错的考虑，如果从底层数据库查询不到数据，则不写入缓存。这就导致每次请求都会到底层数据库进行查询，缓存也失去了意义。当高并发或有人利用不存在的Key频繁攻击时，数据库的压力骤增，甚至崩溃，这就是缓存穿透问题。

缓存穿透与缓存击穿同样非常相似，区别点在于缓存穿透的实际请求数据在数据库中也没有，而缓存击穿是仅仅在缓存中没命中，但是在数据库中其实是存在对应数据的。

发生场景：

  • 原来数据是存在的，但由于某些原因（误删除、主动清理等）在缓存和数据库层面被删除了，但前端或前置的应用程序依旧保有这些数据；
  • 黑客恶意攻击，外部爬虫，故意大量访问某些读取不存在数据的业务；

缓存穿透解决方案：

  1. 缓存空值（null）或默认值
    • 分析业务请求，如果是正常业务请求时发生缓存穿透现象，可针对相应的业务数据，在数据库查询不存在时，将其缓存为空值（null）或默认值，但是需要注意的是，针对空值的缓存失效时间不宜过长，一般设置为5分钟之内。当数据库被写入或更新该key的新数据时，缓存必须同时被刷新，避免数据不一致。
  2. 业务逻辑前置校验
    • 在业务请求的入口处进行数据合法性校验，检查请求参数是否合理、是否包含非法值、是否恶意请求等，提前有效阻断非法请求。比如，根据年龄查询时，请求的年龄为-10岁，这显然是不合法的请求参数，直接在参数校验时进行判断返回。
  3. 使用 布隆过滤器快速判断数据不存在（推荐）
    • 在写入数据时，使用布隆过滤器进行标记（相当于设置白名单），业务请求发现缓存中无对应数据时，可先通过查询布隆过滤器判断数据是否在白名单内（布隆过滤器可以判断数据一定不存在），如果不在白名单内，则直接返回空或失败。
  4. 用户黑名单限制：当发生异常情况时，实时监控访问的对象和数据，分析用户行为，针对故意请求、爬虫或攻击者，进行特定用户的限制；
  5. 添加反爬策略：比如添加请求签名校验机制、比如添加IP访问限制策略等等

缓存预热

缓存预热就是系统上线后，将相关的缓存数据直接加载到缓存系统。这样就可以避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题！用户直接查询事先被预热的缓存数据！

解决方案：

  1. 直接写个缓存刷新页面，上线时手工操作一下；
  2. 数据量不大，可以在项目启动的时候自动进行加载；
  3. 定时刷新缓存；

缓存降级

当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级。

缓存降级的最终目的是保证核心服务可用，即使是有损的。而且有些服务是无法降级的（如加入购物车、结算）。

在进行降级之前要对系统进行梳理，看看系统是不是可以丢卒保帅；从而梳理出哪些必须誓死保护，哪些可降级；比如可以参考日志级别设置预案：

  1. 一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级；
  2. 警告：有些服务在一段时间内成功率有波动（如在95~100%之间），可以自动降级或人工降级，并发送告警；
  3. 错误：比如可用率低于90%，或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级；
  4. 严重错误：比如因为特殊原因数据错误了，此时需要紧急人工降级。

服务降级的目的，是为了防止Redis服务故障，导致数据库跟着一起发生雪崩问题。因此，对于不重要的缓存数据，可以采取服务降级策略，例如一个比较常见的做法就是，Redis出现问题，不去数据库查询，而是直接返回默认值给用户。

分布式锁

详情请查看：Redis实现分布式锁

LUA脚本

Redis 通过 LUA 脚本创建具有原子性的命令： 当lua脚本命令正在运行的时候，不会有其他脚本或 Redis 命令被执行，实现组合命令的原子操作。

在Redis中执行Lua脚本有两种方法：eval和evalsha。eval命令使用内置的 Lua 解释器，对 Lua 脚本进行求值。

//第一个参数是lua脚本，第二个参数是键名参数个数，剩下的是键名参数和附加参数
> eval "return {KEYS[1],KEYS[2],ARGV[1],ARGV[2]}" 2 key1 key2 first second
1) "key1"
2) "key2"
3) "first"
4) "second"

lua脚本作用

  1. Lua脚本在Redis中是原子执行的，执行过程中间不会插入其他命令。
  2. Lua脚本可以将多条命令一次性打包，有效地减少网络开销。

使用Redis + lua方式可能存在的问题？

  1. 不可重入性。同一个线程无法多次获取同一把锁
  2. 不可重试。获取锁只尝试一次就返回false，没有重试机制
  3. 超时释放。锁超时释放虽然可以避免死锁，但如果是业务执行耗时较长，也会导致锁的释放，存在安全隐患
  4. 主从一致性。如果Redis是主从集群，主从同步存在延迟，当主机宕机时，从成为了主，但可能存在从此时还未完成同步，因此从上就没有锁标识，此时会出现线程安全问题。

什么是Reddsion?

RLock是Redisson分布式锁的最核心接口，继承了concurrent包的Lock接口和自己的RLockAsync接口，RLockAsync的返回值都是RFuture，是Redisson执行异步实现的核心逻辑，也是Netty发挥的主要阵地。

什么是RedLock？

Redis 官方站提出了一种权威的基于 Redis 实现分布式锁的方式名叫 Redlock，此种方式比原先的单节点的方法更安全。它可以保证以下特性：

  1. 安全特性：互斥访问，即永远只有一个 client 能拿到锁
  2. 避免死锁：最终 client 都可能拿到锁，不会出现死锁的情况，即使原本锁住某资源的 client 挂掉了
  3. 容错性：只要大部分 Redis 节点存活就可以正常提供服务

Redis常见性能问题

常见性能问题和解决方案？

  1. Master最好不要做任何持久化工作，包括内存快照和AOF日志文件，特别是不要启用内存快照做持久化。
  2. 如果数据比较关键，某个Slave开启AOF备份数据，策略为每秒同步一次。
  3. 为了主从复制的速度和连接的稳定性，Slave和Master最好在同一个局域网内。
  4. 尽量避免在压力较大的主库上增加从库
  5. Master调用BGREWRITEAOF重写AOF文件，AOF在重写的时候会占大量的CPU和内存资源，导致服务load过高，出现短暂服务暂停现象。
  6. 为了Master的稳定性，主从复制不要用图状结构，用单向链表结构更稳定，即主从关系为：Master<–Slave1<–Slave2<–Slave3…，这样的结构也方便解决单点故障问题，实现Slave对Master的替换，也即，如果Master挂了，可以立马启用Slave1做Master，其他不变。

使用批量操作减少网络传输

一个 Redis 命令的执行可以简化为以下 4 步：

  1. 发送命令
  2. 命令排队
  3. 命令执行
  4. 返回结果

其中，第 1 步和第 4 步耗费时间之和称为 Round Trip Time (RTT,往返时间) ，也就是数据在网络上传输的时间。

使用批量操作可以减少网络传输次数，进而有效减小网络开销，大幅减少 RTT。

另外，除了能减少 RTT 之外，发送一次命令的 socket I/O 成本也比较高（涉及上下文切换，存在read()和write()系统调用），批量操作还可以减少 socket I/O 成本。这个在官方对 pipeline 的介绍中有提到：https://redis.io/docs/manual/pipelining/ 。

Redis 中有一些原生支持批量操作的命令，比如：

  • MGET(获取一个或多个指定 key 的值)、MSET(设置一个或多个指定 key 的值)、
  • HMGET(获取指定哈希表中一个或者多个指定字段的值)、HMSET(同时将一个或多个 field-value 对设置到指定哈希表中)、
  • SADD（向指定集合添加一个或多个元素）
  • ……

不过，在 Redis 官方提供的分片集群解决方案 Redis Cluster 下，使用这些原生批量操作命令可能会存在一些小问题需要解决。就比如说 MGET 无法保证所有的 key 都在同一个 hash slot（哈希槽）上，MGET可能还是需要多次网络传输，原子操作也无法保证了。不过，相较于非批量操作，还是可以节省不少网络传输次数。

整个步骤的简化版如下（通常由 Redis 客户端实现，无需我们自己再手动实现）：

  1. 找到 key 对应的所有 hash slot；
  2. 分别向对应的 Redis 节点发起 MGET 请求获取数据；
  3. 等待所有请求执行结束，重新组装结果数据，保持跟入参 key 的顺序一致，然后返回结果。

如果想要解决这个多次网络传输的问题，比较常用的办法是自己维护 key 与 slot 的关系。不过这样不太灵活，虽然带来了性能提升，但同样让系统复杂性提升。

pipeline的作用？

redis客户端执行一条命令分4个过程： 发送命令、命令排队、命令执行、返回结果。使用pipeline可以批量请求，批量返回结果，执行速度比逐条执行要快。

使用pipeline组装的命令个数不能太多，不然数据量过大，增加客户端的等待时间，还可能造成网络阻塞，可以将大量命令的拆分多个小的pipeline命令完成。

原生批命令（mset和mget）与pipeline对比：

  1. 原生批命令是原子性，pipeline是非原子性。pipeline命令中途异常退出，之前执行成功的命令不会回滚。
  2. 原生批命令只有一个命令，但pipeline支持多命令。

pipeline 和 Redis 事务的对比？

  • 事务是原子操作，pipeline 是非原子操作。两个不同的事务不会同时运行，而 pipeline 可以同时以交错方式执行。
  • Redis 事务中每个命令都需要发送到服务端，而 Pipeline 只需要发送一次，请求次数更少。

事务可以看作是一个原子操作，但其实并不满足原子性。当我们提到 Redis 中的原子操作时，主要指的是这个操作（比如事务、Lua 脚本）不会被其他操作（比如其他事务、Lua 脚本）打扰，并不能完全保证这个操作中的所有写命令要么都执行要么都不执行。这主要也是因为 Redis 是不支持回滚操作。

说说为什么Redis过期了为什么内存没释放？

第一种情况，可能是覆盖之前的key，导致key过期时间发生了改变。

当一个key在Redis中已经存在了，但是由于一些误操作使得key过期时间发生了改变，从而导致这个key在应该过期的时间内并没有过期，从而造成内存的占用。

第二种情况是，Redis过期key的处理策略导致内存没释放。

一般Redis对过期key的处理策略有两种：惰性删除和定时删除。

先说惰性删除的情况

当一个key已经确定设置了xx秒过期同时中间也没有修改它，xx秒之后它确实已经过期了，但是惰性删除的策略它并不会马上删除这个key，而是当再次读写这个key时它才会去检查是否过期，如果过期了就会删除这个key。也就是说，惰性删除策略下，就算key过期了，也不会立刻释放内容，要等到下一次读写这个key才会删除key。

而定时删除会在一定时间内主动淘汰一部分已经过期的数据，默认的时间是每100ms过期一次。因为定时删除策略每次只会淘汰一部分过期key，而不是所有的过期key，如果redis中数据比较多的话要是一次性全量删除对服务器的压力比较大，每一次只挑一批进行删除，所以很可能出现部分已经过期的key并没有及时的被清理掉，从而导致内存没有即时被释放。

Redis突然变慢，有哪些原因？

  1. 存在bigkey。如果Redis实例中存储了 bigkey，那么在淘汰删除 bigkey 释放内存时，也会耗时比较久。应该避免存储 bigkey，降低释放内存的耗时。

  2. 如果Redis 实例设置了内存上限 maxmemory，有可能导致 Redis 变慢。当 Redis 内存达到 maxmemory 后，每次写入新的数据之前，Redis 必须先从实例中踢出一部分数据，让整个实例的内存维持在 maxmemory 之下，然后才能把新数据写进来。

  3. 开启了内存大页。当 Redis 在执行后台 RDB 和 AOF rewrite 时，采用 fork 子进程的方式来处理。但主进程 fork 子进程后，此时的主进程依旧是可以接收写请求的，而进来的写请求，会采用 Copy On Write（写时复制）的方式操作内存数据。

    什么是写时复制？
    这样做的好处是，父进程有任何写操作，并不会影响子进程的数据持久化。
    不过，主进程在拷贝内存数据时，会涉及到新内存的申请，如果此时操作系统开启了内存大页，那么在此期间，客户端即便只修改 10B 的数据，Redis 在申请内存时也会以 2MB 为单位向操作系统申请，申请内存的耗时变长，进而导致每个写请求的延迟增加，影响到 Redis 性能。
    解决方案就是关闭内存大页机制。

  4. 使用了Swap。操作系统为了缓解内存不足对应用程序的影响，允许把一部分内存中的数据换到磁盘上，以达到应用程序对内存使用的缓冲，这些内存数据被换到磁盘上的区域，就是 Swap。当内存中的数据被换到磁盘上后，Redis 再访问这些数据时，就需要从磁盘上读取，访问磁盘的速度要比访问内存慢几百倍。尤其是针对 Redis 这种对性能要求极高、性能极其敏感的数据库来说，这个操作延时是无法接受的。解决方案就是增加机器的内存，让 Redis 有足够的内存可以使用。或者整理内存空间，释放出足够的内存供 Redis 使用

  5. 网络带宽过载。网络带宽过载的情况下，服务器在 TCP 层和网络层就会出现数据包发送延迟、丢包等情况。Redis 的高性能，除了操作内存之外，就在于网络 IO 了，如果网络 IO 存在瓶颈，那么也会严重影响 Redis 的性能。解决方案：1、及时确认占满网络带宽 Redis 实例，如果属于正常的业务访问，那就需要及时扩容或迁移实例了，避免因为这个实例流量过大，影响这个机器的其他实例。2、运维层面，需要对 Redis 机器的各项指标增加监控，包括网络流量，在网络流量达到一定阈值时提前报警，及时确认和扩容。

  6. 频繁短连接。频繁的短连接会导致 Redis 大量时间耗费在连接的建立和释放上，TCP 的三次握手和四次挥手同样也会增加访问延迟。应用应该使用长连接操作 Redis，避免频繁的短连接。

什么是大key？

通常我们会将含有较大数据或含有大量成员、列表数的Key称之为大Key。
以下是对各个数据类型大key的描述：

  • value是STRING类型，它的值超过5MB
  • value是ZSET、Hash、List、Set等集合类型时，它的成员数量超过1w个

上述的定义并不绝对，主要是根据value的成员数量和大小来确定，根据业务场景确定标准。

大Key造成的问题？

  • 客户端超时阻塞：由于 Redis 执行命令是单线程处理，然后在操作大 key 时会比较耗时，那么就会阻塞 Redis，从客户端这一视角看，就是很久很久都没有响应。
  • 网络阻塞：每次获取大 key 产生的网络流量较大，如果一个 key 的大小是 1 MB，每秒访问量为 1000，那么每秒会产生 1000MB 的流量，这对于普通千兆网卡的服务器来说是灾难性的。
  • 工作线程阻塞：如果使用 del 删除大 key 时，会阻塞工作线程，这样就没办法处理后续的命令。
  • 持久化阻塞（磁盘IO）：对AOF 日志的影响
    • 使用Always 策略的时候，主线程在执行完命令后，会把数据写入到 AOF 日志文件，然后会调用 fsync() 函数，将内核缓冲区的数据直接写入到硬盘，等到硬盘写操作完成后，该函数才会返回。因此当使用 Always 策略的时候，如果写入是一个大 Key，主线程在执行 fsync() 函数的时候，阻塞的时间会比较久，因为当写入的数据量很大的时候，数据同步到硬盘这个过程是很耗时的。
    • 另外两种策略都不影响主线程

大 key 造成的阻塞问题还会进一步影响到主从同步和集群扩容。

大key怎么处理？

  1. 压缩数据：当vaule是string时，可以使用序列化、压缩算法将key的大小控制在合理范围内，但是序列化和反序列化都会带来更多时间上的消耗。或者将key进行拆分，一个大key分为不同的部分，记录每个部分的key，使用multiget等操作实现事务读取。
  2. 分拆大Key ：当value是list/set等集合类型时，根据预估的数据规模来进行分片，不同的元素计算后分到不同的片。

什么是 hotkey？

如果一个 key 的访问次数比较多且明显多于其他 key 的话，那这个 key 就可以看作是 hotkey（热 Key）。例如在 Redis 实例的每秒处理请求达到 5000 次，而其中某个 key 的每秒访问量就高达 2000 次，那这个 key 就可以看作是 hotkey。

hotkey 出现的原因主要是某个热点数据访问量暴增，如重大的热搜事件、参与秒杀的商品。

hotkey 有什么危害？

处理 hotkey 会占用大量的 CPU 和带宽，可能会影响 Redis 实例对其他请求的正常处理。此外，如果突然访问 hotkey 的请求超出了 Redis 的处理能力，Redis 就会直接宕机。这种情况下，大量请求将落到后面的数据库上，可能会导致数据库崩溃。

因此，hotkey 很可能成为系统性能的瓶颈点，需要单独对其进行优化，以确保系统的高可用性和稳定性。

如何解决 hotkey？

hotkey 的常见处理以及优化办法如下（这些方法可以配合起来使用）：

  • 读写分离：主节点处理写请求，从节点处理读请求。
  • 使用 Redis Cluster：将热点数据分散存储在多个 Redis 节点上。
  • 本地缓存：使用本地缓存来缓解Redis的压力，从而减少对hotkey的直接访问。

慢查询命令

经常使用O(n)以上复杂度的命令，由于Redis是单线程执行命令，因此这种情况Redis处理数据时就会很耗时。例如

  • sort：对列表（list）、集合（set）、有序集合（sorted set）中的元素进行排序。在最简单的情况下（没有权重、没有模式、没有 LIMIT），SORT 命令的时间复杂度近似于 O(n*log(n))
  • sunion：用于计算两个或多个集合的并集。时间复杂度可以描述为 O(N)，其中 N 是所有参与运算集合的元素总数。如果有多个集合，每个集合有不同数量的元素参与运算，那么复杂度会是所有这些集合元素数量的总和。
  • zunionstore：用于计算一个或多个有序集合的并集，并将结果存储到一个新的有序集合中。在最简单的情况下，ZUNIONSTORE 命令的时间复杂度是 O(N*log(N))，其中 N 是所有参与计算的集合中元素的总数。
  • keys * ：获取所有的 key 操作；复杂度O(n)，数据量越大执行速度越慢；可以使用scan命令替代
  • Hgetall：返回哈希表中所有的字段和；
  • smembers：返回集合中的所有成员；

解决方案就是，不使用这些复杂度较高的命令，并且一次不要获取太多的数据，每次尽量操作少量的数据，让Redis可以及时处理返回

keys命令存在的问题？如何高效安全的遍历所有key？

redis的单线程的。keys指令会导致线程阻塞一段时间，直到执行完毕，服务才能恢复。scan采用渐进式遍历的方式来解决keys命令可能带来的阻塞问题，每次scan命令的时间复杂度是O(1)，但是要真正实现keys的功能，需要执行多次scan。

scan的缺点：在scan的过程中如果有键的变化（增加、删除、修改），遍历过程可能会有以下问题：新增的键可能没有遍历到，遍历出了重复的键等情况，也就是说scan并不能保证完整的遍历出来所有的键。

什么是内存碎片?为什么会有 Redis 内存碎片?

可以将内存碎片简单地理解为那些不可用的空闲内存。

当数据删除后，Redis 释放的内存空间会由内存分配器管理，并不会立即返回给操作系统。所以，操作系统仍然会记录着给 Redis 分配了大量内存。而Redis 释放的内存空间可能并不是连续的，那么，这些不连续的内存空间很有可能处于一种闲置的状态。也就产生了内存碎片

举个例子：操作系统为你分配了 32 字节的连续内存空间，而你存储数据实际只需要使用 24 字节内存空间，那这多余出来的 8 字节内存空间如果后续没办法再被分配存储其他数据的话，就可以被称为内存碎片。

Redis 内存碎片虽然不会影响 Redis 性能，但是会增加内存消耗。

如何清理 Redis 内存碎片？

Redis4.0-RC3 版本以后自带了内存整理，可以避免内存碎片率过大的问题。

直接通过 config set 命令将 activedefrag 配置项设置为 yes 即可。

config set activedefrag yes

具体什么时候清理需要通过下面两个参数控制：

# 内存碎片占用空间达到 500mb 的时候开始清理
config set active-defrag-ignore-bytes 500mb
# 内存碎片率大于 1.5 的时候开始清理
config set active-defrag-threshold-lower 50

通过 Redis 自动内存碎片清理机制可能会对 Redis 的性能产生影响，我们可以通过下面两个参数来减少对 Redis 性能的影响：

# 内存碎片清理所占用 CPU 时间的比例不低于 20%
config set active-defrag-cycle-min 20
# 内存碎片清理所占用 CPU 时间的比例不高于 50%
config set active-defrag-cycle-max 50

另外，重启节点可以做到内存碎片重新整理。如果你采用的是高可用架构的 Redis 集群的话，你可以将碎片率过高的主节点转换为从节点，以便进行安全重启。

Redis的Key和Value的设计原则有哪些？

Key 设计原则

  1. 短小精炼： 避免过长：Key 应该尽量短小，以节省内存和提高操作速度，通常不超过 256 字节。
  2. 使用命名空间： 分隔符：使用冒号（:）作为分隔符来组织命名空间，有助于实现 Key 的层级结构管理。 例如 user:1001:profile，可以很好地反映数据的逻辑分层关系。
  3. 避免热 Key： 负载均衡：确保 Key 的分布均匀，避免某单一 Key 承担过多的访问压力，可能需对数据进行分片处理。
  4. 选择唯一和通用的标识方式： 全局唯一性：确保 Key 的唯一性，避免不同数据使用相同的 Key。 结合业务逻辑，如使用用户ID、产品ID等。

Value 设计原则

  1. 选择合适的数据结构：对应使用：根据不同的需求选择适当的数据类型，如 String、List、Set、Hash、Sorted Set 等。 避免存储过大对象：如需存储大对象，建议先进行拆分或压缩。
  2. 限制单个 Value 的大小： 分片存储：对于需要存储大量数据的 Value，可以考虑拆分成多部分存储，以降低单个操作的复杂度。
  3. 合理设置Blob：如果需要存储Blob数据，考虑放在外部存储引擎中，只将引用或索引保存在 Redis。
  4. 利用压缩： 节省空间：对数据进行压缩，以减少内存占用和网络传输时间。
  5. TTL设置： 数据过期：合理使用 TTL 来控制数据的生命周期，避免无用数据长期占用内存。