面试题 ------Redis

什么是NoSQL数据库

• NoSQL(NoSQL = *Not Only SQL* )，意即“不仅仅是SQL”，泛指**非关系型的数据库**。

• NoSQL 不依赖业务逻辑方式存储，而以简单的key-value模式存储。因此大大的增加了数据库的扩展能力。

  • l 不遵循SQL标准
  • 不支持ACID
  • 远超于SQL的性能。

• NoSQL适用场景

  • 对数据高并发的读写
  • 海量数据的读写
  • 对数据高可扩展性的

• NoSQL不适用场景

  • 需要事务支持
  • 基于sql的结构化查询存储，处理复杂的关系,需要即席查询。

(用不着sql的和用了sql也不行的情况，请考虑用NoSql)

redis 是什么？

Redis(Remote Dictionary Server) 是一个使用 C 语言编写的，开源的（BSD许可）高性能非关系型（NoSQL）的键值对数据库。

Redis 可以存储键和五种不同类型的值之间的映射。键的类型只能为字符串，值支持五种数据类型：字符串、列表、集合、散列表、有序集合。

与传统数据库不同的是 Redis 的数据是存在内存中的，所以读写速度非常快，因此 redis 被广泛应用于缓存方向，每秒可以处理超过 10万次读写操作，是已知性能最快的Key-Value DB。另外，Redis 也经常用来做分布式锁。除此之外，Redis 支持事务 、持久化、LUA脚本、LRU驱动事件、多种集群方案。

redis 有什么优缺点

优点

• 读写性能优异， Redis能读的速度是110000次/s，写的速度是81000次/s。
• 支持数据持久化，支持AOF和RDB两种持久化方式。
• 支持事务，Redis的所有操作都是原子性的，同时Redis还支持对几个操作合并后的原子性执行。
• 数据结构丰富，除了支持string类型的value外还支持hash、set、zset、list等数据结构。
• 支持主从复制，主机会自动将数据同步到从机，可以进行读写分离。

缺点

• 数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。
• Redis 不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复。
• 主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性。
• Redis 较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。为避免这一问题，运维人员在系统上线时必须确保有足够的空间，这对资源造成了很大的浪费。

redis 为啥这么快

1、完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。数据存在内存中，类似于 HashMap，HashMap 的优势就是查找和操作的时间复杂度都是O(1)；

2、数据结构简单，对数据操作也简单，Redis 中的数据结构是专门进行设计的；

3、采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗；

4、使用多路 I/O 复用模型，非阻塞 IO；

5、使用底层模型不同，它们之间底层实现方式以及与客户端之间通信的应用协议不一样，Redis 直接自己构建了 VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求；

redis 的数据类型有哪些

Redis主要有5种数据类型，包括String，List，Set，Zset，Hash，满足大部分的使用要求

数据类型	存储结构	操作	底层实现	适用场景
String	字符串	String 类型是二进制安全的，value 最多512M，原子性的自增和自减，对字符串的一部分进行操作，设置过期时间	简单动态字符串，类似于Java 中的ArrayList	对键值对进行缓存
List	列表	两端压入或弹出元素，对单个或多个元素进行修剪，或者保留一个范围中的元素	底层是快速链表quickList，当元素较少的时候使用zipList ，也就是压缩列表，将所有元素挨着存储，分配一块连续内存，元素较多的时候就将ziplist 连接成quickList	存储一些列表型的数据结构，类似粉丝列表、文章的评论列表之类的数据
Set	无序结合	添加、获取、移除单个元素，检查一个元素是否存在于集合中，计算交集、并集、差集，从集合里面随机获取元素	底层是dict ，使用hash表实现，所有value 指向同一个值 null ，类似于java 中 hashset	交集、并集、差集的操作，比如交集，可以把两个人的粉丝列表整一个交集
Hash	键值集合	添加、获取、移除单个键值对，获取所有键值对，检查某个键是否存在	当field-value长度较短且个数较少时，使用ziplist，否则使用hashtable	结构化的数据，比如一个对象，存储对象的字段和值对应起来
ZSet	有序集合	添加、获取、删除元素 ，根据分值范围或者成员来获取元素 ，计算一个键的排名	底层使用了 Hash 表和 跳表，一方面通过hash 表保证 value 不重复，且保证hash 表中对应sore 来进行排序，在存入的时候通过 score 排序，排序的结构当元素少时使用的是ziplist ， 当元素多的时候使用调表	去重但可以排序，如获取排名前几名的用户

什么是调表？ 有什么优缺点

简单的有序单链表：单链表的特性就是每个元素存放下一个元素的引用。即：通过第一个元素可以找到第二个元素，通过第二个元素可以找到第三个元素，依次类推，直到找到最后一个元素。查找一个元素的时间复杂度是 O（n）
跳表 ：对原始链表添加 索引， 二级索引，三级索引，为了提升查询效率，跳表是可以实现二分查找的有序链表。时间复杂度 O（logn）
优点 ： 大大提升了查询的效率。
缺点： 对插入数据的效率变低， 且维护多级索引变得很难维护 。 插入的持剑复杂度 O（n）

Redis 出现的新的数据类型

• Bigmaps ： Bitmaps本身不是一种数据类型， 实际上它就是字符串（key-value） ， 但是它可以对字符串的位进行操作。 Bitmaps单独提供了一套命令， 所以在Redis中使用Bitmaps和使用字符串的方法不太相同。 可以把Bitmaps想象成一个以位为单位的数组， 数组的每个单元只能存储0和1， 数组的下标在Bitmaps中叫做偏移量。
  1. setbit： 设置某个偏移量
  2. getbit ： 获取某个偏移量的值
  3. bitcount ：统计start - end 之间 1 的个数
  4. bitop ： 对某些数据进行交并集

适用于都某个月的统计用户的活跃度分布。

• HyperLogLog ：是用来做基数统计的算法，HyperLogLog 的优点是，在输入元素的数量或者体积非常非常大时，计算基数所需的空间总是固定的、并且是很小的。
  1. pfadd ： 添加某个值对应的 元素基数，
  2. pfcount ： 统计基数的数量
  3. pfmerge ：将两种基数进行合并

使用统计一些活跃度，类似于统计一周的活跃度

• Geospatial : 地理信息的缩写。该类型，就是元素的2维坐标，在地图上就是经纬度。redis基于该类型，提供了经纬度设置，查询，范围查询，距离查询，经纬度Hash等常见操作。
  1. geoadd : 添加经纬度位置
  2. geopos ： 获取指定位置的坐标值
  3. geodist ：获取两个位置直线距离
  4. georadius ： 以给定的经纬度为中心，找出某一半径内的元素

Redis 的应用场景

• 计数器
  可以对 String 进行自增自减运算，从而实现计数器功能。Redis 这种内存型数据库的读写性能非常高，很适合存储频繁读写的计数量。

• 缓存
  将热点数据放到内存中，设置内存的最大使用量以及淘汰策略来保证缓存的命中率。

• 会话缓存
  可以使用 Redis 来统一存储多台应用服务器的会话信息。当应用服务器不再存储用户的会话信息，也就不再具有状态，一个用户可以请求任意一个应用服务器，从而更容易实现高可用性以及可伸缩性。

• 全页缓存（FPC）
  除基本的会话token之外，Redis还提供很简便的FPC平台。以Magento为例，Magento提供一个插件来使用Redis作为全页缓存后端。此外，对WordPress的用户来说，Pantheon有一个非常好的插件 wp-redis，这个插件能帮助你以最快速度加载你曾浏览过的页面。

• 查找表
  例如 DNS 记录就很适合使用 Redis 进行存储。查找表和缓存类似，也是利用了 Redis 快速的查找特性。但是查找表的内容不能失效，而缓存的内容可以失效，因为缓存不作为可靠的数据来源。

• 消息队列(发布/订阅功能)
  List 是一个双向链表，可以通过 lpush 和 rpop 写入和读取消息。不过最好使用 Kafka、RabbitMQ 等消息中间件。

• 分布式锁实现
  在分布式场景下，无法使用单机环境下的锁来对多个节点上的进程进行同步。可以使用 Redis 自带的 SETNX 命令实现分布式锁，除此之外，还可以使用官方提供的 RedLock 分布式锁实现。

• 其它
  Set 可以实现交集、并集等操作，从而实现共同好友等功能。ZSet 可以实现有序性操作，从而实现排行榜等功能。

Redis的过期键的删除策略

我们都知道，Redis是key-value数据库，我们可以设置Redis中缓存的key的过期时间。Redis的过期策略就是指当Redis中缓存的key过期了，Redis如何处理。

过期策略通常有以下三种：

• 定时过期：每个设置过期时间的key都需要创建一个定时器，到过期时间就会立即清除。该策略可以立即清除过期的数据，对内存很友好；但是会占用大量的CPU资源去处理过期的数据，从而影响缓存的响应时间和吞吐量。

• 惰性过期：只有当访问一个key时，才会判断该key是否已过期，过期则清除。该策略可以最大化地节省CPU资源，却对内存非常不友好。极端情况可能出现大量的过期key没有再次被访问，从而不会被清除，占用大量内存。

• 定期过期：每隔一定的时间，会扫描一定数量的数据库的expires字典中一定数量的key，并清除其中已过期的key。该策略是前两者的一个折中方案。通过调整定时扫描的时间间隔和每次扫描的限定耗时，可以在不同情况下使得CPU和内存资源达到最优的平衡效果。
  (expires字典会保存所有设置了过期时间的key的过期时间数据，其中，key是指向键空间中的某个键的指针，value是该键的毫秒精度的UNIX时间戳表示的过期时间。键空间是指该Redis集群中保存的所有键。)

Redis中同时使用了惰性过期和定期过期两种过期策略。

Redis 内存淘汰机制了解么？

Redis 提供 6 种数据淘汰策略：

1. volatile-lru（least recently used）：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰
2. volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰
3. volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰
4. allkeys-lru（least recently used）：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的 key（这个是最常用的）
5. allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰
6. no-eviction：禁止驱逐数据，也就是说当内存不足以容纳新写入数据时，新写入操作会报错。这个应该没人使用吧！

4.0 版本后增加以下两种：

7. volatile-lfu（least frequently used）：从已设置过期时间的数据集（server.db[i].expires）中挑选最不经常使用的数据淘汰
8. allkeys-lfu（least frequently used）：当内存不足以容纳新写入数据时，在键空间中，移除最不经常使用的 key

Redis 的事务

事务可以一次执行多个命令， 并且带有以下两个重要的保证：

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

• 事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行。

MULTI 、 EXEC 、 DISCARD 和 WATCH 是 Redis 事务相关的命令

• WATCH 命令可以为 Redis 事务提供 check-and-set （CAS）行为。被 WATCH 的键会被监视，并会发觉这些键是否被改动过了。 如果有至少一个被监视的键在 EXEC 执行之前被修改了， 那么整个事务都会被取消， EXEC 返回nil-reply来表示事务已经失败。
• MULTI命令用于开启一个事务，它总是返回OK。 MULTI执行之后，客户端可以继续向服务器发送任意多条命令，这些命令不会立即被执行，而是被放到一个队列中，当EXEC命令被调用时，所有队列中的命令才会被执行。
• EXEC：执行所有事务块内的命令。返回事务块内所有命令的返回值，按命令执行的先后顺序排列。 当操作被打断时，返回空值 nil 。
• 通过调用DISCARD，客户端可以清空事务队列，并放弃执行事务， 并且客户端会从事务状态中退出。
• UNWATCH命令可以取消watch对所有key的监控。

Redis 事务不支持回滚（roll back）

• Redis 命令只会因为错误的语法而失败（并且这些问题不能在入队时发现），或是命令用在了错误类型的键上面：这也就是说，从实用性的角度来说，失败的命令是由编程错误造成的，而这些错误应该在开发的过程中被发现，而不应该出现在生产环境中。
• 因为不需要对回滚进行支持，所以 Redis 的内部可以保持简单且快速。

为什么分区非常有用

Redis分区主要有两个目的:

• 分区可以让Redis管理更大的内存，Redis将可以使用所有机器的内存。如果没有分区，你最多只能使用一台机器的内存。
• 分区使Redis的计算能力通过简单地增加计算机得到成倍提升,Redis的网络带宽也会随着计算机和网卡的增加而成倍增长。

Redis 的线程模型

Redis基于Reactor模式开发了网络事件处理器，这个处理器被称为文件事件处理器（file event handler）。它的组成结构为4部分：多个套接字、IO多路复用程序、文件事件分派器、事件处理器。因为文件事件分派器队列的消费是单线程的，所以Redis才叫单线程模型。

• 文件事件处理器使用 I/O 多路复用（multiplexing）程序来同时监听多个套接字， 并根据套接字目前执行的任务来为套接字关联不同的事件处理器。
• 当被监听的套接字准备好执行连接应答（accept）、读取（read）、写入（write）、关闭（close）等操作时， 与操作相对应的文件事件就会产生， 这时文件事件处理器就会调用套接字之前关联好的事件处理器来处理这些事件。

虽然文件事件处理器以单线程方式运行， 但通过使用 I/O 多路复用程序来监听多个套接字， 文件事件处理器既实现了高性能的网络通信模型， 又可以很好地与 redis 服务器中其他同样以单线程方式运行的模块进行对接， 这保持了 Redis 内部单线程设计的简单性。

redis 的持久化方式有什么？有啥优缺点

Redis 提供两种持久化机制 RDB（默认） 和 AOF 机制:

• RDB：是Redis DataBase缩写快照

RDB是Redis默认的持久化方式。按照一定的时间将内存的数据以快照的形式保存到硬盘中，对应产生的数据文件为dump.rdb。通过配置文件中的save参数来定义快照的周期。

• 优点 ：

  1. 只有一个文件 dump.rdb，方便持久化。
  2. 容灾性好，一个文件可以保存到安全的磁盘。
  3. 性能最大化，fork 子进程来完成写操作，让主进程继续处理命令，所以是 IO 最大化。使用单独子进程来进行持久化，主进程不会进行任何 IO 操作，保证了 redis 的高性能
  4. 相对于数据集大时，比 AOF 的启动效率更高。

• 缺点：

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

• AOF：持久化：
  AOF持久化(即Append Only File持久化)，则是将Redis执行的每次写命令记录到单独的日志文件中，当重启Redis会重新将持久化的日志中文件恢复数据。

当两种方式同时开启时，数据恢复Redis会优先选择AOF恢复

• 优点：

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

• 缺点：

  1. AOF 文件比 RDB 文件大，且恢复速度慢。
  2. 数据集大的时候，比 rdb 启动效率低。

• 两种相比：

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

持久化应该如何选择 ？

官方推荐两个都启用。

如果对数据不敏感，可以选单独用RDB。

不建议单独用 AOF，因为可能会出现Bug。

如果只是做纯内存缓存，可以都不用。

• RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储

• AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.

• Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大

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

• 同时开启两种持久化方式

• 在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据, 因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.

• RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？

• 建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)， 快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。

• 性能建议

因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。 如果使用AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。代价,一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。

redis 中缓存击穿， 缓存穿透，缓存雪崩都是什么意思，怎么解决

• 缓存击穿 : key对应的数据存在，但在redis中过期，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮

解决方案 ：
1. 预先设置热门数据：在redis高峰访问之前，把一些热门数据提前存入到redis里面，加大这些热门数据key的时长
2. 分级缓存（缓存两份数据，第二份数据生存时间长一点作为备份，第一份数据用于被请求命中，如果第二份数据被命中说明第一份数据已经过期，要去mysql请求数据重新缓存两份数据）
3. 实时调整：现场监控哪些数据热门，实时调整key的过期时长
4. 使用锁 ： 当缓存查不到的时候 ，将访问数据库的操作，加一个互斥量，保证只有一个去访问数据库。

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

解决方案：
1. 对空值缓存 ：如果一个查询返回的数据为空（不管是数据是否不存在），我们仍然把这个空结果（null）进行缓存，设置空结果的过期时间会很短，最长不超过五分钟。
2. 采用布隆过滤器 ： 布隆过滤器可以用于检索一个元素是否在一个集合中
3. 进行实时监控：当发现Redis的命中率开始急速降低，需要排查访问对象和访问的数据，和运维人员配合，可以设置黑名单限制服务
4. 接口层增加校验，如用户鉴权校验，id做基础校验，id<=0的直接拦截；

• 缓存雪崩： key对应的数据存在，但在redis中过期，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。一般是指大量的数据同时过期导致很多请求同时访问到数据库。

解决方案：

1. 构建多级缓存架构：nginx缓存 + redis缓存 +其他缓存（ehcache等）
2. redis集群，将原来一个人干的工作，分发给多个人干
3. 将缓存失效时间分散开：比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，
4. 设置过期标志更新缓存：记录缓存数据是否过期（设置提前量），如果过期会触发通知另外的线程在后台去更新实际key的缓存。

redis 如何解决超卖问题

利用乐观锁解决超卖问题