Redis

redis的线程模型

Redis 内部使用文件事件处理器 file event handler ，这个文件事件处理器是单线程的，所以 Redis 才叫做单线程的模型。它采用 IO 多路复用机制同时监听多个 socket，将产生事件的 socket 压入内存队列中，事件分派器根据 socket 上的事件类型来选择对应的事件处理器进行处理。

文件事件处理器的结构包含 4 个部分：

• 多个 socket
• IO 多路复用程序
• 文件事件分派器
• 事件处理器（连接应答处理器、命令请求处理器、命令回复处理器）

多个 socket 可能会并发产生不同的操作，每个操作对应不同的文件事件，但是 IO 多路复用程序会监听多个 socket，会将产生事件的 socket 放入队列中排队，事件分派器每次从队列中取出一个 socket，根据 socket 的事件类型交给对应的事件处理器进行处理。

来看客户端与 Redis 的一次通信过程：

要明白，通信是通过 socket 来完成的，不懂的同学可以先去看一看 socket 网络编程。

首先，Redis 服务端进程初始化的时候，会将 server socket 的 AE_READABLE 事件与连接应答处理器关联。

客户端 socket01 向 Redis 进程的 server socket 请求建立连接，此时 server socket 会产生一个 AE_READABLE 事件，IO 多路复用程序监听到 server socket 产生的事件后，将该 socket 压入队列中。文件事件分派器从队列中获取 socket，交给连接应答处理器。连接应答处理器会创建一个能与客户端通信的 socket01，并将该 socket01 的 AE_READABLE 事件与命令请求处理器关联。

假设此时客户端发送了一个 set key value 请求，此时 Redis 中的 socket01 会产生 AE_READABLE 事件，IO 多路复用程序将 socket01 压入队列，此时事件分派器从队列中获取到 socket01 产生的 AE_READABLE 事件，由于前面 socket01 的 AE_READABLE 事件已经与命令请求处理器关联，因此事件分派器将事件交给命令请求处理器来处理。命令请求处理器读取 socket01 的 key value 并在自己内存中完成 key value 的设置。操作完成后，它会将 socket01 的 AE_WRITABLE 事件与命令回复处理器关联。

如果此时客户端准备好接收返回结果了，那么 Redis 中的 socket01 会产生一个 AE_WRITABLE 事件，同样压入队列中，事件分派器找到相关联的命令回复处理器，由命令回复处理器对 socket01 输入本次操作的一个结果，比如 ok ，之后解除 socket01 的 AE_WRITABLE 事件与命令回复处理器的关联。

Redis的Mysql的区别

Redis和MySQL的区别总结

类型：Mysql是关系型数据库，redis是非关系型数据库；

数据存放：Mysql持久化到硬盘上，速度比较慢，redis将数据保存在内存中，读取速度比较快

业务场景：Mysql和redis 需要根据具体的业务进行选型，一般来说redis和Mysql需要配合使用；redis适合存放一些热点数据，因为读写速度快，比如排行榜、计数器、消息队列推送

Redis和传统的关系型数据库有什么不同？

Redis是一种基于键值对的NoSQL数据库，而键值对的值是由多种数据结构和算法组成的。Redis的数据都存储于内存中，因此它的速度惊人，读写性能可达10万/秒，远超关系型数据库。

关系型数据库是基于二维数据表来存储数据的，它的数据格式更为严谨，并支持关系查询。关系型数据库的数据存储于磁盘上，可以存放海量的数据，但性能远不如Redis。

Redis常见的数据结构

String：String结构底层是一个简单动态字符串，支持扩容，存储字符串

Hash：hash类型存储的是键值对，底层数据结构是ziplist和hash

list：list存储线性有序且可重复的元素，底层数据结构是双向链表/压缩列表

set: set存储不可重复的元素，一般用于求交集、差集等，底层数据结构是hash和整数数组

zset：zset存储的是有序不可重复的元素，zset为每个元素添加了一个score属性作为排序依据，底层数据结构是ziplist和跳表

geospatioal(地理位置) Hyperloglog(基数 ) Bitmaps(位存储)

zset数据结构

有序集合对象有2种编码方案，当同时满足以下条件时，集合对象采用ziplist编码，否则采用skiplist编码：

• 有序集合保存的元素数量不超过128个；
• 有序集合保存的所有元素的成员长度都小于64字节。

zset对象的底层数据结构包括：压缩列表、字典、跳跃表。

Redis中rehash过程

Redis字典的实现主要涉及三个结构体：字典、哈希表、哈希表节点。其中，每个哈希表节点保存一个键值对，每个哈希表由多个哈希表节点构成，而字典则是对哈希表的进一步封装。这三个结构体的关系如下图所示：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-25rzUfoJ-1682835430066)(D:/学习/JAVA/面经/面试题整理版本.assets/redis-hash-3-20220225114140138.png)]

dict代表字典，dictht代表哈希表，dictEntry代表哈希表节点。

一个字典包含两个哈希表，在Redis中，扩展和收缩哈希表是通过REHASH实现的，执行REHASH的大致步骤如下：

1. 为字典的ht[1]哈希表分配内存空间

   如果执行的是扩展操作，则ht[1]的大小为第1个大于等于ht[0].used*2的2n。如果执行的是收缩操作，则ht[1]的大小为第1个大于等于ht[0].used的2n。

2. 将存储在ht[0]中的数据迁移到ht[1]上

   重新计算键的哈希值和索引值，然后将键值对放置到ht[1]哈希表的指定位置上。

3. 将字典的ht[1]哈希表晋升为默认哈希表

   迁移完成后，清空ht[0]，再交换ht[0]和ht[1]的值，为下一次REHASH做准备。

当满足以下任何一个条件时，程序会自动开始对哈希表执行扩展操作：

1. 服务器目前没有执行bgsave或bgrewriteof命令，并且哈希表的负载因子大于等于1；
2. 服务器目前正在执行bgsave或bgrewriteof命令，并且哈希表的负载因子大于等于5。

为了避免REHASH对服务器性能造成影响，REHASH操作不是一次性地完成的，而是分多次、渐进式地完成的。渐进式REHASH的详细过程如下：

1. 为ht[1]分配空间，让字典同时持有ht[0]和ht[1]两个哈希表；
2. 在字典中的索引计数器rehashidx设置为0，表示REHASH操作正式开始；
3. 在REHASH期间，每次对字典执行添加、删除、修改、查找操作时，程序除了执行指定的操作外，还会顺带将ht[0]中位于rehashidx上的所有键值对迁移到ht[1]中，再将rehashidx的值加1；
4. 随着字典不断被访问，最终在某个时刻，ht[0]上的所有键值对都被迁移到ht[1]上，此时程序将rehashidx属性值设置为-1，标识REHASH操作完成。

REHSH期间，字典同时持有两个哈希表，此时的访问将按照如下原则处理：

1. 新添加的键值对，一律被保存到ht[1]中；
2. 删除、修改、查找等其他操作，会在两个哈希表上进行，即程序先尝试去ht[0]中访问要操作的数据，若不存在则到ht[1]中访问，再对访问到的数据做相应的处理。

redis为什么不考虑线程安全的问题呢

Redis是个单线程程序，所以它是线程安全的。虽然Redis 6.0里面，增加了多线程的模型，但是增加的多线程只是用来处理网络IO事件，对于指令的执行过程，仍然是由主线程来处理，所以不会存在多个线程通知执行操作指令的情况。

Redis单线程为什么还能这么快？

• Redis是基于内存的，内存的读写速度非常快；
• Redis是单线程的，避免了不必要的上下文切换和竞争条件；
• Redis使用多路复用技术，可以处理并发的连接。非阻塞I/O内部实现采用epoll，采用了epoll+自己实现的简单的事件框架。epoll中的读、写、关闭、连接都转化成了事件，然后利用epoll的多路复用特性，绝不在io上浪费一点时间。

为什么Redis是单线程的？

1.官方答案

因为Redis是基于内存的操作，CPU不是Redis的瓶颈，Redis的瓶颈最有可能是机器内存的大小或者网络带宽。既然单线程容易实现，而且CPU不会成为瓶颈，那就顺理成章地采用单线程的方案了。

2.性能指标

关于Redis的性能，官方网站也有，普通笔记本轻松处理每秒几十万的请求。

3.详细原因

1）不需要各种锁的性能消耗

Redis的数据结构并不全是简单的Key-Value，还有list，hash等复杂的结构，这些结构有可能会进行很细粒度的操作，比如在很长的列表后面添加一个元素，在hash当中添加或者删除一个对象。这些操作可能就需要加非常多的锁，导致的结果是同步开销大大增加。

总之，在单线程的情况下，就不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗。

2）单线程多进程集群方案

单线程的威力实际上非常强大，核心效率也非常高，多线程自然是可以比单线程有更高的性能上限，但是在今天的计算环境中，即使是单机多线程的上限也往往不能满足需要了，需要进一步摸索的是多服务器集群化的方案，这些方案中多线程的技术照样是用不上的。

所以单线程、多进程的集群不失为一个时髦的解决方案。

3）CPU消耗

采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU。

但是如果CPU成为Redis瓶颈，或者不想让服务器其他CUP核闲置，那怎么办？

可以考虑多起几个Redis进程，Redis是key-value数据库，不是关系数据库，数据之间没有约束。只要客户端分清哪些key放在哪个Redis进程上就可以了。

redis大key删除

解决方案

• 渐进式删除

  分批删除，通过 scan 命令遍历大key，每次取得少部分元素，对其删除，然后再获取和删除下一批元素

  hash key:通过hscan命令，每次获取500个字段，再用hdel命令；

  set key:使用sscan命令，每次扫描集合中500个元素，再用srem命令每次删除一个元素；

  list key:删除大的List键，未使用scan命令； 通过ltrim命令每次删除少量元素。

  sorted set key:删除大的有序集合键，和List类似，使用sortedset自带的zremrangebyrank命令,每次删除top 100个元素。

• UNLINK (4.0版本以后)。

  Redis 4.0 推出了一个重要命令 UNLINK，用来拯救 del 删大key的困境。

  UNLINK 工作思路：

  （1）在所有命名空间中把 key 删掉，立即返回，不阻塞。

  （2）后台线程执行真正的释放空间的操作。

  UNLINK 基本可以替代 del，但个别场景还是需要 del 的，例如在空间占用积累速度特别快的时候就不适合使用UNLINK，因为 UNLINK 不是立即释放空间。

Redis的高可用、高并发

redis 实现高并发主要依靠主从架构，一主多从，一般来说，很多项目其实就足够了，单主用来写入数据，单机几万 QPS，多从用来查询数据，多个从实例可以提供每秒 10w 的 QPS。

如果想要在实现高并发的同时，容纳大量的数据，那么就需要 redis 集群，使用 redis 集群之后，可以提供每秒几十万的读写并发。

redis 高可用，如果是做主从架构部署，那么加上哨兵就可以了，就可以实现，任何一个实例宕机，可以进行主备切换。

Redis的主从复制

• Redis 采用异步方式复制数据到 slave 节点，不过 Redis2.8 开始，slave node 会周期性地确认自己每次复制的数据量；
• 一个 master node 是可以配置多个 slave node 的；
• slave node 也可以连接其他的 slave node；
• slave node 做复制的时候，不会 block master node 的正常工作；
• slave node 在做复制的时候，也不会 block 对自己的查询操作，它会用旧的数据集来提供服务；但是复制完成的时候，需要删除旧数据集，加载新数据集，这个时候就会暂停对外服务了；
• slave node 主要用来进行横向扩容，做读写分离，扩容的 slave node 可以提高读的吞吐量。

注意，如果采用了主从架构，那么建议必须开启 master node 的持久化，不建议用 slave node 作为 master node 的数据热备，因为那样的话，如果你关掉 master 的持久化，可能在 master 宕机重启的时候数据是空的，然后可能一经过复制， slave node 的数据也丢了。

另外，master 的各种备份方案，也需要做。万一本地的所有文件丢失了，从备份中挑选一份 rdb 去恢复 master，这样才能确保启动的时候，是有数据的，即使采用了后续讲解的高可用机制，slave node 可以自动接管 master node，但也可能 sentinel 还没检测到 master failure，master node 就自动重启了，还是可能导致上面所有的 slave node 数据被清空。

Redis 主从复制的核心原理

主从复制的断点续传

复制的完整流程

全量复制

client-output-buffer-limit slave 256MB 64MB 60Copy to clipboardErrorCopied

增量复制

heartbeat

异步复制

使用redis的注意事项

• 给Key设置过期时间，同时注意不同业务的key，尽量过期时间分散一点

  • 一般建议用expire设置过期时间
  • 如果大量的key在某个时间点集中过期，到过期的那个时间点，Redis可能会存在卡顿，甚至出现缓存雪崩现象，因此一般不同业务的key，过期时间应该分散一些。有时候，同业务的，也可以在时间上加一个随机值，让过期时间分散一些。

• 建议使用批量操作提高效率

  • Redis客户端执行一次命令可分为4个过程：1.发送命令-> 2.命令排队-> 3.命令执行-> 4. 返回结果。1和4 称为RRT（命令执行往返时间）。 Redis提供了批量操作命令，如mget、mset等，可有效节约RRT。但是呢，大部分的命令，是不支持批量操作的，比如hgetall，并没有mhgetall存在。Pipeline 则可以解决这个问题。

• 注意使用del命令

  • 如果删除一个String类型的key，时间复杂度就是O（1），可以直接del。
  • 如果删除一个List/Hash/Set/ZSet类型时，它的复杂度是O(n), n表示元素个数。
  • 如果是List类型，你可以执行lpop或者rpop，直到所有元素删除完成。
  • 如果是Hash/Set/ZSet类型，你可以先执行hscan/sscan/scan查询，再执行hdel/srem/zrem依次删除每个元素。

  使用Redis，你必须知道的21个注意要点 - 知乎 (zhihu.com)

Redis集群有几种模式

• 主从模式

  • 作用
    • 读写分离：master写，slave度，提高服务器的读写负载能力
    • 负载均衡：基于主从结构，配合读写分离，由slave分担master负载，并根据需求的变化，改变slave的数据，通过多个结点分担数据读取负载，大大提高Redis服务器并发量与数据吞吐量
    • 故障恢复：当master出现问题时，由slave提供服务，实现快速的故障恢复
    • 数据冗余：实现数据热备份，是持久化之外的一种数据冗余方式
    • 高可用基石：基于主从复制，构建哨兵模式与集群，实现Redis的高可用方案

• 哨兵模式

  • Redis Sentinel（哨兵）是一个分布式架构，它包含若干个哨兵节点和数据节点。每个哨兵节点会对数据节点和其余的哨兵节点进行监控，当发现节点不可达时，会对节点做下线标识。如果被标识的是主节点，它就会与其他的哨兵节点进行协商，当多数哨兵节点都认为主节点不可达时，它们便会选举出一个哨兵节点来完成自动故障转移的工作，同时还会将这个变化实时地通知给应用方。整个过程是自动的，不需要人工介入，有效地解决了Redis的高可用问题！

    一组哨兵可以监控一个主节点，也可以同时监控多个主节点，两种情况的拓扑结构如下图：

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ZzU3aOMO-1682835430067)(D:/学习/JAVA/面经/面试题整理版本.assets/redis-7-16626934464042.png)]

    ​ 哨兵的作用：

    • 哨兵会定期监控数据节点，其他哨兵节点是否可达

    • 当哨兵发现master宕机时，会自动将salve升级为master，然后通过发布订阅这模式，让其他从服务器修改配置，切换主机，只有当多个节点认为其不可达才可以

      优点：

      1. 主从可以切换，既是一个发生故障也可以使用，系统可用性好
      2. 由多个哨兵节点组成，系统更加健壮

      缺点:

      • 扩容麻烦，配置也麻烦

• Cluster模式

  • redis cluster在设计的时候，就考虑到了去中心化，去中间件，也就是说，集群中的每个节点都是平等的关系，都是对等的，每个节点都保存各自的数据和整个集群的状态。每个节点都和其他所有节点连接，而且这些连接保持活跃，这样就保证了我们只需要连接集群中的任意一个节点，就可以获取到其他节点的数据。

  • 那么redis 是如何合理分配这些节点和数据的呢？

    Redis 集群没有并使用传统的一致性哈希来分配数据，而是采用另外一种叫做哈希槽 (hash slot)的方式来分配的。redis cluster 默认分配了 16384 个slot，当我们set一个key 时，会用CRC16算法来取模得到所属的slot，然后将这个key 分到哈希槽区间的节点上，具体算法就是：CRC16(key) % 16384。

    在redis-cluster架构中，redis-master节点一般用于接收读写，而redis-slave节点则一般只用于备份，其与对应的master拥有相同的slot集合，若某个redis-master意外失效，则再将其对应的slave进行升级为临时redis-master。

(6条消息) Redis集群三种方式_Notail⁰的博客-CSDN博客_redis集群三种方式

说说Redis的持久化策略

RDB AOF RDB-AOF

RDB：使用快照的方式将数据持久化到硬盘上，redis通过快照来保存内存中数据在某一时间节点的副本，是redis的默认持久化机制

AOF：以独立日志的方式记录每一次的对数据进行修改的命令，为了兼顾数据安全和性能，可以选择每一秒同步一次AOF文件

RDP的优点：生成的.rdb文件体积小，持久化速度快；缺点:实时性差容易丢失数据

AOF的有点：实时性相对于RBD来说比较好,使用一秒同步一次的机制,最多只丢失一秒之内的数据；缺点:文件体积大，修复速度慢

RDB-AOF混合：兼顾了RDB和AOF的有点,重写时将RDB文件直接写入到AOF文件的开头,对于重写之后的redis命令，则追加到AOF文件的末尾.

通过 RDB 或 AOF，都可以将 Redis 内存中的数据给持久化到磁盘上面来，然后可以将这些数据备份到别的地方去，比如说阿里云等云服务。

如果 Redis 挂了，服务器上的内存和磁盘上的数据都丢了，可以从云服务上拷贝回来之前的数据，放到指定的目录中，然后重新启动 Redis，Redis 就会自动根据持久化数据文件中的数据，去恢复内存中的数据，继续对外提供服务。

如果同时使用 RDB 和 AOF 两种持久化机制，那么在 Redis 重启的时候，会使用 AOF 来重新构建数据，因为 AOF 中的数据更加完整。

AOF和RDB的优缺点

RDB 优缺点

AOF 优缺点

RDB 和 AOF 到底该如何选择

Redis集群有几种模式

• 主从模式

  • 作用
    • 读写分离：master写，slave度，提高服务器的读写负载能力
    • 负载均衡：基于主从结构，配合读写分离，由slave分担master负载，并根据需求的变化，改变slave的数据，通过多个结点分担数据读取负载，大大提高Redis服务器并发量与数据吞吐量
    • 故障恢复：当master出现问题时，由slave提供服务，实现快速的故障恢复
    • 数据冗余：实现数据热备份，是持久化之外的一种数据冗余方式
    • 高可用基石：基于主从复制，构建哨兵模式与集群，实现Redis的高可用方案

• 哨兵模式

  • Redis Sentinel（哨兵）是一个分布式架构，它包含若干个哨兵节点和数据节点。每个哨兵节点会对数据节点和其余的哨兵节点进行监控，当发现节点不可达时，会对节点做下线标识。如果被标识的是主节点，它就会与其他的哨兵节点进行协商，当多数哨兵节点都认为主节点不可达时，它们便会选举出一个哨兵节点来完成自动故障转移的工作，同时还会将这个变化实时地通知给应用方。整个过程是自动的，不需要人工介入，有效地解决了Redis的高可用问题！

    一组哨兵可以监控一个主节点，也可以同时监控多个主节点，两种情况的拓扑结构如下图：

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ZdCAZ83v-1682835430067)(D:/学习/JAVA/面经/面试题整理版本.assets/redis-7.png)]

    ​ 哨兵的作用：

    • 哨兵会定期监控数据节点，其他哨兵节点是否可达

    • 当哨兵发现master宕机时，会自动将salve升级为master，然后通过发布订阅这模式，让其他从服务器修改配置，切换主机，只有当多个节点认为其不可达才可以

      优点：

      1. 主从可以切换，既是一个发生故障也可以使用，系统可用性好
      2. 由多个哨兵节点组成，系统更加健壮

      缺点:

      • 扩容麻烦，配置也麻烦

• Cluster模式

  • redis cluster在设计的时候，就考虑到了去中心化，去中间件，也就是说，集群中的每个节点都是平等的关系，都是对等的，每个节点都保存各自的数据和整个集群的状态。每个节点都和其他所有节点连接，而且这些连接保持活跃，这样就保证了我们只需要连接集群中的任意一个节点，就可以获取到其他节点的数据。
    那么redis 是如何合理分配这些节点和数据的呢？
    Redis 集群没有并使用传统的一致性哈希来分配数据，而是采用另外一种叫做哈希槽 (hash slot)的方式来分配的。redis cluster 默认分配了 16384 个slot，当我们set一个key 时，会用CRC16算法来取模得到所属的slot，然后将这个key 分到哈希槽区间的节点上，具体算法就是：CRC16(key) % 16384。

    在redis-cluster架构中，redis-master节点一般用于接收读写，而redis-slave节点则一般只用于备份，其与对应的master拥有相同的slot集合，若某个redis-master意外失效，则再将其对应的slave进行升级为临时redis-master。

Redis哨兵集群实现高可用

哨兵介绍

Sentinel，中文名是哨兵。哨兵是 Redis 集群架构中非常重要的一个组件，主要有以下功能：

• 集群监控：负责监控 Redis master 和 slave 进程是否正常工作。
• 消息通知：如果某个 Redis 实例有故障，那么哨兵负责发送消息作为报警通知给管理员。
• 故障转移：如果 master node 挂掉了，会自动转移到 slave node 上。
• 配置中心：如果故障转移发生了，通知 client 客户端新的 master 地址。

哨兵用于实现 Redis 集群的高可用，本身也是分布式的，作为一个哨兵集群去运行，互相协同工作。

• 故障转移时，判断一个 master node 是否宕机了，需要大部分的哨兵都同意才行，涉及到了分布式选举的问题。
• 即使部分哨兵节点挂掉了，哨兵集群还是能正常工作的，因为如果一个作为高可用机制重要组成部分的故障转移系统本身是单点的，那就很坑爹了。

哨兵主从切换导致数据不一致

两种情况

主备切换的过程，可能会导致数据丢失：

• 异步复制导致的数据丢失

因为 master->slave 的复制是异步的，所以可能有部分数据还没复制到 slave，master 就宕机了，此时这部分数据就丢失了。

• 脑裂导致的数据丢失

脑裂，也就是说，某个 master 所在机器突然脱离了正常的网络，跟其他 slave 机器不能连接，但是实际上 master 还运行着。此时哨兵可能就会认为 master 宕机了，然后开启选举，将其他 slave 切换成了 master。这个时候，集群里就会有两个 master ，也就是所谓的脑裂。

此时虽然某个 slave 被切换成了 master，但是可能 client 还没来得及切换到新的 master，还继续向旧 master 写数据。因此旧 master 再次恢复的时候，会被作为一个 slave 挂到新的 master 上去，自己的数据会清空，重新从新的 master 复制数据。而新的 master 并没有后来 client 写入的数据，因此，这部分数据也就丢失了。

解决方案

进行如下配置：

min-slaves-to-write 1
min-slaves-max-lag 10Copy to clipboardErrorCopied

表示，要求至少有 1 个 slave，数据复制和同步的延迟不能超过 10 秒。

如果说一旦所有的 slave，数据复制和同步的延迟都超过了 10 秒钟，那么这个时候，master 就不会再接收任何请求了。

• 减少异步复制数据的丢失

有了 min-slaves-max-lag 这个配置，就可以确保说，一旦 slave 复制数据和 ack 延时太长，就认为可能 master 宕机后损失的数据太多了，那么就拒绝写请求，这样可以把 master 宕机时由于部分数据未同步到 slave 导致的数据丢失降低的可控范围内。

• 减少脑裂的数据丢失

如果一个 master 出现了脑裂，跟其他 slave 丢了连接，那么上面两个配置可以确保说，如果不能继续给指定数量的 slave 发送数据，而且 slave 超过 10 秒没有给自己 ack 消息，那么就直接拒绝客户端的写请求。因此在脑裂场景下，最多就丢失 10 秒的数据。

缓存穿透、缓存击穿、缓存雪崩有什么区别，该如何解决？

参考答案

缓存穿透：

问题描述：

恶意的请求不存在的数据，由于缓存不会命中，接着查询数据库也无法返回查询结果，那么也不会写入到缓存中，这就会导致每一次的请求都会落到数据库上，造成缓存穿透

解决方案：

1. 缓存空对象：存储层未命中后，仍然将空值存入缓存层，客户端再次访问数据时，缓存层会直接返回空值。
2. 布隆过滤器：将数据存入布隆过滤器，访问缓存之前以过滤器拦截，若请求的数据不存在则直接返回空值。

缓存击穿：

问题描述：

一份热点数据，它的访问量非常大。在其缓存失效的瞬间，大量请求直达存储层，导致服务崩溃。

解决方案：

1. 永不过期：热点数据不设置过期时间，所以不会出现上述问题，这是“物理”上的永不过期。或者为每个数据设置逻辑过期时间，当发现该数据逻辑过期时，使用单独的线程重建缓存。
2. 加互斥锁：对数据的访问加互斥锁，当一个线程访问该数据时，其他线程只能等待。这个线程访问过后，缓存中的数据将被重建，届时其他线程就可以直接从缓存中取值。

缓存雪崩：

问题描述：

缓存在同一时间大面积失效，后面的请求都会落到数据库上，造成数据库短时间内承受大量请求而崩坏，可能是缓存中有大量数据同时过期，也可能是Redis节点发生故障，导致大量请求无法得到处理。

解决方案：

1. 避免数据同时过期：设置过期时间时，附加一个随机数，避免大量的key同时过期。
2. 启用降级和熔断措施：在发生雪崩时，若应用访问的不是核心数据，则直接返回预定义信息/空值/错误信息。或者在发生雪崩时，对于访问缓存接口的请求，客户端并不会把请求发给Redis，而是直接返回。
3. 构建高可用的Redis服务：采用哨兵或集群模式，部署多个Redis实例，个别节点宕机，依然可以保持服务的整体可用。

如何保证缓存与数据库的双写一致性？

本地缓存和redis缓存的区别

1. 读写速度，不考虑并发问题，本地缓存自然是最快的。但是如果本地缓存不加锁，那应并发了咋办呢？所以，我们以加锁方式再比较一次。
2. 场景使用，同一数据，从数据库取出来，放到redis只要一次，而放到本地缓存，则需要n个集群次
3. 本地缓存无法用于重复点击，重复点击会分发请求到多台服务器，而用本地缓存只能防止本机重复点击，redis则可以防止，但是时间间隔也需要在redis的读写差之外。
4. redis内存可能n多扩充，而本地扩大堆内存代价是很大的。
5. 本地缓存需要自己实现过期功能，实现不好可能导致极其严重的后果，而redis经过大量的流量验证，许多漏洞无需考试，安全。
6. **本地缓存无法提供丰富的数据结构，redis有很多数据结构，方便操作，比如 **hash set list zset等。
7. redis可以写磁盘，可持久化保存，有些缓存你想重启程序后还能继续使用。
8. 各位开发同学水平差别大，使用本地缓存极有可能导致严重的线程安全问题，并发考虑严重。
9. 加本地缓存后，代码复杂度急剧上升，后面进来的开发很难一下领会原有开发想法。间接提升维护成本。
10. 其实在map和redis取值这里省的时间，可能在我们写得乱七八糟的代码里，早都不算啥了，所有有时候咱们真的没必要较那几毫秒的真！

请介绍一下Redis的过期策略

Redis支持如下两种过期策略：

惰性删除：客户端访问一个key的时候，Redis会先检查它的过期时间，如果发现过期就立刻删除这个key。

定期删除：Redis会将设置了过期时间的key放到一个独立的字典中，并对该字典进行每秒10次的过期扫描，

**过期扫描不会遍历字典中所有的key，而是采用了一种简单的贪心策略。**该策略的删除逻辑如下：

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

该配置就是配内存淘汰策略的，主要有以下六种方案：

• volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰
• volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰
• volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰
• allkeys-lru：从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰
• allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰
• no-enviction（驱逐）：禁止驱逐数据，新写入操作会报错 ，当内存超出 maxmemory，写入请求会报错，但是删除和读请求可以继续

redis的watch命令

很多时候，要确保事务中的数据没有被其他客户端修改才执行该事务。Redis提供了watch命令来解决这类问题，这是一种乐观锁的机制。客户端通过watch命令，要求服务器对一个或多个key进行监视，如果在客户端执行事务之前，这些key发生了变化，则服务器将拒绝执行客户端提交的事务，并向它返回一个空值。

redis的list常见操作

• lpush/rpush：从列表的左侧/右侧添加数据；
• lrange：指定索引范围，并返回这个范围内的数据；
• lindex：返回指定索引处的数据；
• lpop/rpop：从列表的左侧/右侧弹出一个数据；
  ile-random**：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰
• allkeys-lru：从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰
• allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰
• no-enviction（驱逐）：禁止驱逐数据，新写入操作会报错 ，当内存超出 maxmemory，写入请求会报错，但是删除和读请求可以继续

redis的watch命令

很多时候，要确保事务中的数据没有被其他客户端修改才执行该事务。Redis提供了watch命令来解决这类问题，这是一种乐观锁的机制。客户端通过watch命令，要求服务器对一个或多个key进行监视，如果在客户端执行事务之前，这些key发生了变化，则服务器将拒绝执行客户端提交的事务，并向它返回一个空值。

redis的list常见操作

• lpush/rpush：从列表的左侧/右侧添加数据；
• lrange：指定索引范围，并返回这个范围内的数据；
• lindex：返回指定索引处的数据；
• lpop/rpop：从列表的左侧/右侧弹出一个数据；
• blpop/brpop：从列表的左侧/右侧弹出一个数据，若列表为空则进入阻塞状态。