Redis常见题型

Redis

Redis是一个高性能的非关系型的键值对数据库，使用C编写实现的。与传统的数据库不同的是Redis是存在内存中的，所以读写速度非常快，每秒可以处理超过10万次的读写操作，这也是Redis常常被用作缓存的原因。

Redis的优缺点？

优点：

• 读写性能好，读的速度可达110000次/s，写的速度可达81000次/s。
• 支持数据持久化，有AOF和RDB两中持久化方式
• 数据结构丰富，支持String、List、Set、Hash等结构
• 支持事务，Redis所有的操作都是原子性的，并且还支持几个操作合并后的原子性执行，原子性指操作要么成功执行，要么失败不执行，不会执行一部分。
• 支持主从复制，主机可以自动将数据同步到从机，进行读写分离。

缺点：

• 因为Redis是将数据存到内存中的，所以会受到内存大小的限制，不能用作海量数据的读写
• Redis不具备自动容错和恢复功能，主机或从机宕机会导致前端部分读写请求失败，需要重启机器或者手动切换前端的IP才能切换。

Redis6.0之前是单线程的，为什么Redis6.0之前采用单线程而不采用多线程呢？

简单来说，就是Redis官方认为没必要，单线程的Redis的瓶颈通常在CPU的IO，而在使用Redis时几乎不存在CPU成为瓶颈的情况。使用Redis主要的瓶颈在内存和网络，并且使用单线程也存在一些优点，比如系统的复杂度较低，可为维护性较高，避免了并发读写所带来的一系列问题。

Redis为什么这么快主要有以下几个原因：

• 运行在内存中
• 数据结构简单
• 使用多路IO复用技术
• 单线程实现，单线程避免了线程切换、锁等造成的性能开销。

Redis6.0之后为什么引入了多线程？

前面说了那么多Redis使用单线程的原因，但从Redis6.0后开始支持多线程了，简直打脸有点快。那么为什么较新的Redis版本又开始支持多线程了呢？

前面也说了Redis的瓶颈在内存和网络，Redis6.0引入多线程主要是为了解决网路IO读写这个瓶颈，执行命令还是单线程执行的，所以也不存在线程安全问题。

Redis6.0默认是否开启了多线程呢？

默认是没有开启的，如需开启，需要修改配置文件redis.conf：io-threads-do-reads no，no改为yes

Redis的数据类型有哪些？

Redis的常见的数据类型有String、Hash、Set、List、ZSet。还有三种不那么常见的数据类型：Bitmap、HyperLogLog、Geospatial。

Redis的应用场景有哪些？

• 缓存：Redis基于内存，读写速度非常快，并且有键过期功能和键淘汰策略，可以作为缓存使用。
• 排行榜：Redis提供的有序集合可以很方便地实现排行榜。
• 分布式锁：Redis的setnx功能来实现分布式的锁。
• 社交功能：实现共同好友、共同关注等
• 计数器：通过String进行自增自减实现计数功能
• 消息队列：Redis提供了发布、订阅、阻塞队列等功能，可以实现一个简单的消息队列。

Redis是单线程的，如何提高CPU的利用率？

可以在一个服务器上部署多个Redis实例，把他们当作不同的服务器使用。

过期键的删除策略

键的过期删除策略

常见的过期删除策略是惰性删除、定期删除、定时删除。

• 惰性删除：只有访问这个键时才会检查它是否过期，如果过期则清除。**优点：**最大化地节约CPU资源。**缺点：**如果大量过期键没有被访问，会一直占用大量内存。
• 定时删除：为每个设置过期时间的key都创造一个定时器，到了过期时间就清除。**优点：**该策略可以立即清除过期的键。**缺点：**会占用大量的CPU资源去处理过期的数据。
• 定期删除：每隔一段时间就对一些键进行检查，删除其中过期的键。该策略是惰性删除和定时删除的一个折中，既避免了占用大量CPU资源又避免了出现大量过期键不被清除占用内存的情况。

Redis中同时使用了惰性删除和定期删除两种。

Redis的持久化

什么是Redis的持久化？

因为Redis是基于内存的，为了让防止一些意外情况导致数据丢失，需要将数据持久化到磁盘上。

Redis常见的持久化机制有哪些？有什么有优缺点？

Redis提供了两种不同的持久化方式，一种是RDB，一种是AOF。

RDB

RDB是redis默认的持久化方式，按照一定的时间间隔将内存的数据以快照的形式保存到硬盘，恢复时是将快照读取到内存中。RDB持久化实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。

优点：

• 适合对大规模的数据恢复，比AOF的启动效率高
• 只有一个文件 dump.rdb，方便持久化
• 性能最大化，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。

缺点：

• 数据安全性低，在一定间隔时间内做一次备份，如果Redis突然宕机，会丢失最后一次快照的修改
• 由于RDB是通过fork子进程来协助完成数据持久化工作的，因此当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。

AOF

AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。

优点：

• 具备更高的安全性，Redis提供了3种同步策略，分别是每秒同步、每修改同步和不同步。相比RDB突然宕机丢失的数据会更少，每秒同步会丢失一秒种的数据，每修改同步会不会丢失数据。
• 由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。
• AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作，可以通过该文件完成数据的重建。

缺点：

• 对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
• 根据AOF选择同步策略的不同，效率也不同，但AOF在运行效率上往往会慢于RDB。

Redis的事务

什么是Redis的事务

Redis的事务是一个单独的隔离操作，事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断，所以Redis事务是在一个队列中，一次性、顺序性、排他性地执行一系列命令。

Redis 事务的主要作用就是串联多个命令防止别的命令插队。

Redis事务的相关命令

Redis事务相关的命令主要有以下几种：

• DISCARD：命令取消事务，放弃执行事务队列内的所有命令，恢复连接为非 (transaction) 模式，如果正在使用 WATCH 命令监视某个(或某些) key，那么取消所有监视，等同于执行命令 UNWATCH 。
• EXEC：执行事务队列内的所有命令。
• MULTI：用于标记一个事务块的开始。
• UNWATCH：用于取消 WATCH命令对所有 key 的监视。如果已经执行过了EXEC或DISCARD命令，则无需再执行UNWATCH命令，因为执行EXEC命令时，开始执行事务，WATCH命令也会生效，而 DISCARD命令在取消事务的同时也会取消所有对 key 的监视，所以不需要再执行UNWATCH命令了
• WATCH：用于标记要监视的key，以便有条件地执行事务，WATCH命令可以监控一个或多个键，一旦其中有一个键被修改（或删除），之后的事务就不会执行。

Redis事务执行的三个阶段

1. 开始事务（MULTI）
2. 命令入列
3. 执行事务（EXEC）

Redis事务的特性

• Redis事务不保证原子性，单条的Redis命令是原子性的，但事务不能保证原子性。
• Redis事务是有隔离性的，但没有隔离级别，事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。（顺序性、排他性）
• Redis事务不支持回滚，Redis执行过程中的命令执行失败，其他命令仍然可以执行。（一次性）

Redis事务为什么不支持回滚？

在Redis的事务中，命令允许失败，但是Redis会继续执行其它的命令而不是回滚所有命令，是不支持回滚的。

主要原因有以下两点：

• Redis 命令只在两种情况失败：
  • 语法错误的时候才失败（在命令输入的时候不检查语法）。
  • 要执行的key数据类型不匹配：这种错误实际上是编程错误，这应该在开发阶段被测试出来，而不是生产上。
• 因为不需要回滚，所以Redis内部实现简单并高效。（在Redis为什么是单线程而不是多线程也用了这个思想，实现简单并且高效）

缓存穿透

key对应的数据在数据库中并不存在，每次针对此key的请求从缓存中获取不到，请求都会到数据库，从而可能压垮数据库。比如用一个不存在的用户id获取用户信息，不论缓存还是数据库都没有，若黑客利用此漏洞进行攻击可能压垮数据库。

数据库没有，缓存没有

解决：1.将这个空对象设置到缓存里边去。下次再请求的时候，就可以从缓存里边获取了。这种情况我们一般会将空对象设置一个较短的过期时间。

2.对参数进行效验，不合法参数进行拦截。

缓存击穿

某个key对应的数据库中存在，但在Redis中的某个节点过期了，此时若有大量并发请求过来，这些请求发现缓存过期，都会从后端DB加载数据并回到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。

解决办法：1.热点数据设置永不过期

2.枷锁：上面的现象是多个线程去查询数据库的这条数据，那么我们可以在第一个查询数据的请求上使用一个互斥锁来锁住他，其他的线程走到这一步拿不到锁就等着，等第一个线程查询到了数据，然后将数据放到Redis缓存起来。后面的线程进来发现已经有缓存了，就直接走缓存。

缓存雪崩

缓存雪崩是指，在高并发情况下大量缓存失效，或者缓存层出现故障。于是所有的请求都会达到数据库，数据库的调用量会暴增，造成数据库也会挂掉的情况

解决方法：

1.随机设置key失效时间，避免大量key集体失效。setRedis（Key，value，time + Math.random() * 10000）；
2.若是集群部署，可将热点数据均匀分布在不同的 Redis 库中也能够避免 key 全部失效问题
3.不设置过期时间
4.跑定时任务，在缓存失效前刷进新的缓存