12.Redis学习总结+常见面试题

Redis个人总结

一、Redis 简介
Redis 是一个开源，高级的键值存储和一个适用的解决方案，用于构建高性能，可扩展的Web 应用程序。简单来说 Redis 就是一个数据库，不过与传统数据库不同的是 Redis 的数据是存在内存中的，所以读写速度非常快，因此 Redis 被广泛应用于缓存方向。另外，Redis 也经常用来做分布式锁。Redis 提供了多种数据类型来支持不同的业务场景。除此之外，Redis 支持事务 、持久化、LUA脚本、LRU驱动事件、多种集群方案。

Redis 的优点
以下是 Redis 的一些优点：
异常快 - Redis 非常快，每秒可执行大约 81000 次的设置(SET)操作，每秒大约可执行 110000 次的读取/获取(GET)操作。
支持丰富的数据类型 - Redis 支持开发人员常用的大多数数据类型，例如列表，集合，排序集和散列等等。这使得 Redis 很容易被用来解决各种问题，因为我们知道哪些问题可以更好使用地哪些数据类型来处理解决。
操作具有原子性 - 所有 Redis 操作都是原子操作，这确保如果两个客户端并发访问，Redis 服务器能接收更新的值。
多实用工具 - Redis 是一个多实用工具，可用于多种用例，如：缓存，消息队列(Redis 本地支持发布/订阅)，应用程序中的任何短期数据，例如，web应用程序中的会话，网页命中计数等。

二、Redis 五种基本数据结构

1）字符串 string
Redis 中的字符串是一种动态字符串，这意味着使用者可以修改，它的底层实现有点类似于 Java 中的 ArrayList。
EXPIRE 命令设置过期时间
INCR原子自增函数

2）列表 list
Redis 的列表相当于 Java 语言中的 LinkedList，这意味着 list的插入和删除操作非常快，时间复杂度为 O(1)，但是索引定位很慢，时间复杂度为 O(n)。
链表的基本操作
LPUSH 和 RPUSH 分别可以向 list 的左边（头部）和右边（尾部）添加一个新元素；
LRANGE 命令可以从 list 中取出一定范围的元素；
LINDEX 命令可以从 list 中取出指定下表的元素，相当于 Java 链表操作中的 get(int index) 操作；
使用：队列、关注列表、粉丝列表等

3）字典 hash
Redis 中的字典相当于 Java 中的 HashMap，内部实现也差不多类似，都是通过 “数组 +链表” 的链地址法来解决部分哈希冲突，同时这样的结构也吸收了两种不同数据结构的优点。
Redis 使用 渐进式 rehash 小步扩容搬迁。
常用于存储用户及用户对应的用户信息

4）集合 set
Redis 的集合相当于 Java 语言中的 HashSet，它内部的键值对是无序、唯一的。它的内部实现相当于一个特殊的字典，字典中所有的 value 都是一个值 NULL。
使用：共同好友等

5）有序列表 zset
这可能使 Redis 最具特色的一个数据结构了，它类似于 Java中 SortedSet 和 HashMap 的结合体，一方面它是一个 set，保证了内部 value 的唯一性，另一方面它可以为每个 value 赋予一个 score 值，用来代表排序的权重。它的内部实现用的是一种叫做 「跳跃表」 的数据结构。
使用：积分榜等

三、Redis持久化

Redis 的数据 全部存储在内存中，如果突然宕机，数据就会全部丢失，因此必须有一套机制来保证 Redis 的数据不会因为故障而丢失，这种机制就是 Redis 的 持久化机制，它会将内存中的数据库状态 保存到磁盘中。
从客户端发起请求开始，到服务器真实地写入磁盘，需要发生如下几件事情：

1. 客户端向数据库 发送写命令 (数据在客户端的内存中)
2. 数据库接收到客户端的 写请求 (数据在服务器的内存中)
3. 数据库调用系统 API 将数据写入磁盘 (数据在内核缓冲区中)
4. 操作系统将 写缓冲区 传输到 磁盘控制器 (数据在磁盘缓存中)
5. 操作系统的磁盘控制器将数据 写入实际的物理媒介中 (数据在磁盘中)

Redis 中的两种持久化方式

方式一：RDB快照
Redis 快照 是最简单的 Redis 持久性模式。当满足特定条件时，它将生成数据集的时间点快照，例如如果先前的快照是在2分钟前创建的，并且现在已经至少有 100 次新写入，则将创建一个新的快照。此条件可以由用户配置 Redis 实例来控制，也可以在运行时修改而无需重新启动服务器。快照作为包含整个数据集的单个 .rdb 文件生成。
但我们知道，Redis 是一个 单线程 的程序，这意味着，我们不仅仅要响应用户的请求，还需要进行内存快照。而后者要求 Redis 必须进行 IO 操作，这会严重拖累服务器的性能。还有一个重要的问题是，我们在 持久化的同时，内存数据结构 还可能在 变化，比如一个大型的 hash 字典正在持久化，结果一个请求过来把它删除了，可是这才刚持久化结束，怎么办？
使用系统多进程 COW(Copy On Write) 机制 | fork 函数
操作系统多进程 COW(Copy On Write) 机制 拯救了我们。Redis 在持久化时会调用 glibc 的函数 fork 产生一个子进程，简单理解也就是基于当前进程 复制 了一个进程，主进程和子进程会共享内存里面的代码块和数据段：
为什么 fork 成功调用后会有两个返回值呢？ 因为子进程在复制时复制了父进程的堆栈段，所以两个进程都停留在了 fork 函数中 (都在同一个地方往下继续"同时"执行)，等待返回，所以 一次在父进程中返回子进程的 pid，另一次在子进程中返回零，系统资源不够时返回负数。 (伪代码如下)

pid = os.fork()
if pid > 0:
handle_client_request() # 父进程继续处理客户端请求
if pid == 0:
handle_snapshot_write() # 子进程处理快照写磁盘
if pid < 0:
 # fork error

所以 快照持久化 可以完全交给子进程 来处理，父进程 则继续处理客户端请求。子进程做数据持久化，它不会修改现有的内存数据结构，它只是对数据结构进行遍历读取，然后序列化写到磁盘中。但是 父进程不一样，它必须持续服务客户端请求，然后对 内存数据结构进行不间断的修改。
这个时候就会使用操作系统的 COW 机制来进行 数据段页面的分离。数据段是由很多操作系统的页面组合而成，当父进程对其中一个页面的数据进行修改时，会将被共享的页面复制一份分离出来，然后对这个复制的页面进行修改。这时子进程相应的页面是 没有变化的，还是进程产生时那一瞬间的数据。子进程因为数据没有变化，它能看到的内存里的数据在进程产生的一瞬间就凝固了，再也不会改变，这也是为什么 Redis 的持久化叫「快照」的原因。接下来子进程就可以非常安心的遍历数据了进行序列化写磁盘了。

方式二：AOF
快照不是很持久。如果运行 Redis 的计算机停止运行，电源线出现故障或者您 kill -9 的实例意外发生，则写入 Redis 的最新数据将丢失。尽管这对于某些应用程序可能不是什么大问题，但有些使用案例具有充分的耐用性，在这些情况下，快照并不是可行的选择。
AOF(Append Only File - 仅追加文件) 它的工作方式非常简单：每次执行 修改内存 中数据集的写操作时，都会记录 该操作。假设 AOF 日志记录了自 Redis 实例创建以来 所有的修改性指令序列，那么就可以通过对一个空的 Redis 实例 顺序执行所有的指令，也就是 「重放」，来恢复 Redis 当前实例的内存数据结构的状态。
当 Redis 收到客户端修改指令后，会先进行参数校验、逻辑处理，如果没问题，就立即将该指令文本存储 到 AOF 日志中，也就是说，先执行指令再将日志存盘。这一点不同于 MySQL、LevelDB、HBase 等存储引擎，如果我们先存储日志再做逻辑处理，这样就可以保证即使宕机了，我们仍然可以通过之前保存的日志恢复到之前的数据状态，但是 Redis 为什么没有这么做呢？
没有什么特别的原因。仅仅是因为，由于AOF文件会比较大，为了避免写入无效指令（错误指令），必须先做指令检查？如何检查，只能先执行了。因为语法级别检查并不能保证指令的有效性，比如删除一个不存在的key。而MySQL这种是因为它本身就维护了所有的表的信息，所以可以语法检查后过滤掉大部分无效指令直接记录日志，然后再执行。
更多讨论见：为什么Redis先执行指令，再记录AOF日志，而不是像其它存储引擎一样反过来呢？ - https://www.zhihu.com/question/342427472

AOF 重写
Redis 在长期运行的过程中，AOF 的日志会越变越长。如果实例宕机重启，重放整个 AOF日志会非常耗时，导致长时间 Redis 无法对外提供服务。所以需要对 AOF 日志 “瘦身”。Redis 提供了 bgrewriteaof 指令用于对 AOF 日志进行瘦身。其 原理 就是 开辟一个子进程 对内存进行 遍历 转换成一系列 Redis 的操作指令，序列化到一个新的 AOF 日志文件 中。序列化完毕后再将操作期间发生的 增量 AOF 日志 追加到这个新的 AOF 日志文件中，追加完毕后就立即替代旧的 AOF 日志文件了，瘦身工作就完成了。
fsync
AOF 日志是以文件的形式存在的，当程序对 AOF 日志文件进行写操作时，实际上是将内容写到了内核为文件描述符分配的一个内存缓存中，然后内核会异步将脏数据刷回到磁盘的。我们需要借助 glibc 提供的 fsync(int fd) 函数来讲指定的文件内容 强制从内核缓存刷到磁盘。但 “强制开车” 仍然是一个很消耗资源的一个过程，需要 “节制”！通常来说，生产环境的服务器，Redis 每隔 1s 左右执行一次 fsync 操作就可以了。
Redis 同样也提供了另外两种策略，一个是 永不 fsync，来让操作系统来决定合适同步磁盘，很不安全，另一个是 来一个指令就 fsync 一次，非常慢。但是在生产环境基本不会使用，了解一下即可。

开启AOF持久化功能后，服务器每执行命令，会把命令以协议格式追加到aof_buf缓存区的末尾，不是直接写入文件。将缓冲区内容保存到RDB文件中，Redis有多种策略：
always：所有内容写入并同步到AOF文件中。
eversec：每秒同步一次，由一个线程专门负责。
no：同步由操作系统决定。

Redis 4.0 混合持久化
重启 Redis 时，我们很少使用 RDB来恢复内存状态，因为会丢失大量数据。我们通常使用AOF 日志重放，但是重放 AOF 日志性能相对 RDB 来说要慢很多，这样在 Redis 实例很大的情况下，启动需要花费很长的时间。Redis 4.0 为了解决这个问题，带来了一个新的持久化选项——混合持久化。将 RDB文件的内容和增量的 AOF 日志文件存在一起。这里的 AOF 日志不再是全量的日志，而是 自持久化开始到持久化结束 的这段时间发生的增量 AOF 日志，通常这部分 AOF 日志很小：于是在 Redis 重启的时候，可以先加载RDB的内容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，重启效率因此大幅得到提升。

四、Redis实现分布式锁

单机锁
程序中使用的锁叫单机锁，我们日常中所说的“锁”都泛指单机锁，其分类有很多，大体可分为以下几类：
悲观锁，是数据对外界的修改采取保守策略，它认为线程很容易把数据修改掉，因此在整个数据被修改的过程中都会采取锁定状态，直到一个线程使用完，其他线程才可以继续使用，典型应用是 synchronized；
乐观锁，和悲观锁的概念恰好相反，乐观锁认为一般情况下数据在修改时不会出现冲突，所以在数据访问之前不会加锁，只是在数据提交更改时，才会对数据进行检测，典型应用是 ReadWriteLock 读写锁；
可重入锁，也叫递归锁，指的是同一个线程在外面的函数获取了锁之后，那么内层的函数也可以继续获得此锁，在 Java 语言中 ReentrantLock 和 synchronized 都是可重入锁；
独占锁和共享锁，只能被单线程持有的锁叫做独占锁，可以被多线程持有的锁叫共享锁，独占锁指的是在任何时候最多只能有一个线程持有该锁，比如 ReentrantLock 就是独占锁；而 ReadWriteLock 读写锁允许同一时间内有多个线程进行读操作，读锁就属于共享锁。

分布式锁
分布式锁是控制分布式系统之间同步访问共享资源的一种方式。是为了解决分布式系统中，不同的系统或是同一个系统的不同主机共享同一个资源的问题，它通常会采用互斥来保证程序的一致性，这就是分布式锁的用途以及执行原理。
为何需要分布式锁
使用分布式锁主要有两个场景：避免不同节点重复相同的工作：比如用户执行了某个操作有可能不同节点会发送多封邮件；避免破坏数据的正确性：如果两个节点在同一条数据上同时进行操作，可能会造成数据错误或不一致的情况出现；

Java 中实现分布式锁的常见方式
锁的本质：同一时间只允许一个用户操作。所以理论上，能够满足这个需求的工具我们都能够使用 (就是其他应用能帮我们加锁的)：
1. 基于 MySQL 中的锁：MySQL 本身有自带的悲观锁 for update 关键字，也可以自己实现悲观/乐观锁来达到目的；
2. 基于 Zookeeper 有序节点：Zookeeper 允许临时创建有序的子节点，这样客户端获取节点列表时，就能够当前子节点列表中的序号判断是否能够获得锁；
3. 基于 Redis 的单线程：由于 Redis 是单线程，所以命令会以串行的方式执行，并且本身提供了像 SETNX(set if not exists) 这样的指令，本身具有互斥性；
4. 基于 Memcached 实现分布式锁，可使用 add 方法来实现，如果添加成功了则表示分布式锁创建成功；
每个方案都有各自的优缺点，例如 MySQL 虽然直观理解容易，但是实现起来却需要额外考虑 锁超时、加事务等，并且性能局限于数据库，诸如此类我们在此不作讨论，重点关注Redis。

使用 Redis 实现分布式锁
使用 Redis 实现分布式锁主要需要使用 setnx 方法，也就是 set if not exists（不存在则创建），具体的实现代码如下：

127.0.0.1:6379> setnx lock true
(integer) 1 #创建锁成功
#逻辑业务处理...
127.0.0.1:6379> del lock
(integer) 1 #释放锁

当执行 setnx 命令之后返回值为 1 的话，则表示创建锁成功，否则就是失败。释放锁使用 del 删除即可，当其他程序 setnx 失败时，则表示此锁正在使用中，这样就可以实现简单的分布式锁了。
但是以上代码有一个问题，就是没有设置锁的超时时间，因此如果出现异常情况，会导致锁未被释放，而其他线程又在排队等待此锁就会导致程序不可用。
有人可能会想到使用 expire 来设置键值的过期时间来解决这个问题，例如以下代码：

127.0.0.1:6379> setnx lock true
(integer) 1 #创建锁成功
127.0.0.1:6379> expire lock 30 #设置锁的(过期)超时时间为 30s
(integer) 1 
#逻辑业务处理...
127.0.0.1:6379> del lock
(integer) 1 #释放锁

但这样执行仍然会有问题，因为 setnx lock true 和 expire lock 30 命令是非原子的，也就是一个执行完另一个才能执行。但如果在 setnx 命令执行完之后，发生了异常情况，那么就会导致 expire 命令不会执行，因此依然没有解决死锁的问题。
这个问题在 Redis 2.6.12 之前一直没有得到有效的处理，当时的解决方案是在客户端进行原子合并操作，于是就诞生了很多客户端类库来解决此原子问题，不过这样就增加了使用的成本。因为你不但要添加 Redis 的客户端，还要为了解决锁的超时问题，需额外的增加新的类库，这样就增加了使用成本，但这个问题在 Redis 2.6.12 版本中得到了有效的处理。
在 Redis 2.6.12 中我们可以使用一条 set 命令来执行键值存储，并且可以判断键是否存在以及设置超时时间了，如下代码所示：

127.0.0.1:6379> set lock true ex 30 nx
OK #创建锁成功

其中，ex 是用来设置超时时间的，而 nx 是 not exists 的意思，用来判断键是否存在。如果返回的结果为“OK”则表示创建锁成功，否则表示此锁有人在使用。

锁超时
从上面的内容可以看出，使用 set 命令之后好像一切问题都解决了，但在这里我要告诉你，其实并没有。例如，我们给锁设置了超时时间为 10s，但程序的执行需要使用 15s，那么在第 10s 时此锁因为超时就会被释放，这时候线程二在执行 set 命令时正常获取到了锁，于是在很短的时间内 2s 之后删除了此锁，这就造成了锁被误删的情况：
锁被误删的解决方案是在使用 set 命令创建锁时，给 value 值设置一个归属标识。例如，在 value 中插入一个 UUID，每次在删除之前先要判断 UUID 是不是属于当前的线程，如果属于再删除，这样就避免了锁被误删的问题。
注意：在锁的归属判断和删除的过程中，不能先判断锁再删除锁，如下代码所示：

if(uuid.equals(uuid)){ // 判断是否是自己的锁
	del(luck); // 删除锁
}

应该把判断和删除放到一个原子单元中去执行，因此需要借助 Lua 脚本来执行，在 Redis 中执行 Lua 脚本可以保证这批命令的原子性，它的实现代码如下：

/**
 * 释放分布式锁
 * @param jedis Redis客户端
 * @param lockKey 锁的 key
 * @param flagId 锁归属标识
 * @return 是否释放成功
 */
public static boolean unLock(Jedis jedis, String lockKey, String flagId) {
     
    String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
    Object result = jedis.eval(script, Collections.singletonList(lockKey), Collections.singletonList(flagId));
    if ("1L".equals(result)) {
      // 判断执行结果
        return true;
    }
    return false;
}

其中，Collections.singletonList() 方法是将 String 转成 List，因为 jedis.eval() 最后两个参数要求必须是 List 类型。

锁超时可以通过两种方案来解决：
把执行耗时的方法从锁中剔除，减少锁中代码的执行时间，保证锁在超时之前，代码一定可以执行完；
把锁的超时时间设置的长一些，正常情况下我们在使用完锁之后，会调用删除的方法手动删除锁，因此可以把超时时间设置的稍微长一些。

五、Redis过期策略和内存淘汰机制

1.过期策略
对于已经过期的数据，Redis 将使用两种策略来删除这些过期键，它们分别是惰性删除和定期删除。
惰性删除是指 Redis 服务器不主动删除过期的键值，而是当访问键值时，再检查当前的键值是否过期，如果过期则执行删除并返回 null 给客户端；如果没过期则正常返回值信息给客户端。
它的优点是不会浪费太多的系统资源，只是在每次访问时才检查键值是否过期。缺点是删除过期键不及时，造成了一定的空间浪费。

定期删除是指 Redis 服务器每隔一段时间会检查一下数据库，看看是否有过期键可以被清除。
默认情况下 Redis 定期检查的频率是每秒扫描 10 次，用于定期清除过期键。当然此值还可以通过配置文件进行设置，在 redis.conf 中修改配置“hz”即可，默认的值为“hz 10”。
小贴士：定期删除的扫描并不是遍历所有的键值对，这样的话比较费时且太消耗系统资源。Redis 服务器采用的是随机抽取形式，每次从过期字典中，取出 20 个键进行过期检测，过期字典中存储的是所有设置了过期时间的键值对。如果这批随机检查的数据中有 25% 的比例过期，那么会再抽取 20 个随机键值进行检测和删除，并且会循环执行这个流程，直到抽取的这批数据中过期键值小于 25%，此次检测才算完成。

以上是 Redis 服务器对待过期键的处理方案，当 Redis 的内存超过最大允许的内存之后，Redis 会触发内存淘汰策略，这和过期策略是完全不同的两个概念，经常有人把二者搞混，这两者一个是在正常情况下清除过期键，一个是在非正常情况下为了保证 Redis 顺利运行的保护策略。
当 Redis 内存不够用时，Redis 服务器会根据服务器设置的淘汰策略，删除一些不常用的数据，以保证 Redis 服务器的顺利运行。

2.Redis 内存淘汰策略
可以使用 config get maxmemory-policy 命令，来查看当前 Redis 的内存淘汰策略，示例代码如下：

127.0.0.1:6379> config get maxmemory-policy
1) "maxmemory-policy"
2) "noeviction"

在 4.0 版本之前 Redis 的内存淘汰策略有以下 6 种。
noeviction：不淘汰任何数据，当内存不足时，执行缓存新增操作会报错，它是 Redis 默认内存淘汰策略。
allkeys-lru：淘汰整个键值中最久未使用的键值。
allkeys-random：随机淘汰任意键值。
volatile-lru：淘汰所有设置了过期时间的键值中最久未使用的键值。
volatile-random：随机淘汰设置了过期时间的任意键值。
volatile-ttl：优先淘汰更早过期的键值。
可以看出我们上面示例使用的是 Redis 默认的内存淘汰策略“noeviction”。
而在 Redis 4.0 版本中又新增了 2 种淘汰策略：
volatile-lfu，淘汰所有设置了过期时间的键值中最少使用的键值；
allkeys-lfu，淘汰整个键值中最少使用的键值。
小贴士：从以上内存淘汰策略中可以看出，allkeys-xxx 表示从所有的键值中淘汰数据，而 volatile-xxx 表示从设置了过期键的键值中淘汰数据。
这个内存淘汰策略我们可以通过配置文件来修改，redis.conf 对应的配置项是“maxmemory-policy noeviction”，只需要把它修改成我们需要设置的类型即可。
需要注意的是，如果使用修改 redis.conf 的方式，当设置完成之后需要重启 Redis 服务器才能生效。
还有另一种简单的修改内存淘汰策略的方式，我们可以使用命令行工具输入“config set maxmemory-policy noeviction”来修改内存淘汰的策略，这种修改方式的好处是执行成功之后就会生效，无需重启 Redis 服务器。但它的坏处是不能持久化内存淘汰策略，每次重启 Redis 服务器之后设置的内存淘汰策略就会丢失。

3.Redis 内存淘汰算法
内存淘汰算法主要包含两种：LRU 淘汰算法和 LFU 淘汰算法。
LRU（ Least Recently Used，最近最少使用）淘汰算法：是一种常用的页面置换算法，也就是说最久没有使用的缓存将会被淘汰。
LRU 是基于链表结构实现的，链表中的元素按照操作顺序从前往后排列，最新操作的键会被移动到表头，当需要进行内存淘汰时，只需要删除链表尾部的元素即可。
Redis 使用的是一种近似 LRU 算法，目的是为了更好的节约内存，它的实现方式是给现有的数据结构添加一个额外的字段，用于记录此键值的最后一次访问时间。Redis 内存淘汰时，会使用随机采样的方式来淘汰数据，它是随机取 5 个值 (此值可配置) ，然后淘汰最久没有使用的数据。

LFU（Least Frequently Used，最不常用的）淘汰算法：最不常用的算法是根据总访问次数来淘汰数据的，它的核心思想是“如果数据过去被访问多次，那么将来被访问的频率也更高”。
LFU 相对来说比 LRU 更“智能”，因为它解决了使用频率很低的缓存，只是最近被访问了一次就不会被删除的问题。如果是使用 LRU 类似这种情况数据是不会被删除的，而使用 LFU 的话，这个数据就会被删除。
Redis 内存淘汰策略使用了 LFU 和近 LRU 的淘汰算法，具体使用哪种淘汰算法，要看服务器是如何设置内存淘汰策略的，也就是要看“maxmemory-policy”的值是如何设置的。

六、Redis集群

快速搭建集群

数据一致性（缓存更新）：先更新数据库，再删除缓存

常见面试题

1. redis 为什么这么快
2. 为什么要用 redis/为什么要用缓存
3. 为什么要用 redis 而不用 map/guava 做缓存?
4. redis 和 memcached 的区别
5. redis 常见数据结构以及使用场景分析（String、Hash、List、Set、Sorted Set）
6. redis 设置过期时间
7. redis 内存淘汰机制(MySQL里有2000w数据，Redis中只存20w的数据，如何保证Redis中的数据都是热点数据?)
8. redis 持久化机制(怎么保证 redis 挂掉之后再重启数据可以进行恢复)
9. redis 事务
10. 缓存雪崩和缓存穿透问题解决方案
11. 如何解决 Redis 的并发竞争 Key 问题
12. 如何保证缓存与数据库双写时的数据一致性?