面试你需要知道的Redis

概述

Redis是C语言开发的一个开源的高性能键值对（Key-Value）的内存数据库，可以用作数据库、缓存、消息中间件。它是一种NoSQL（not-only-sql）泛指非关系型数据库，支持10W QPS，单进程单线程，线程安全，采用I/O多路复用机制。

Redis优势

• Redis完全基于内存，绝大部分请求是纯粹的内存操作，非常迅速，数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度是O(1)。
• 数据结构简单，对数据操作也简单。
• 用单线程，避免了不必要的上下文切换和竞争条件，不存在多线程导致的CPU切换，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有死锁问题导致的性能消耗。
• 使用多路复用IO模型，非阻塞IO。

常用操作

String

redis 127.0.0.1:6379> SET runoob "菜鸟教程"
OK
redis 127.0.0.1:6379> GET runoob
"菜鸟教程"

Hash

redis 127.0.0.1:6379> DEL runoob
redis 127.0.0.1:6379> HMSET runoob field1 "Hello" field2 "World"
"OK"
redis 127.0.0.1:6379> HGET runoob field1
"Hello"
redis 127.0.0.1:6379> HGET runoob field2
"World"

List

redis 127.0.0.1:6379> DEL runoob
redis 127.0.0.1:6379> lpush runoob redis
(integer) 1
redis 127.0.0.1:6379> lpush runoob mongodb
(integer) 2
redis 127.0.0.1:6379> lpush runoob rabitmq
(integer) 3
redis 127.0.0.1:6379> lrange runoob 0 10
1) "rabitmq"
2) "mongodb"
3) "redis"
redis 127.0.0.1:6379>

Set（集合）

redis 127.0.0.1:6379> DEL runoob
redis 127.0.0.1:6379> sadd runoob redis
(integer) 1
redis 127.0.0.1:6379> sadd runoob mongodb
(integer) 1
redis 127.0.0.1:6379> sadd runoob rabitmq
(integer) 1
redis 127.0.0.1:6379> sadd runoob rabitmq
(integer) 0
redis 127.0.0.1:6379> smembers runoob

1) "redis"
2) "rabitmq"
3) "mongodb"

zset(sorted set：有序集合)

redis 127.0.0.1:6379> DEL runoob
redis 127.0.0.1:6379> zadd runoob 0 redis
(integer) 1
redis 127.0.0.1:6379> zadd runoob 0 mongodb
(integer) 1
redis 127.0.0.1:6379> zadd runoob 0 rabitmq
(integer) 1
redis 127.0.0.1:6379> zadd runoob 0 rabitmq
(integer) 0
redis 127.0.0.1:6379> > ZRANGEBYSCORE runoob 0 1000
1) "mongodb"
2) "rabitmq"
3) "redis"

五种数据类型

Redis使用一个redisObject对象表示所有的key和value

• String
• Hash
• List
• Set
• Zset

Redis是单线程的，但Redis为什么这么快？

1、完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)；
2、数据结构简单，对数据操作也简单，Redis中的数据结构是专门进行设计的；
3、采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗；
4、使用多路I/O复用模型，非阻塞IO；这里“多路”指的是多个网络连接，“复用”指的是复用同一个线程
5、使用底层模型不同，它们之间底层实现方式以及与客户端之间通信的应用协议不一样，Redis直接自己构建了VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求；

为什么Redis是单线程的？

Redis是基于内存的操作，CPU不是Redis的瓶颈，Redis的瓶颈最有可能是机器内存的大小或者网络带宽。既然单线程容易实现，而且CPU不会成为瓶颈，那就顺理成章地采用单线程的方案了（毕竟采用多线程会有很多麻烦！）。

缓存雪崩

如果缓存数据设置的过期时间是相同的，并且Redis恰好将这部分数据全部删光了。这就会导致在这段时间内，这些缓存同时失效，全部请求到数据库中。**这就是缓存雪崩：**Redis挂掉了，请求全部走数据库。对缓存数据设置相同的过期时间，导致某段时间内缓存失效，请求全部走数据库。缓存雪崩如果发生了，很可能就把我们的数据库搞垮，导致整个服务瘫痪！

如何解决缓存雪崩

1、在缓存的时候给过期时间加上一个随机值，这样就会大幅度的减少缓存在同一时间过期。

2、对于“Redis挂掉了，请求全部走数据库”这种情况，我们可以有以下的思路：
事发前：实现Redis的高可用(主从架构+Sentinel（哨兵） 或者Redis Cluster（集群）)，尽量避免Redis挂掉这种情况发生。
事发中：万一Redis真的挂了，我们可以设置本地缓存(ehcache)+限流(hystrix)，尽量避免我们的数据库被干掉(起码能保证我们的服务还是能正常工作的)
事发后：redis持久化，重启后自动从磁盘上加载数据，快速恢复缓存数据。

缓存穿透

比如，我们有一张数据库表，ID都是从1开始的(正数)：但是可能有黑客想把我的数据库搞垮，每次请求的ID都是负数。这会导致我的缓存就没用了，请求全部都找数据库去了，但数据库也没有这个值啊，所以每次都返回空出去。

缓存穿透是指查询一个一定不存在的数据。由于缓存不命中，并且出于容错考虑，如果从数据库查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，失去了缓存的意义。

这就是缓存穿透：请求的数据在缓存大量不命中，导致请求走数据库。缓存穿透如果发生了，也可能把我们的数据库搞垮，导致整个服务瘫痪！

如何解决缓存穿透

1、由于请求的参数是不合法的(每次都请求不存在的参数)，于是我们可以使用布隆过滤器(BloomFilter)或者压缩filter提前拦截，不合法就不让这个请求到数据库层！
2、当我们从数据库找不到的时候，我们也将这个空对象设置到缓存里边去。下次再请求的时候，就可以从缓存里边获取了。这种情况我们一般会将空对象设置一个较短的过期时间。

缓存与数据库双写一致

读操作流程

如果我们的数据在缓存里边有，那么就直接取缓存的。
如果缓存里没有我们想要的数据，我们会先去查询数据库，然后将数据库查出来的数据写到缓存中。
最后将数据返回给请求

什么是缓存与数据库双写一致问题？

从理论上说，只要我们设置了键的过期时间，我们就能保证缓存和数据库的数据最终是一致的。因为只要缓存数据过期了，就会被删除。随后读的时候，因为缓存里没有，就可以查数据库的数据，然后将数据库查出来的数据写入到缓存中。

除了设置过期时间，我们还需要做更多的措施来尽量避免数据库与缓存处于不一致的情况发生。

对于更新操作

一般来说，执行更新操作时，我们会有两种选择：
先操作数据库，再操作缓存
先操作缓存，再操作数据库

首先，要明确的是，无论我们选择哪个，我们都希望这两个操作要么同时成功，要么同时失败。所以，这会演变成一个分布式事务的问题。

所以，如果原子性被破坏了，可能会有以下的情况：

操作数据库成功了，操作缓存失败了。
操作缓存成功了，操作数据库失败了。

如果第一步已经失败了，我们直接返回Exception出去就好了，第二步根本不会执行。

操作缓存有两种方案：

• 更新缓存
• 删除缓存

一般我们都是采取删除缓存策略的，原因如下：

1、 高并发环境下，无论是先操作数据库还是后操作数据库而言，如果加上更新缓存，那就更加容易导致数据库与缓存数据不一致问题。(删除缓存直接和简单很多)
2、如果每次更新了数据库，都要更新缓存【这里指的是频繁更新的场景，这会耗费一定的性能】，倒不如直接删除掉。等再次读取时，缓存里没有，那我到数据库找，在数据库找到再写到缓存里边(体现懒加载)

基于这两点，对于缓存在更新时而言，都是建议执行删除操作！

先操作数据库，再删缓存

正常的情况是这样的：

先操作数据库，成功；
再删除缓存，也成功；

如果原子性被破坏了：

第一步成功(操作数据库)，第二步失败(删除缓存)，会导致数据库里是新数据，而缓存里是旧数据。
如果第一步(操作数据库)就失败了，我们可以直接返回错误(Exception)，不会出现数据不一致。

如果在高并发的场景下，出现数据库与缓存数据不一致的概率特别低，也不是没有：

1、缓存刚好失效
2、线程A查询数据库，得一个旧值
3、线程B将新值写入数据库
4、线程B删除缓存
5、线程A将查到的旧值写入缓存
要达成上述情况，还是说一句概率特别低：

先删缓存，再操作数据库

正常情况是这样的：

先删除缓存，成功；
再更新数据库，也成功

如果原子性被破坏了：

第一步成功(删除缓存)，第二步失败(更新数据库)，数据库和缓存的数据还是一致的。
如果第一步(删除缓存)就失败了，我们可以直接返回错误(Exception)，数据库和缓存的数据还是一致的。

看起来是很美好，但是我们在并发场景下分析一下，就知道还是有问题的了：

线程A删除了缓存
线程B查询，发现缓存已不存在
线程B去数据库查询得到旧值
线程B将旧值写入缓存
线程A将新值写入数据库

因此，我们得出结论如下：

• 先删除缓存，再更新数据库
• 在高并发下表现不如意，在原子性被破坏时表现优异
• 先更新数据库，再删除缓存(Cache Aside Pattern设计模式)
• 在高并发下表现优异，在原子性被破坏时表现不如意