redis面试总结

一、为啥单线程redis那么快？

• 完全基于内存，绝大部分请求是纯粹的内存操作，非常快速；
• 数据结构简单，对数据操作也简单；
• 采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗；
• 使用多路 I/O 复用模型，非阻塞 IO。

怎么理解单线程？

• 首先咱得知道Redis是单线程。
• 主要是指 Redis的网络 IO 和键值对读写是由一个线程来完成，这也是 Redis 对外提供键值存储服务的主要流程。
• 但 Redis 的其他功能，比如持久化等其实是由额外线程执行的。

为什么用再谈单线程？

其实主要是为了避免多线程的开销问题。为了避免多线程编程面临的共享资源的并发访问控制问题，锁的控制以及死锁问题导致的性能开销，为了系统代码的易调试性和可维护性。

再谈Redis的单线程怎么用

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 的响应性能。

再谈它是内存数据库并有高效数据结构

埋坑 Redis 的大部分操作在内存上完成，再加上它采用了高效的数据结构，例如哈希表和跳表，这是它实现高性能的一个重要原因。

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

redis值有五种数据类型，

• String（字符串）可以做简单的键值对缓存；
• List（列表）可以存储一些列表型的数据结构；
• Hash（哈希）可以存结构化的数据，比如一个对象；
• Set（集合）可以做交集、并集、差集的操作，比如交集，可以把两个人的粉丝列表整一个交集；
• Sorted Set（有序集合）去重但可以排序，如获取排名前几名的用户。

String 类型的底层实现只有一种数据结构，简单动态字符串。Hash是当数据量较小时用压缩列表实现，较大时用哈希表实现并且不可逆就行了。

谈谈Hash?

首先一个哈希表，其实就是一个数组，数组的每个元素称为一个哈希桶。一个哈希表是由多个哈希桶组成的，每个哈希桶中保存了键值对数据。

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

如何解决？

• 拉链法。链式哈希也很容易理解，就是指同一个哈希桶中的多个元素用一个链表来保存，它们之间依次用指针连接。
• rehash，过程分为三步：
  • 给哈希表 2 分配更大的空间，例如是当前哈希表 1 大小的两倍；
  • 把哈希表 1 中的数据重新映射并拷贝到哈希表 2 中；
  • 释放哈希表 1 的空间。
• **渐进式 rehash。**方案二第二步涉及大量的数据拷贝，如果一次性把哈希表 1 中的数据都迁移完，会造成 Redis 线程阻塞，无法服务其他请求。
  • 简单来说就是在第二步拷贝数据时，Redis 仍然正常处理客户端请求，每处理一个请求时，从哈希表 1 中的第一个索引位置开始，顺带着将这个索引位置上的所有 entries 拷贝到哈希表 2 中；等处理下一个请求时，再顺带拷贝哈希表 1 中的下一个索引位置的 entries。把一次性大量拷贝的开销，分摊到了多次处理请求的过程中，避免了耗时操作，保证了数据的快速访问。

底层数据结构方面：可以谈压缩列表、跳表

首先 redis集合类型的底层数据结构主要有 5 种：整数数组、双向链表、哈希表、压缩列表和跳表。

• 压缩列表实际上类似于一个数组，数组中的每一个元素都对应保存一个数据。和数组不同的是，压缩列表在表头有三个字段 zlbytes、zltail 和 zllen，分别表示列表长度、列表尾的偏移量和列表中的 entry 个数；压缩列表在表尾还有一个 zlend，表示列表结束。
  
• 跳表在链表的基础上，增加了多级索引，通过索引位置的几个跳转，实现数据的快速定位
  

时间复杂度？

String数据类型和它具体实现？TODO

三、谈谈持久化

什么是Redis持久化？

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

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

• RDB将当前数据状态进行保存，快照形式，存储数据结果，存储格式简单，关注点在数据
• AOF将数据的操作过程进行保存，日志形式，存储操作过程，存储格式复杂，关注点在数据的操作过程

谈谈AOF

AOF怎么实现的？

• AOF(append only file)持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令达到恢复数据的目的。 与RDB相比可以简单描述为 改记录数据为记录数据产生的过程
• AOF的主要作用是 解决了数据持久化的实时性，目前已经是Redis持久化的主流方式
• 优先使用AOF

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文件中的数据不一致。

• 为了解决这种数据不一致的问题，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怎么实现的？

和 AOF 相比，RDB 记录的是某一时刻的数据，并不是操作，所以，在做数据恢复时，我们可以直接把 RDB 文件读入内存，很快地完成恢复。

Redis 的数据都在内存中，为了提供所有数据的可靠性保证，它执行的是全量快照，也就是说，把内存中的所有数据都记录到磁盘中

通过bgsave命令在后台执行全量快照

RDB优缺点是什么？

优点：

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

缺点：

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

快照时数据能修改吗？

可以，Redis 就会借助操作系统提供的 写时复制技术 ，在执行快照的同时，正常处理写操作。如果主线程要修改一块数据（例如图中的键值对 C），那么， 这块数据就会被复制一份 ，生成该数据的副本（键值对 C’）。然后，主线程在这个数据副本上进行修改。同时，bgsave 子进程可以继续把原来的数据（键值对 C）写入 RDB 文件。

可以每秒做一次快照吗？

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

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

混合使用 AOF 日志和内存快照。

内存快照以一定的频率执行，在两次快照之间，使用 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中有个设置时间过期的功能，即对存储在redis数据库中的值可以设置一个过期时间。

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

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

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

时效性数据的存储结构

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

数据删除策略有哪些？

定时删除 、惰性删除

• 定时删除：创建一个定时器，当key设置有过期时间，且过期时间到达时，由定时器任务立即执行对键的删除操作。
  • 优点：节约内存，到时就删除，快速释放掉不必要的内存占用
  • 缺点：CPU压力很大，无论CPU此时负载量多高，均占用CPU，会影响redis服务器响应时间和指令吞吐量
  • 总结：用处理器性能换取存储空间（拿时间换空间）
• 惰性删除：数据到达过期时间，不做处理。等下次访问该数据时， 如果未过期，返回数据；发现已过期，删除，返回不存在。内部执行 expireIfNeeded() 函数，检查数据是否过期，所有的get操作都与它绑定
  • 优点：节约CPU性能，发现必须删除的时候才删除
  • 缺点：内存压力很大，出现长期占用内存的数据
  • 总结：用存储空间换取处理器性能（拿时间换空间）

定期删除

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

八、Redis 主从复制

redis 主从复制是啥？

主从复制：指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点（Master/Leader），后者称为从节点（Slave/Follower）。

• 数据的复制是单向的！只能由主节点复制到从节点（主节点以写为主、从节点以读为主）。
• Redis的主从复制是异步复制，异步分为两个方面：
  • 一个是master服务器在将数据同步到slave时是异步的，因此master服务器在这里仍然可以接收其他请求
  • 一个是slave在接收同步数据也是异步的。

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

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

为什么要采用读写分离的方式呢？

• 如果不采用读写分离的方式，对于数据一致性的维护需要涉及到加锁、实例间协商是否完成修改等一系列操作的巨额的开销。
• 主从库模式一旦采用了读写分离，所有数据的修改只会在主库上进行，不用协调三个实例。主库有了最新的数据后，会同步给从库，这样，主从库的数据就是一致的。

主从复制相关命令？TODO

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

1、建立连接阶段（即准备阶段，slave连接master）

• 第一阶段是主从库间建立连接、协商同步的过程，主要是为全量复制做准备。在这一步，从库和主库建立起连接，并告诉主库即将进行同步，主库确认回复后，主从库间就可以开始同步了。psync 命令包含了 主库的 runID 和复制进度 offset 两个参数。
  2、数据同步阶段
• 在第二阶段，主库执行bgsave生成RDB，将所有数据同步给从库。从库收到数据后，在本地完成数据加载。从库加载数据时，主库不会被阻塞，仍然可以正常接收请求。为了保证主从库的数据一致性， 主库会在内存中用专门的 replication buffer（复制缓冲区），记录 RDB 文件生成后收到的所有写操作。
  3、命令传播阶段
• 当主库完成 RDB 文件发送后，就会把此时 replication buffer 中的修改操作发给从库，从库再重新执行这些操作。

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

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

数据同步阶段master有什么注意事项？

• 如果master数据量巨大，数据同步阶段应避开流量高峰期，避免造成master阻塞，影响业务正常执行

• 复制缓冲区大小设定不合理，会导致数据溢出。如进行全量复制周期太长，进行部分复制时发现数据已经存在丢失的情况，必须进行第二次全量复制，致使 slave陷入死循环状态。

  # 默认为1M
  repl-backlog-size 1mb
  

• master单机内存占用主机内存的比例不应过大，建议使用**50%-70%**的内存，留下30%-50%的内存 用于执行bgsave命令和创建复制缓冲区。

命令传播阶段要是主从库间的网络断连了 redis 如何处理？数据还能保持一致吗？

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

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

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

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

当主从库断连后，主库会把断连期间收到的写操作命令，写入 replication buffer，同时也会把这些操作命令也写入 repl_backlog_buffer 这个缓冲区。

即同时主服务器进行命令传播期间（从服务器完成全量复制后，主服务器接受到写命令，会同时将命令传播到从服务器），不仅将写命令发送给所有服务器，还会将写命令写入复制积压缓冲区。

所以如果网络中断后，主从库的连接恢复之后，从库首先会给主库发送 psync 命令，并把自己当前的 slave_repl_offset 发给主库，主库会判断自己的 master_repl_offset 和 slave_repl_offset 之间的差距。

在网络断连阶段，主库可能会收到新的写操作命令，所以，一般来说，master_repl_offset 会大于 slave_repl_offset。此时，主库只用把 master_repl_offset 和 slave_repl_offset 之间的命令操作同步给从库就行。

什么是 repl_backlog_buffer？它和replication buffer之间的区别？

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

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

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

二者区别？

首先来说一下复制缓冲区。

• 作用：主节点开始和一个从节点进行全量同步时，会为从节点创建一个输出缓冲区，这个缓冲区就是复制缓冲区。当主节点向从节点发送 RDB 文件时，如果又接收到了写命令操作，就会把它们暂存在复制缓冲区中。等 RDB 文件传输完成，并且在从节点加载完成后，主节点再把复制缓冲区中的写命令发给从节点，进行同步。
• 对主从同步的影响：如果主库传输 RDB 文件以及从库加载 RDB 文件耗时长，同时主库接收的写命令操作较多，就会 导致复制缓冲区被写满而溢出 。一旦溢出 ，主库就会关闭和从库的网络连接， 重新开始全量同步 。所以，我们可以通过调整 client-output-buffer-limit 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 命令的响应超时了，那么，哨兵就会先把它标记为“主观下线”。

通常会采用多实例组成的集群模式进行部署，这也被称为哨兵集群。引入多个哨兵实例一起来判断，就可以避免单个哨兵因为自身网络状况不好，而误判主库下线的情况。同时，多个哨兵的网络同时不稳定的概率较小，由它们一起做决策，误判率也能降低。

只有大多数的哨兵实例，都判断主库已经“主观下线”了，主库才会被标记为“客观下线”。

如何选定新主库呢？

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

筛选：检查从库的当前在线状态，还要判断它之前的网络连接状态。如果从库总是和主库断连，而且断连次数超出了一定的阈值，我们就有理由相信，这个从库的网络状况并不是太好，就可以把这个从库筛掉了。

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

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

哨兵集群是怎么建立的？

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

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

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

• 哨兵给主库发送 INFO 命令，主库接受到这个命令后，就会 把从库列表返回给哨兵 。接着，哨兵就可以根据从库列表中的连接信息，和每个从库建立连接，并在这个连接上持续地对从库进行监控。
  
  哨兵和客户端间的信息同步：基于 pub/sub 机制的客户端事件通知
• 哨兵就是一个运行在特定模式下的 Redis 实例，只不过它并不服务请求操作，只是完成监控、选主和通知的任务。所以，每个哨兵实例也提供 pub/sub 机制，客户端可以从哨兵订阅消息 。哨兵提供的消息订阅频道有很多，不同频道包含了主从库切换过程中的不同关键事件。

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

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

十、redis集群？

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

首先谈数据分区规则

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

再谈分区具体方案

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的新增或减少而找不到。
  • 并且增加或减少master时Redis cluster移动hash slot的成本是非常低的。

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

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

最后谈实例通信机制

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

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映射到一个具有232次方个桶空间中，即0-(232-1)的数字空间中。我们可以将其用一个首尾相连的闭合环形表示，如下图所示：

图中列出了一个虚拟的圆环，上面有0-232个节点位置。算法首先需要计算出存储节点在圆环上的位置。具体可以选择服务器的ip或主机名作为关键字进行哈希，这样每台机器就能确定其在哈希环上的位置。这一点是为了保证算法的分散性：节点的位置跟具体多少个节点没关系，只跟节点的内在特性有关系。

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

Redis集群如何选择数据库？

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

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

16384个

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

参考第四部分的redis过期数据删除策略

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

十一、应用场景解决方案

缓存预热

问题描述：

• 请求数量较高
• 主从之间数据吞吐量较大，数据同步操作频度较高

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

缓存雪崩

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

解决方案：

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

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

• 如果Redis是集群部署，将热点数据均匀分布在不同的Redis库中也能避免全部失效的问题。

缓存击穿

问题描述：Redis中某个key过期，该key访问量巨大，多个数据请求从服务器直接压到Redis后，均未命中Redis在短时间内发起了大量对数据库中同一数据的访问

解决方案：

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

缓存穿透

问题描述：在正常的情况下，用户查询数据都是存在的，但是在异常情况下，缓存与数据都没有数据，但是用户不断发起请求，这样每次请求都会打到数据库上面去，这时的用户很可能是攻击者，攻击会导致数据库压力过大，严重会击垮数据库。

解决方案：

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