redis面试总结

一、Redis为什么这么快？

redis为什么这么快？那为什么Redis在4.0之前会选择使用单线程？而且使用单线程还那么快？

主要是使用简单，不存在锁竞争，可以在无锁的情况下完成所有操作，不存在死锁和线程切换带来的性能和时间上的开销，但同时单线程也不能完全发挥出多核CPU的性能 。

• 完全基于内存；
• 采用了高效的数据结构，比如 哈希表和跳表 ；（为后面埋坑）
• 采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗；
• 使用 多路 I/O 复用 模型，它是基于非阻塞的 I/O 模型。

Redis是单线程还是多线程呢？怎么理解单线程？（重要）

Redis不同版本之间采用的线程模型是不一样的，在Redis4.0版本之前使用的是单线程模型，在4.0版本之后增加了多线程的支持。

• 在4.0之前，Redis的单线程主要是指 Redis的 网络 IO 和 键值对读写 是 由一个线程来完成 。 但是Redis的持久化、集群同步还是使用其他线程来完成。
• 4.0之后添加了多线程的支持，主要是体现在大数据的 异步删除功能 上，例如 unlink key、flushdb async、flushall async 等

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

Redis 的瓶颈并不在 CPU，而在 内存和网络 。

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

优化方向：

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

Redis的单线程怎么用？（多路 I/O 复用）

Redis 是采用了多路复用机制，使其在网络 IO 操作中能并发处理大量的客户端请求，实现高吞吐率。

• redis采用非阻塞模式：阻塞模式下三个网络IO可能的阻塞点， 监听请求（bind/listen），建立连接（accept），读取请求（recv） 会导致 Redis 整个线程阻塞，无法处理其他客户端请求，效率很低。所以redis采用非阻塞模式，当 Redis 调用 accept() 但一直未有连接请求到达时，Redis 线程可以返回处理其他操作，而不用一直等待。
• 基于多路复用的高性能 I/O 模型，就是一个线程处理多个 IO 流。 简单来说，在 Redis 单线程的情况下，允许内核中存在多个监听套接字和已连接套接字。内核监听套接字上的请求。一旦请求到达，就会交给 Redis 线程处理，这就实现了一个 Redis 线程处理多个 IO 流的效果。请求到达时能通知到 Redis 线程，select/epoll 提供了基于事件的回调机制，即针对不同事件的发生，调用相应的处理函数。
• 再说 回调机制 ，select/epoll 一旦监测到 FD 上有请求到达时，就会触发相应的事件。事件会被放进一个队列，Redis 单线程对该事件队列不断进行处理调用相应的处理函数。这样一来，Redis 无需一直轮询是否有请求实际发生，这就可以避免造成 CPU 资源浪费，提升 Redis 的响应性能。

关系型数据库和非关系型数据库的区别？

参考：https://cloud.tencent.com/developer/article/1784274

二、redis中高效的数据结构？

redis 的五种数据类型是什么？

• String（字符串）：可以做简单的键值对缓存，底层实现只有一种数据结构，简单动态字符串；
• List（列表）：可以存储一些列表型的数据结构；
• Hash（哈希）：可以存结构化的数据，比如一个对象，当数据量 较小时用压缩列表实现 ，较大时用哈希表实现 并且不可逆；
• Set（集合）：可以做交集、并集、差集的操作，比如交集，可以把两个人的粉丝列表整一个交集；
• Sorted Set（有序集合）：去重但可以排序，如获取排名前几名的用户。

谈谈哈希表?说说 渐进式rehash？

哈希表其实就是一个数组，数组的每个元素称为一个哈希桶。

一个哈希表是由多个哈希桶组成的，每个哈希桶中保存了键值对数据。

优点：O(1) 的时间复杂度快速查找到键值对
缺点：哈希表的冲突问题和 rehash 可能带来的操作阻塞。

如何解决？redis采用 渐进式rehash

• 拉链法。链式哈希也很容易理解，就是指同一个哈希桶中的多个元素用一个链表来保存，它们之间依次用指针连接。
• rehash，过程分为三步：
  • 给哈希表 2 分配更大的空间，例如是当前哈希表 1 大小的两倍；
  • 把哈希表 1 中的数据重新映射并拷贝到哈希表 2 中；
  • 释放哈希表 1 的空间。
• 渐进式 rehash。
  • 在 hash 的内部包含了两个hashtable,一般情况下只是用一个。
  • 在扩容的时候 rehash 策略会保留新旧两个 hashtable 结构,查询时也会同时查询两个 hashtable.Redis会将旧 hashtable 中的内容一点一点的迁移到新的 hashtable 中,当迁移完成时,就会用新的 hashtable 取代之前的.当 hashtable 移除了最后一个元素之后,这个数据结构将会被删除。
  • 数据搬迁的操作放在 hash 的后续指令中,也就是来自客户端对 hash 的指令操作.一旦客户端后续没有指令操作这个 hash，Redis就会使用定时任务对数据主动搬迁。
  • 正常情况下,当 hashtable 中元素的个数等于数组的长度时,就会开始扩容,扩容的新数组是原数组大小的 2 倍。

参考：https://juejin.cn/post/6844903862961176584

bgsave时哈希表会扩容吗？

参考：https://juejin.cn/post/6844903862961176584

谈谈压缩列表、跳表？

参考：https://blog.csdn.net/qq_36389060/article/details/123955761
首先 redis集合类型的底层数据结构主要有 5 种：整数数组、双向链表、哈希表、压缩列表和跳表。

• 压缩列表实际上类似于一个数组，数组中的每一个元素都对应保存一个数据。

• 和数组不同的是，压缩列表在表头有三个字段 zlbytes、zltail 和 zllen，分别表示 列表占用内存的字节数、列表尾的偏移量 和 列表中的 entry 个数 ；压缩列表在表尾还有一个 zlend，表示列表结束。
  

• 跳表在链表的基础上，增加了多级索引，通过索引位置的几个跳转，实现数据的快速定位
  

说说数据结构的时间复杂度？

Redis高级数据结构 之 bitmap

参考：https://blog.csdn.net/u011957758/article/details/74783347

三、谈谈持久化

Redis是如何实现数据不丢失的呢？什么是Redis持久化？

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

Redis 的持久化主要有两大机制，即 AOF（Append Only File）日志和 RDB 快照。

• AOF 日志（Append Only File，文件追加方式）：记录所有的操作命令，并以 文本的形式 追加到文件中。
• RDB 快照（Redis DataBase）：将某一个时刻的内存数据，以 二进制的方式 写入磁盘。
• 混合持久化方式 ：Redis 4.0 新增了混合持久化的方式，集成了 RDB 和 AOF 的优点。

谈谈AOF

AOF的实现原理？（写后日志）

• AOF(append only file)持久化：AOF采用的是 写后日志的方式 ，Redis先执行命令把数据写入内存，然后再记录日志到文件中。
• AOF日志 记录的是操作命令 ，不是实际的数据，如果采用AOF方法做故障恢复时需要将全量日志都执行一遍。AOF中记录的是每一个命令的详细信息，包括完整的命令类型、参数等。只要产生写命令，就会实时写入到AOF文件中。
• AOF的主要作用是 解决了数据持久化的实时性，目前已经是Redis持久化的主流方式
• 优先使用AOF

MySQL则采用的是 “写前日志”，那 Redis为什么要先执行命令，再把数据写入日志呢？

这个主要是由于 Redis在写入日志之前，不对命令进行语法检查，所以只记录执行成功的命令，避免出现记录错误命令的情况，而且在命令执行后再写日志不会阻塞当前的写操作。

后写日志又有什么风险呢？

• 数据可能会丢失：如果 Redis 刚执行完命令，此时发生故障宕机，会导致这条命令存在丢失的风险。
• 可能阻塞其他操作：AOF 日志其实也 是在主线程中执行 ，所以当 Redis 把日志文件写入磁盘的时候，还是会阻塞后续的操作无法执行。

AOF写数据三种策略？

• Always：每个写命令执行完，立马同步地将日志写回磁盘；
• Everysec：每个写命令执行完，只是 先把日志写到 AOF 文件的内存缓冲区 ，每隔一秒把缓冲区中的内容写入磁盘；
• No（操作系统控制的写回）：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘。

日志文件太大了怎么办？谈谈AOF重写机制？

• AOF重写机制：对过大的AOF文件进行重写，以此来压缩AOF文件的大小。
• 实现：检查当前键值数据库中的键值对， 记录键值对的最终状态，将某个键值对 重复操作后产生的多条操作记录 压缩成一条 。进而实现压缩AOF文件的大小。

如何配置AOF重写？重写指标有哪些？

AOF手动重写方式

• 手动重写：bgrewriteaof，后台执行，并不是立马执行

AOF自动重写方式

• 自动重写触发条件设置，比size大就自动重写，比自动重写百分比大就重写

  auto-aof-rewrite-min-size size 
  auto-aof-rewrite-percentage percentage
  

• 自动重写触发比对参数（ 运行指令info Persistence获取具体信息 ），aof_current_size 用于和size对比

  aof_current_size 
  aof_base_size
  

• 自动重写触发条件，满足一个就进行自动重写
  

AOF 重写仍然很耗时，会阻塞吗?

和 AOF 日志由主线程写回不同，重写过程是由后台子进程 bgrewriteaof 来完成的，这也是为了避免阻塞主线程，导致数据库性能下降。

重写流程是怎样的？

每次执行重写时：

• 主线程 fork 出后台的 bgrewriteaof 子进程。
• 此时，fork 子进程会把主线程的内存拷贝一份给 bgrewriteaof 子进程，这里面就包含了数据库的最新数据。
• 然后，bgrewriteaof 子进程就可以在不影响主线程的情况下，逐一把拷贝的数据写成操作，记入重写日志。

什么是AOF缓冲区？什么是AOF重写缓冲区？

• AOF缓冲区:是正常使用aof作为数据落地中间地带，所有的数据先到aof缓冲区再到aof文件中。
• AOF重写缓冲区： 是aof重写时，redis还要继续接收数据，这个数据就写到aof重写缓冲区，当aof重写ok时，主进程在把aof重写缓冲区的数据写到aof缓冲区，最后fsync到aof文件中。

如何解决AOF重写过程中的数据不一致问题？重要

• 为了解决这种数据不一致的问题，Redis增加了一个 AOF重写缓存， 这个缓存在fork出子进程之后开始启用，Redis服务器 主进程 在执行完写命令之后，会同时将这个写命令追加到 AOF缓冲区 和 AOF重写缓冲区
• 即子进程在执行AOF重写时，主进程需要执行以下三个工作：
  • 执行client发来的命令请求；
  • 将写命令追加到现有的AOF文件中；
  • 将写命令追加到AOF重写缓存中。
• 完成AOF重写之后：当子进程完成对AOF文件重写之后，它会向父进程发送一个完成信号，父进程接到该完成信号之后，会调用一个信号处理函数，该函数完成以下工作：
  • 将AOF重写缓存中的内容全部写入到新的AOF文件中 ；这个时候新的AOF文件所保存的数据库状态和服务器当前的数据库状态一致；
  • 对新的AOF文件进行改名，原子的覆盖原有的AOF文件；完成新旧两个AOF文件的替换 。
• 当这个信号处理函数执行完毕之后，主进程就可以继续像往常一样接收命令请求了。

在整个AOF后台重写过程中，只有最后的 “主进程写入命令到AOF缓存”和“对新的AOF文件进行改名，覆盖原有的AOF文件。” 这两个步骤（信号处理函数执行期间）会造成主进程阻塞，在其他时候，AOF后台重写都不会对主进程造成阻塞，这将AOF重写对性能造成的影响降到最低。

如何配置开启AOF？

• 配置：appendonly yes|no
  • 作用：是否开启AOF持久化功能，默认为不开启状态
• 配置：appendfsync always|everysec|no
  • 作用：AOF写数据策略
• 配置：appendfilename filename
  • 作用：AOF持久化文件名，默认文件名未appendonly.aof，建议配置为appendonly-端口号.aof
• 配置：dir
  • 作用：AOF持久化文件保存路径，与RDB持久化文件保持一致即可

AOF日志的优缺点是什么？

优点：
1、数据安全，aof 持久化可以配置 appendfsync 属性，有 always，每进行一次 命令操作就记录到 aof 文件中一次。
2、通过 append 模式写文件，即使中途服务器宕机，可以通过 redis-check-aof 工具解决数据一致性问题。
3、AOF 机制的 rewrite 模式。AOF 文件没被 rewrite 之前（文件过大时会对命令 进行合并重写），可以删除其中的某些命令（比如误操作的 flushall）)
缺点：
1、AOF 文件比 RDB 文件大，且恢复速度慢。
2、数据集大的时候，比 rdb 启动效率低。

谈谈RDB

RDB的实现原理？

• RDB 记录的是某一时刻的数据，并不是操作 ，在做数据恢复时直接把 RDB 文件读入内存，很快地完成恢复。
• Redis 的数据都在内存中，为了提供所有数据的可靠性保证，它执行的是全量快照，也就是说，把内存中的所有数据都记录到磁盘中 。
• 通过bgsave命令在后台执行全量快照

RDB优缺点是什么？

优点：

• RDB是一个紧凑压缩的二进制文件，存储效率较高
• RDB内部存储的是redis在某个时间点的数据快照，非常适合用于数据备份，全量复制等场景
• RDB恢复数据的速度要比AOF快很多
• 应用：服务器中每X小时执行bgsave备份，并将RDB文件拷贝到远程机器中，用于灾难恢复。

缺点：

• 数据安全性低。RDB 是间隔一段时间进行持久化，如果持久化之间 redis 发生故障，会发生数据丢失。所以这种方式更适合数据要求不严谨的时候。

RDB做快照时会阻塞线程吗？RDB 做快照的时候数据能修改吗？

Redis 提供了两个命令来生成 RDB 快照文件，分别是 save 和 bgsave。

• save是在前台执行的，也就是说在生成RDB文件时，会阻塞整个实例，在RDB未生成之前，任何请求都是无法处理的，对于内存很大的实例，生成RDB文件非常耗时，显然这是我们不能接受的。
• 所以通常我们会选择执行bgsave让Redis在 后台生成RDB文件 ，这样 Redis依旧可以处理客户端请求，不会阻塞整个实例。

save是同步的会阻塞客户端命令，bgsave的时候是可以修改的。

Redis是怎么解决在bgsave做快照的时候允许数据修改呢？（写时复制技术，重要 重要 重要）

但不是说后台生成RDB就是没有代价的，Redis为了实现后台把内存数据的快照写入文件，采用了操作系统提供的 Copy On Write（写时复制） 技术，也就是我们熟知的 fork系统调用 。

• fork系统调用会产生一个子进程，它与父进程 共享相同的内存地址空间，这样子进程在这一时刻就能拥有与父进程的相同的内存数据。
• 虽然子进程与父进程共享同一块内存地址空间，但在fork子进程时，操作系统需要拷贝父进程的内存页表给子进程，如果整个Redis实例内存占用很大，那么它的内存页表也会很大，在拷贝时就会比较耗时，同时这个过程会消耗大量的CPU资源。在完成拷贝之前父进程也处于阻塞状态，无法处理客户端请求。
• fork执行完之后，子进程就可以扫描自身所有的内存数据，然后把全部数据写入到RDB文件中。
• 之后父进程依旧处理客户端的请求，当在处理写命令时，父进程会重新分配新的内存地址空间，从操作系统申请新的内存使用，不再与子进程共享，这个过程就是Copy On Write（写实复制）名字的由来。这样父子进程的内存就会逐渐分离，父进程申请新的内存空间并更改内存数据，子进程的内存数据不受影响。

由此可以看出，在生成RDB文件时，不仅消耗CPU资源，还有 需要占用最多一倍的内存空间 。

我们在Redis执行info命令，可以看到fork子进程的耗时，可以通过这个耗时来评估fork时间是否符合预期。同时我们应该保证Redis机器拥有足够的CPU和内存资源，并合理设置生成RDB的时机。

可以每秒做一次快照吗？执行RDB的频率高有什么问题？

不行。如果频繁地执行全量快照，也会带来两方面的开销：

• 一方面，频繁将全量数据写入磁盘，会给磁盘带来很大压力，多个快照竞争有限的磁盘带宽，前一个快照还没有做完，后一个又开始做了，容易造成恶性循环。
• 另一方面，bgsave 子进程需要通过 fork 操作从主线程创建出来。子进程在创建后不会再阻塞主线程，但是，fork 这个创建过程本身会阻塞主线程，而且主线程的内存越大，阻塞时间越长。如果频繁 fork 出 bgsave 子进程，这就会频繁阻塞主线程了（所以，在 Redis 中如果有一个 bgsave 在运行，就不会再启动第二个 bgsave 子进程）。

谈谈混合持久化？（混用 RDB 和 AOF）

• 内存快照以一定的频率执行；
• 在两次RDB快照之间，使用 AOF 日志记录这期间的所有命令操作；
• 既能享受到 RDB 文件快速恢复的好处，又能享受到 AOF 只记录操作命令的简单优势。

AOF和RDB比较

• AOF文件比RDB更新频率高，优先使用AOF还原数据。
• AOF比RDB更安全也更大
• RDB性能比AOF好
• 如果两个都配了优先加载AOF

如何选择合适的持久化方式？（重要）

• 如果想达到高的数据安全性，你应该同时使用两种持久化功能。在这种情况下，当 Redis 重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。

• 如果你非常关心你的性能， 但仍然可以承受数分钟以内的数据丢失，那么你可以只使用RDB持久化。

• 有很多用户都只使用AOF持久化everysec，但并不推荐这种方式，因为定时生成RDB快照非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比AOF恢复的速度要快。

• 如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化方式。

Redis持久化数据和缓存怎么做扩容？TODO

• 如果Redis被当做缓存使用，使用一致性哈希实现动态扩容缩容。
• 果Redis被当做一个持久化存储使用，必须使用固定的keys-to-nodes映射关系，节点的数量一旦确定不能变化。否则的话(即Redis节点需要动态变化的情况），必须使用可以在运行时进行数据再平衡的一套系统，而当前只有Redis集群可以做到这样。

四、Redis过期数据删除策略

什么是过期数据？

Redis中有个设置时间过期的功能，即对存储在redis数据库中的值可以设置一个过期时间。

set key的时候，都可以给一个expire time，就是过期时间，通过过期时间就可以指定这个key可以存活的时间。

Redis是一种内存级数据库，所有数据均存放在内存中，内存中的数据可以通过 TTL指令 获取其状态

• XX ：具有时效性的数据
• 1 ：永久有效的数据
• 2 ：已经过期的数据 或 被删除的数据 或 未定义的数据

时效性数据的存储结构是怎样的？

• 当给name设置值iteima，它会有一个十六进制的存储地址
• redis中会开放一块空间（expires），存放的就是 存储地址 : 过期时间
• 删除策略就是操作expires空间
  

数据删除策略有哪些（三种策略）？说说定期删除的执行流程？

定时删除 、惰性删除

• 定时删除：创建一个定时器，当key设置有过期时间，且过期时间到达时，由定时器任务立即执行对键的删除操作。（拿时间换空间）
• 惰性删除：数据到达过期时间，不做处理。等下次访问该数据时， 如果未过期，返回数据；发现已过期，删除，返回不存在。内部执行 expireIfNeeded() 函数，检查数据是否过期，所有的get操作都与它绑定（拿空间换时间）

定期删除流程

redis默认是每隔100ms就随机抽取一些设置了过期时间的key，检查其是否过期，如果过期就删除 。注意这里是随机抽取的。为什么要随机呢?假如redis存了几十万个key，每隔100ms就遍历所有的设置过期时间的key的话，就会给CPU带来很大的负载。

执行流程：

• 每个库都有一个expires
  
• Redis启动服务器初始化时，读取配置server.hz的值，默认为10
• 每秒钟执行server.hz次 serverCron() ==> databasesCron() == > activeExpireCycle()
  • serverCron() ：对服务器进行定时轮询；
  • databasesCron()：对每个库进行轮询（轮询expires）；
  • activeExpireCycle()：对每个expires[i]逐一进行检测，每次执行250ms/server.hz。
• 对某个expires[*]检测时，随机挑选W个key检测
  • 如果key超时，删除key
  • 如果一轮中删除的key的数量>W * 25%，循环该过程
  • 如果一轮中删除的key的数量≤W * 25%，检查下一个expires[i]，0-15循环（redis默认有16个库）
  • 找多少个key可以自己设定： W取值=ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP属性值
• 参数current_db用于记录activeExpireCycle() 进入哪个expires[i] 执行，如果activeExpireCycle()执行时间到期，下次从current_db继续向下执行

五、Redis内存满了怎么办？怎么优化？

当新数据进入redis时，如果内存不足并且没有key过期怎么办？（逐出算法）

• Redis使用内存存储数据，在执行每一个命令前 ，会调用 freeMemoryIfNeeded() 检测内存是否充足。如果内存不满足新加入数据的最低存储要求，redis要 临时删除 一些数据为当前指令清理存储空间。清理数据的策略称为逐出算法。
• 注意：逐出数据的过程不是100%能够清理出足够的可使用的内存空间，如果不成功则反复执行。当对所有数据尝试完毕后，如果不能达到内存清理的要求，将出现错误信息。
  

谈谈缓存数据的淘汰机制（逐出算法）？

不进行数据淘汰的策略，只有 no-eviction 这一种，会引发错误OOM（Out Of Memory），内存泄漏。

会进行淘汰的 7 种策略，我们可以再进一步根据淘汰候选数据集的范围把它们分成两类：

• 在设置了过期时间的数据中进行淘汰，包括 volatile-random、volatile-ttl、volatile-lru、volatile-lfu四种。
  • volatile-lru：使用 LRU 算法筛选设置了过期时间的键值对，即挑选最近最少使用的数据淘汰（latest recently used，推荐设置）
  • volatile-lfu：使用 LFU 算法选择设置了过期时间的键值对，即挑选最近使用次数最少的数据淘汰（latest frequently used）
  • volatile-ttl：挑选将要过期的数据淘汰（按照过期时间淘汰）
  • volatile-random：在设置了过期时间的键值对中，进行随机删除。
• 在所有数据范围内进行淘汰，包括 allkeys-lru、allkeys-random、allkeys-lfu三种。
  • allkeys-lru：挑选最近最少使用的数据淘汰
  • allkeys-lfu：挑选最近使用次数最少的数据淘汰
  • allkeys-random：从所有键值对中随机选择并删除数据；

谈谈LRU、LFU？TODO

六、谈谈对Redis事务的理解？

先说说什么是事务？

事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行。

满足以下要求：

• 原子性。原子性的要求很明确，就是一个事务中的多个操作必须都完成，或者都不完成。
• 一致性。就是指数据库中的数据在事务执行前后是一致的。
• 隔离性。它要求数据库在执行一个事务时，其它操作无法存取到正在执行事务访问的数据。
• 持久性。数据库执行事务后，数据的修改要被持久化保存下来。当数据库重启后，数据的值需要是被修改后的值。

说说什么是redis事务？

redis事务就是一个 命令执行的队列 ，将一系列预定义命令包装成一个整体（一个队列）。当执行时，一次性按照添加顺序依次执行，中间不会被打断或者干扰。

• 一个队列中，一次性、顺序性、排他性的执行一系列命令

redis怎么实现事务？

分三个阶段：

• 事务开始： MULTI
• 命令入队，Redis 实例只是把这些命令暂存到一个命令队列中，并不会立即执行。
• 事务执行 ：EXEC，执行命令队列中的所有命令。

事务执行过程中，如果服务端收到有EXEC、DISCARD、WATCH、MULTI之外的请求，将会把请求放入队列中排队。

Redis 通过 MULTI、EXEC、DISCARD 和 WATCH 四个命令来支持事务机制

• WATCH命令可以监控一个或多个键，一旦其中有一个键被修改（或删除），之后的事务就不会执行。监控一直持续到EXEC命令（事务中的命令是在EXEC之后才执行的，所以在MULTI命令后可以修改WATCH监控的键值）

• discard在使用中，如果multi开启事务，命令入队，直接discard的话，所有的命令都会回滚。

那Redis事务还有没有其他实现？

• 基于Lua脚本，Redis可以保证脚本内的命令一次性、按顺序地执行，其同时也不提供事务运行错误的回滚，执行过程中如果部分命令运行错误，剩下的命令还是会继续运行完。
• 基于中间标记变量，通过另外的标记变量来标识事务是否执行完成，读取数据时先读取该标记变量判断是否事务执行完成。但这样会需要额外写代码实现，比较繁琐

Redis能否满足事务的ACID属性？（分情况讨论，重要 重要 重要 重要 ）

原子性（分情况讨论）

• 命令入队时就报错，会放弃事务执行，保证原子性；
• 命令入队时没报错，实际执行时报错，不保证原子性；
• EXEC 命令执行时实例故障，如果开启了 AOF 日志，可以保证原子性。

第一种情况是，在执行 EXEC 命令前，客户端发送的操作命令本身就有错误，在命令入队时就被 Redis 实例判断出来了。提交时Redis会拒绝执行。能保证原子性。

第二种情况。事务操作入队时，命令有问题，但 Redis 实例没有检查出错误。但是，在执行完 EXEC 命令以后，Redis 实际执行这些事务操作时，就会报错。但还是会把正确的命令执行完。原子性就无法得到保证了。（Redis 中并没有提供回滚机制。）

第三种情况：在执行事务的 EXEC 命令时，Redis 实例发生了故障，导致事务执行失败。如果开启了 AOF 日志，那么只会有部分的事务操作被记录到 AOF 日志中。使用 redis-check-aof 工具检查 AOF 日志文件，把未完成的事务操作从 AOF 文件中去除，从而保证了原子性。 没开AOF就不保证。

一致性

情况一：命令入队时就报错，不执行，保证。

情况二：命令入队时没报错，实际执行时报错，正确执行，错误不执行，保证。

情况三：EXEC 命令执行时实例发生故障，没开RDB和AOF数据为空保证，只开RDB不会在事务时执行快照保证，只开AOF是可以删的保证。

隔离性：

两种情况：

情况一：并发操作在 EXEC 命令前执行，此时隔离性的保证要使用 WATCH 机制来实现，否则隔离性无法保证；

• WATCH 机制的作用是，在事务执行前，监控一个或多个键的值变化情况，当事务调用 EXEC 命令执行时，WATCH 机制会先检查监控的键是否被其它客户端修改了。如果修改了，就放弃事务执行，避免事务的隔离性被破坏。然后，客户端可以再次执行事务，此时，如果没有并发修改事务数据的操作了，事务就能正常执行，隔离性也得到了保证。

情况二：并发操作在 EXEC 命令后执行，此时，隔离性可以保证。

• 因为 Redis 是用单线程执行命令，而且，EXEC 命令执行后，Redis 会保证先把命令队列中的所有命令执行完。所以，在这种情况下，并发操作不会破坏事务的隔离性

持久性：就得扯AOF和RDB了

• 如果 Redis 没有使用 RDB 或 AOF，那么事务的持久化属性肯定得不到保证。
• 如果 Redis 使用了 RDB 模式，那么，在一个事务执行后，而下一次的 RDB 快照还未执行前，如果发生了实例宕机，这种情况下，事务修改的数据也是不能保证持久化的。
• 如果 Redis 采用了 AOF 模式，因为 AOF 模式的三种配置选项 no、everysec 和 always 都会存在数据丢失的情况，所以，事务的持久性属性也还是得不到保证。

总结

Redis 的事务机制 可以保证一致性和隔离性 ，但是 无法保证持久性 。不过，因为 Redis 本身是内存数据库，持久性并不是一个必须的属性，我们更加关注的还是原子性、一致性和隔离性这三个属性。原子性的情况比较复杂，只有当事务中使用的命令语法有误时，原子性得不到保证，在其它情况下，事务都可以原子性执行。

建议：严格按照 Redis 的命令规范进行程序开发，并且通过 code review 确保命令的正确性。

七、Redis 锁（分布式锁）TODO

什么是分布式锁？

分布式锁其实就是，控制分布式系统不同进程共同访问共享资源的一种锁的实现。如果不同的系统或同一个系统的不同主机之间共享了某个临界资源，往往需要互斥来防止彼此干扰，以保证一致性。

Redis分布式锁方案一：SETNX + EXPIRE

即先用setnx来抢锁，如果抢到之后，再用expire给锁设置一个过期时间，防止锁忘记了释放。

SETNX 是SET IF NOT EXISTS的简写。日常命令格式是SETNX key value。如果 key不存在，则SETNX成功返回1，如果这个key已经存在了，则返回0。

if（jedis.setnx(key_resource_id,lock_value) == 1）{ //加锁
    expire（key_resource_id，100）; //设置过期时间
    try {
        do something  //业务请求
    }catch(){
  }
  finally {
       jedis.del(key_resource_id); //释放锁
    }
}

但是这个方案中，setnx和expire两个命令分开了， 「不是原子操作」 。如果执行完setnx加锁，正要执行expire设置过期时间时，进程crash或者要重启维护了，那么这个锁就别的线程就永远获取不到了。

Redis分布式锁方案二：SETNX + value值是(系统时间+过期时间)

long expires = System.currentTimeMillis() + expireTime; //系统时间+设置的过期时间
String expiresStr = String.valueOf(expires);

// 如果当前锁不存在，返回加锁成功
if (jedis.setnx(key_resource_id, expiresStr) == 1) {
        return true;
} 
// 如果锁已经存在，获取锁的过期时间
String currentValueStr = jedis.get(key_resource_id);

// 如果获取到的过期时间，小于系统当前时间，表示已经过期
if (currentValueStr != null && Long.parseLong(currentValueStr) < System.currentTimeMillis()) {

     // 锁已过期，获取上一个锁的过期时间，并设置现在锁的过期时间
     // 将给定 key 的值设为 value ，并返回 key 的旧值(old value)
    String oldValueStr = jedis.getSet(key_resource_id, expiresStr);
    
    if (oldValueStr != null && oldValueStr.equals(currentValueStr)) {
         // 考虑多线程并发的情况，只有一个线程的设置值和当前值相同，它才可以加锁
         return true;
    }
}
        
//其他情况，均返回加锁失败
return false;
}

这个方案的优点是，巧妙移除expire单独设置过期时间的操作，把 过期时间放到setnx的value值 里面来。解决了方案一发生异常，锁得不到释放的问题。但是这个方案还有别的缺点：

• 过期时间是客户端自己生成的（System.currentTimeMillis()是当前系统的时间），必须要求分布式环境下，每个客户端的时间必须同步 。
• 如果锁过期的时候，并发多个客户端同时请求过来，都执行jedis.getSet()， 最终只能有一个客户端加锁成功，但是该客户端锁的过期时间，可能被别的客户端覆盖 。
• 该锁 没有保存持有者的唯一标识 ，可能被别的客户端 释放/解锁 。

Redis分布式锁方案三：使用Lua脚本(包含SETNX + EXPIRE两条指令)

实际上，我们还可以使用Lua脚本来保证原子性（包含setnx和expire两条指令），lua脚本如下：

if redis.call('setnx',KEYS[1],ARGV[1]) == 1 then
   redis.call('expire',KEYS[1],ARGV[2])
else
   return 0
end;

加锁代码如下：

 String lua_scripts = "if redis.call('setnx',KEYS[1],ARGV[1]) == 1 then" +
            " redis.call('expire',KEYS[1],ARGV[2]) return 1 else return 0 end";   
Object result = jedis.eval(lua_scripts, Collections.singletonList(key_resource_id), Collections.singletonList(values));
//判断是否成功
return result.equals(1L);

Redis分布式锁方案四：SET的扩展命令（SET EX PX NX）TODO

Redis分布式锁方案五：SET EX PX NX + 校验唯一随机值,再删除 TODO

Redis分布式锁方案六：Redisson框架 TODO

Redis分布式锁方案七：使用Lua脚本(包含SETNX + EXPIRE两条指令)TODO

LUA脚本分布式锁在集群下如何保证有效？hash tag

参考：https://blog.csdn.net/shaofei_huai/article/details/119547945

八、Redis 主从复制

redis 主从复制是啥？

主从复制：指 将 主节点 的数据，复制到其他 从节点 服务器。

• 数据的复制是单向的
• 异步复制 ，异步分为两个方面：
  • 一个是master服务器在将数据同步到slave时是异步的，因此master服务器在这里仍然可以接收其他请求；
  • 一个是slave在接收同步数据也是异步的。

为什么要采用读写分离的方式呢？（保证数据的一致性）

Redis 提供了主从库模式，以保证数据副本的一致：

• 读操作：主库、从库都可以接收；
• 写操作：首先到主库执行，然后，主库将写操作同步给从库。

主从复制相关命令？TODO

那主从库同步是如何完成的呢？（原理）

1、建立连接阶段（即准备阶段，slave连接master）：主从库间建立连接、协商同步的过程，主要是为全量复制做准备。

• 在这一步，从库会发送 PSYNC 命令和主库建立起连接，并告诉主库即将进行同步，主库确认回复后，主从库间就可以开始同步了。psync 命令包含了 主库的 runID 和复制进度 offset 两个参数。

2、数据同步阶段

• 主库执行bgsave生成RDB，将所有数据同步给从库。
• 从库收到数据后，在本地完成数据加载。
• 从库加载数据时，主库不会被阻塞，仍然可以正常接收请求。
• 为了保证主从库的数据一致性， 主库会在内存中用专门的 replication buffer（复制缓冲区），记录 RDB 文件生成后收到的所有写操作。

3、命令传播阶段

• 当主库完成 RDB 文件发送后，就会把此时 replication buffer 中的修改操作发给从库，从库再重新执行这些操作。

全量复制 与 增量复制（部分复制）

• 全量复制：slave发同步指令那一刻的所有数据
• 增量复制：进行RDB过程中对应的所有数据

replication buffer的作用?replication buffer太小会怎么样？（重要）

replication buffer里面存放的数据是下面三个时间内所有的master数据更新操作：

• master执行rdb bgsave产生snapshot的时间
• master发送rdb到slave网络传输时间
• slave load rdb文件把数据恢复到内存的时间

replication buffer由 client-output-buffer-limit slave 参数设置，当这个值太小会导致主从复制链接断开。从而引发：

• 当master-slave复制 连接断开，server端会释放连接相关的数据结构。replication buffer中的数据也就丢失了，此时主从之间重新开始复制过程。
• 还有个更严重的问题，主从复制连接断开，导致主从上出现rdb bgsave和rdb重传操作无限循环。

replication backlog是啥？命令传播阶段要是主从库间的网络断连了 redis 如何处理？数据还能保持一致吗？（增量复制，Redis2.8之后）

从 Redis 2.8 开始，网络断了之后，主从库 会采用增量复制的方式 继续同步。增量复制只会把主从库网络断连期间主库收到的命令，同步给从库。

当主服务器进行命令传播的时候，maser不仅将所有的数据更新命令发送到所有slave的replication buffer，还会写入replication backlog。

当断开的slave重新连接上master的时候，slave将会发送psync命令（包含复制的偏移量offset），请求partial resync。主库会判断自己的 master_repl_offset 和 slave_repl_offset 之间的差距。

• 如果offset存在，主库只用把 master_repl_offset 和 slave_repl_offset 之间的命令操作同步给从库就行。
• 如果请求的offset不存在，那么执行全量的sync操作，相当于重新建立主从复制。

这里用到了三个增量复制的实现细节：

• 主服务器的复制偏移量：replication_offset
• 主服务器的 复制积压缓冲区 ：replication_backlog
• 服务器的运行id

对于复制偏移量：执行复制的双方，主从服务器都会维护一个复制偏移量，主服务器每次向从服务器传播n个字节的数据时，就将自己的复制偏移量的值加上N，从服务器每次收到主服务器传播来的N个字节数据时，就将自己的复制偏移量的值加上N。

replication backlog的结构是怎样的？replication backlog和replication buffer之间的区别是什么？

repl_backlog_buffer 是一个环形缓冲区 ，主库会记录自己写到的位置，从库则会记录自己已经读到的位置。恢复时主库和从库之间相差的操作，在增量复制时，主库会把它们同步给从库。

二者区别？

• replication buffer 对应于每个slave，通过 config set client-output-buffer-limit slave 设置。
• replication backlog是一个环形缓冲区，整个master进程中只会存在一个，所有的slave公用。backlog的大小通过 repl-backlog-size 参数设置，默认大小是1M。
  • 其大小可以根据每秒产生的命令 乘以（（master执行rdb bgsave的时间）+ (master发送rdb到slave的时间) + (slave load rdb文件的时间) ) ，来估算积压缓冲区的大小，repl-backlog-size值不小于这两者的乘积。

replication backlog可能会出现的问题有哪些？

问题：因为repl_backlog_buffer 是一个环形缓冲区，所以在缓冲区写满后，主库会继续写入，此时，就会覆盖掉之前写入的操作。 如果从库的读取速度比较慢，就有可能导致从库还未读取的操作被主库新写的操作覆盖了，这会导致主从库间的数据不一致。

解决：可以根据 Redis 所在服务器的内存资源再适当增加 repl_backlog_size 值， 比如说设置成缓冲空间大小的 4 倍 ，另一方面，你可以考虑使用切片集群来分担单个主库的请求压力。

redis 如何处理PSYNC命令？怎么判断是进行全量复制还是增量复制？（重要）

如果当前请求不满足PSYNC（包括 Run ID 和 Offset）的条件，则需要进行全量复制。满足psync的条件有两个

• 第一个是slave带来的runid是否为当前master的runid，如果不是，则需要全量同步；
• 第二个条件即当前slave带来的复制offset，master在backlog（复制积压缓冲区）中是否还能找到，如果找不到，还是需要全量复制的。

如果两个条件都满足，master会告诉slave可以增量复制，回复+CONTINUE消息。

从库如何处理过期key？

• slave不会过期key，只会等待master过期key。
• 如果master过期了一个key，或者通过LRU淘汰了一个key，那么会 模拟一条del命令发送给slave 。

什么是心跳机制？

• 进入命令传播阶段候，master与slave间需要进行信息交换，使用心跳机制进行维护，实现双方连接保持在线
• master心跳：
  • 指令：PING
  • 周期：由repl-ping-slave-period决定，默认10秒
  • 作用：判断slave是否在线
  • 查询：INFO replication 获取slave最后一次连接时间间隔，lag项维持在0或1视为正常
• slave心跳任务
  • 指令：REPLCONF ACK {offset}
  • 周期：1秒
  • 作用1：汇报slave自己的复制偏移量，获取最新的数据变更指令
  • 作用2：判断master是否在线

九、哨兵机制 - 主库故障了从库该怎么办？数据还能保持一致吗？Redis 还能正常提供服务吗？

什么是哨兵机制？

哨兵(sentinel) 是一个分布式系统，用于对主从结构中的每台服务器进行监控，当出现故障时通过 筛选+打分 机制选择新的master并将所有slave连接到新的master。（监控和选择）

哨兵主要负责的就是三个任务：监控、选主（选择主库）和通知。

哨兵是如何监控的？工作流程是什么？

• 哨兵进程会使用 PING 命令检测它自己和主、从库的网络连接情况，用来判断实例的状态。
• 如果哨兵发现主库或从库对 PING 命令的响应超时了，那么，哨兵就会先把它标记为“主观下线”。
• 如果 大多数的哨兵实例，都判断主库已经“主观下线”了，主库才会被标记为“客观下线”。
• 哨兵集群会 投票选举 一个sentinel节点进行故障处理， 在从节点中选取一个主节点，其他从节点挂载到新的主节点上自动复制新主节点的数据。

如何选定新主库呢？（筛选 + 打分）

哨兵选择新主库的过程称为 筛选 + 打分

筛选：检查从库的当前在线状态，还要判断它之前的网络连接状态。

• 如果从库总是和主库断连，而且断连次数超出了一定的阈值，就可以把这个从库筛掉了。
• 如果一个 从库 和 主库 断开连接已经超过了down-after-milliseconds的10倍，外加master宕机的时长，那么slave就被认为不适合选举为master。

  ( down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state
  

打分：依据 从库优先级、从库复制进度以及从库 ID 号 。

• 第一轮：优先级最高的从库得分高。
• 第二轮：和旧主库同步程度最接近的从库得分高。（replication offset）
• 第三轮：ID 号小的从库得分高。

哨兵集群是怎么建立的？

哨兵彼此之间建立连接形成集群：基于 pub/sub 机制（发布 / 订阅机制）的哨兵集群组成

• 哨兵只要和主库建立起了连接，就可以在主库上发布消息了，比如说发布它自己的连接信息（IP 和端口）。同时，它也可以从主库上订阅消息，获得其他哨兵发布的连接信息 。当多个哨兵实例都在主库上做了发布和订阅操作后，它们之间就能知道彼此的 IP 地址和端口。只有订阅了同一个频道的应用，才能通过发布的消息进行信息交换。

哨兵和从库建立连接：基于 INFO 命令的从库列表

• 哨兵给主库发送 INFO 命令，主库接受到这个命令后，就会 把从库列表返回给哨兵 。接着，哨兵就可以根据从库列表中的连接信息，和每个从库建立连接，并在这个连接上持续地对从库进行监控。
  

哨兵和客户端间的信息同步：基于 pub/sub 机制的客户端事件通知

• 哨兵就是一个运行在特定模式下的 Redis 实例，只不过它并不服务请求操作，只是完成监控、选主和通知的任务。所以，每个哨兵实例也提供 pub/sub 机制，客户端可以从哨兵订阅消息 。哨兵提供的消息订阅频道有很多，不同频道包含了主从库切换过程中的不同关键事件。

哨兵集群由哪个实例来执行主从切换呢？TODO

哨兵集群在判断了主库“客观下线”后，经过 投票仲裁 ，选举一个 Leader 出来，由它负责实际的主从切换，即由它来完成新主库的选择以及通知从库与客户端。

十、redis集群？

Redis集群模式的工作原理能说一下么？

集群中那么多Master节点，redis cluster在存储的时候如何确定选择哪个节点呢？（数据分区规则：哈希槽，类似一致性hash）

Redis Cluster数据分区采用哈希规则。

Redis集群 没用 一致性hash,而是引入了 哈希槽 的概念，Redis集群有16384个哈希槽， 每个key通过CRC16校验后对16384取模来决定放置哪个槽，集群的每个节点负责一部分hash槽。

再谈分析一下分区方案的优缺点

优点：

• 解耦数据和节点间关系，易于节点扩容和收缩的难度；
• 节点自身维护槽的映射关系，不需要客户端或者代理服务维护槽分区元数据；
  • hash slot让node的增加和移除很简单，增加一个master，就将其他master的hash slot移动部分过去，减少一个master，就将它的hash slot移动到其他master上去。
  • 每次增加或减少master节点都 是对16384取模，而不是根据master数量 ，这样原本在老的master上的数据不会因master的新增或减少而找不到。

缺点：也就是集群功能限制的地方

• key批量操作支持有限。 对于映射为不同slot值的key由于执行mset、mget等操作可能存在于多个节点上而不被支持。
• key事务操作支持有限。 多个key分布在不同节点上时无法使用事务功能。
• key作为数据分区的最小粒度，不能将一个大的键值对象如hash、list等映射到不同的节点。
• 不支持多数据库空间 。单机下Redis可以支持16个数据库，集群模式下只能使用一个数据库空间，即db0。
• 复制结构只支持一层，从节点只能复制主节点，不支持嵌套树状复制结构。

最后谈集群实例之间是怎样通信机制的？

Redis Cluster 实例以 Gossip 协议 进行通信的机制：

• 一是，每个实例之间会 按照一定的频率 ，从集群中随机挑选一些实例，向它们发送ping命令，来检测这些实例是否在线，并交换彼此的状态信息。PING 消息中封装了发送消息的 实例自身的状态信息、部分其它实例的状态信息，以及 Slot 映射表 。
• 二是，一个实例在接收到 PING 消息后，会给发送 PING 消息的实例，发送一个 PONG 消息。PONG 消息包含的内容和 PING 消息一样。
  

Gossip 协议可以保证在一段时间后，集群中的每一个实例都能获得其它所有实例的状态信息。

在集群模式下，redis 的 key 是如何寻址的？

Redis集群 没用 一致性hash,而是引入了 哈希槽 的概念，Redis集群有16384个哈希槽， 每个key通过CRC16校验后对16384取模来决定放置哪个槽，集群的每个节点负责一部分hash槽。

CRC16校验：循环冗余校验码(Cyclic Redundancy Check)

分布式寻址（数据分布方案）都有哪些算法？

节点取余分区方案：

• 使用特定的数据（Redis的健或用户ID），根据节点数量N使用公式计算哈希值:hash(key)%N，决定数据映射到某一节点。
• 优点：简单
• 缺点：当节点数量变化时，会导致数据的重新迁移，因此需要重新计算数据节点映射关系。
• 解决方案：翻倍扩容可以使数据迁移从80%降到50%

一致性哈希分区方案

虚拟槽分区方案（Redis Cluster采用此方案）

了解一致性 hash 算法吗？它的应用场景有哪些？

简单点说就是使用常用的hash算法 将key映射到一个具有2^32次方个桶空间中 ，即0 ~ 2^32 - 1 的数字空间中。我们可以将其用一个首尾相连的闭合环形表示，如下图所示：

图中列出了一个虚拟的圆环，上面有0-2^32个节点位置。算法首先需要计算出存储节点在圆环上的位置。 具体可以选择服务器的ip或主机名作为关键字进行哈希 。

这一点是为了保证算法的分散性：节点的位置跟具体多少个节点没关系，只跟节点的内在特性有关系。

上图我们假设有4个节点：node1，node2，node3，node4。计算好他们的位置之后，接下来我们就需要就计算出各个不同的key的存储位置了：将key用同样的算法计算出hash值 ，从而确定其在数据环上的位置，然后从此位置 沿着逆时针行走 ，遇到的第一个服务器就是该数据应该存储的节点。

应用场景

一致性哈希是分布式系统组件负载均衡的首选算法，它既可以在客户端实现，也可以在中间件上实现。其应用有：

• 分布式散列表(DHT)的设计；
• 分布式关系数据库(MySQL)：分库分表时，计算数据与节点的映射关系；
• 分布式缓存：Memcached 的客户端实现了一致性哈希，还可以使用中间件 twemproxy 管理 redis/memcache 集群；
• RPC 框架 Dubbo：用来选择服务提供者；
• 亚马逊的云存储系统 Dynamo；
• 分布式 Web 缓存；
• Bittorrent DHT；
• LVS。

Redis集群如何选择数据库？

Redis集群目前无法做数据库选择，默认在0数据库。

Redis集群最大节点个数是多少？

16384个

如何避免使用 Redis 主从集群时，读到过期数据呢？

为了避免这种情况，建议是，在业务应用中使用 EXPIREAT/PEXPIREAT 命令，把数据的过期时间设置为具体的时间点，避免读到过期数据。

十一、缓存异常问题汇总

缓存异常有四种类型，分别是 缓存和数据库的数据不一致、缓存雪崩、缓存击穿和缓存穿透。

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

共有四种方案：

1. 先更新数据库，后更新缓存
2. 先更新缓存，后更新数据库
3. 先删除缓存，后更新数据库
4. 先更新数据库，后删除缓存

第一种和第二种方案，没有人使用的，

• 第一种方案存在问题是：并发更新数据库场景下，会将脏数据刷到缓存。
• 第二种方案存在的问题是：如果先更新缓存成功，但是数据库更新失败，则肯定会造成数据不一致。

目前主要用第三和第四种方案。

缓存雪崩

在一个 较短 的时间内，缓存中 较多 的key 集中过期，此周期内请求访问过期的数据，redis未命中，redis向数据库获取数据，数据库同时接收到大量的请求无法及时处理导致数据库崩溃。

解决方案：

• 在批量往Redis存数据的时候，把每个Key的失效时间都加个随机值就好了，这样可以保证数据不会在同一时间大面积失效

  setRedis（Key，value，time + Math.random() * 10000）；
  

缓存击穿

缓存击穿跟缓存雪崩有点类似，缓存雪崩是大规模的key失效，而缓存击穿是某个热点的key失效，大并发集中对其进行请求，就会造成大量请求读缓存没读到数据，从而导致高并发访问数据库，引起数据库压力剧增。这种现象就叫做缓存击穿。

解决方案：

• 直接让热点数据永远不过期，定时任务定期去刷新数据就可以了。
• 我们可以在第一个请求去查询数据库的时候对他加一个互斥锁，其余的查询请求都会被阻塞住，直到锁被释放，后面的线程进来发现已经有缓存了，就直接走缓存，从而保护数据库。但这也是性能的瓶颈

缓存穿透

缓存穿透是指用户请求的数据在缓存中不存在即没有命中，同时在数据库中也不存在，导致用户每次请求该数据都要去数据库中查询一遍。

如果有恶意攻击者不断请求系统中不存在的数据，会导致短时间大量请求落在数据库上，造成数据库压力过大，甚至导致数据库承受不住而宕机崩溃。

缓存穿透的关键在于在Redis中查不到key值，它和缓存击穿的根本区别在于传进来的key在Redis中是不存在的。假如有黑客传进大量的不存在的key，那么大量的请求打在数据库上是很致命的问题，所以在日常开发中要对参数做好校验，一些非法的参数，不可能存在的key就直接返回错误提示。

解决方案：

• 添加参数校验 ：可以在接口层添加校验，不合法的直接返回即可，没必要做后续的操作。
• 缓存空值 ：可以为这些key 设置的值设置为null 丢到缓存里面去。后面再出现查询这个key 的请求的时候，直接返回null ,就不用在到 数据库中去走一圈了。但是别忘了设置过期时间。
• 布隆过滤器 ：redis的一个高级用法就是使用布隆过滤器（Bloom Filter）。把已存在数据的key存在布隆过滤器中。当有新的请求时，先到布隆过滤器中查询是否存在，如果不存在该条数据直接返回；如果存在该条数据再查询缓存查询数据库。

缓存预热

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

如果不进行预热，那么Redis初始状态数据为空，系统上线初期，对于高并发的流量，都会访问到数据库中， 对数据库造成流量的压力。

缓存预热解决方案：

• 数据量不大的时候，工程启动的时候进行加载缓存动作；
• 数据量大的时候，设置一个定时任务脚本，进行缓存的刷新；
• 数据量太大的时候，优先保证热点数据进行提前加载到缓存。

什么是缓存降级？TODO

参考：https://blog.csdn.net/weixin_43882788/article/details/122021951

补充

说说 Redis 的高可用吧

• 高可用：通过设计减少系统不能提供服务的时间。
• Redis实现高可用主要有三种方式：主从复制、哨兵模式，以及 Redis 集群。

主从复制 + 哨兵 已经满足了我们的生产环境需要，那为什么还需要使用集群模式呢？

哨兵模式归根节点还是主从模式，在主从模式下我们可以通过增加salve节点来 扩展读并发能力 ，但是没办法扩展写能力和存储能力，存储能力只能是master节点能够承载的上限。所以为了扩展写能力和存储能力，我们就需要引入集群模式。

Redis集群中数据集中在部分哈希槽怎么办？TODO

Redis除了持久化之外还有哪些方法能保证数据不丢失？TODO

Redis对C中的数据结构做了哪些优化？TODO

哈希槽怎么重新分配到其它节点上？