Redis追命连环问，你能回答到第几问？（上）

Redis常见面试题连环问，你能回答到第几问？（上）

Redis常见面试题连环问，你能回答到第几问？（中）

Redis常见面试题连环问，你能回答到第几问？（下）

Redis是后端工程师必备的一项技能，下面分享一位求职者在面试过程中遇到的问题。

面试官说：“我们开始吧。看了你的简历，觉得你对redis应该掌握的不错，我们今天就来讨论下redis…”。我想：“来就来，兵来将挡水来土掩”。

一、Redis是什么

面试官：你先来说下redis是什么吧

我：（这不就是总结下redis的定义和特点嘛）Redis是C语言开发的一个开源的（遵从BSD协议）高性能键值对（key-value）的内存数据库，可以用作数据库、缓存、消息中间件等。它是一种NoSQL（not-only sql，泛指非关系型数据库）的数据库。

我顿了一下，接着说：Redis作为一个内存数据库。

1. 性能优秀，数据在内存中，读写速度非常快，支持并发10W QPS；

2. 单进程单线程，是线程安全的，采用IO多路复用机制；

3. 丰富的数据类型，支持字符串（strings）、散列（hashes）、列表（lists）、集合（sets）、有序集合（sorted sets）等；

4. 支持数据持久化。可以将内存中数据保存在磁盘中，重启时加载；

5. 主从复制，哨兵，高可用；

6. 可以用作分布式锁；

7. 可以作为消息中间件使用，支持发布订阅

注：答主回答的还是不错的，我们看一下官方简介

Redis是一个基于BSD开源的项目，是一个把结构化的数据放在内存中的一个存储系统，你可以把它作为数据库，缓存和消息中间件来使用。同时支持strings，lists，hashes，sets，sorted sets，bitmaps，hyperloglogs和geospatial indexes等数据类型。

它还内建了复制，lua脚本，LRU（Least Recently Used，最近最少使用），事务等功能，通过redis sentinel（即哨兵）实现高可用，通过redis cluster实现了自动分片。以及事务，发布/订阅，自动故障转移等等。

面试官：总结的不错，看来是早有准备啊。刚来听你提到redis支持五种数据类型，那你能简单说下这五种数据类型吗？

二、五种数据类型

我：当然可以，但是在说之前，我觉得有必要先来了解下Redis内部内存管理是如何描述这5种数据类型的。说着，我拿着笔给面试官画了一张图：

我：首先redis内部使用一个redisObject对象来表示所有的key和value，redisObject最主要的信息如上图所示：
type表示一个value对象具体是何种数据类型，
encoding是不同数据类型在redis内部的存储方式。比如：type=string表示value存储的是一个普通字符串，那么encoding可以是raw或者int。

我顿了一下，接着说：下面我简单说下5种数据类型：

1. string是redis最基本的类型，可以理解成与memcached一模一样的类型，一个key对应一个value。value不仅是string，也可以是数字。string类型是二进制安全的，意思是redis的string类型可以包含任何数据，比如jpg图片或者序列化的对象。string类型的值最大能存储512M。

2. Hash是一个键值（key-value）的集合。redis的hash是一个string的key和value的映射表，Hash特别适合存储对象。常用命令：hget,hset,hgetall等。

3. list列表是简单的字符串列表，按照插入顺序排序。可以添加一个元素到列表的头部（左边）或者尾部（右边） 常用命令：lpush、rpush、lpop、rpop、lrange(获取列表片段)等。
   应用场景：list应用场景非常多，也是Redis最重要的数据结构之一，比如twitter的关注列表，粉丝列表都可以用list结构来实现。
   数据结构：list就是链表，可以用来当消息队列。redis提供了List的push和pop操作，还提供了操作某一段的api，可以直接查询或者删除某一段的元素。
   实现方式：redis list的是实现是一个双向链表，支持反向查找和遍历，更方便操作，不过带来了额外的内存开销。

4. set是string类型的无序集合。集合是通过hashtable实现的。set中的元素是没有顺序的，而且是没有重复的。
   常用命令：sdd、spop、smembers、sunion等。
   应用场景：redis set对外提供的功能和list一样是一个列表，特殊之处在于set是自动去重的，而且set提供了判断某个成员是否在一个set集合中。

5. zset和set一样是string类型元素的集合，且不允许重复的元素。常用命令：zadd、zrange、zrem、zcard等。
   使用场景：sorted set可以通过用户额外提供一个优先级（score）的参数来为成员排序，并且是插入有序的，即自动排序。当你需要一个有序的并且不重复的集合列表，那么可以选择sorted set结构。和set相比，sorted set关联了一个double类型权重的参数score，使得集合中的元素能够按照score进行有序排列，redis正是通过分数来为集合中的成员进行从小到大的排序。
   实现方式：Redis sorted set的内部使用HashMap和跳跃表(skipList)来保证数据的存储和有序，HashMap里放的是成员到score的映射，而跳跃表里存放的是所有的成员，排序依据是HashMap里存的score，使用跳跃表的结构可以获得比较高的查找效率，并且在实现上比较简单。

数据类型应用场景总结

面试官：那Redis缓存你一定用过的吧，用的过程中遇到过什么问题吗？雪崩了解吗？

我：缓存和数据库数据一致性问题：分布式环境下非常容易出现缓存和数据库间数据一致性问题，针对这一点，如果项目对缓存的要求是强一致性的，那么就不要使用缓存。我们只能采取合适的策略来降低缓存和数据库间数据不一致的概率，而无法保证两者间的强一致性。合适的策略包括合适的缓存更新策略，更新数据库后及时更新缓存、缓存失败时增加重试机制。

缓存雪崩

缓存雪崩是指在我们设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB，DB瞬时压力过重雪崩。

举个栗子：
如果某电商网站首页所有Key的失效时间都是12小时，中午12点刷新的，我零点有个大促活动大量用户涌入，假设每秒6000个请求，本来缓存可以抗住每秒5000个请求，但是缓存中所有Key都失效了。此时6000个/秒的请求全部落在了数据库上，数据库必然扛不住，真实情况可能DBA都没反应过来直接挂了，此时，如果没什么特别的方案来处理，DBA很着急，重启数据库，但是数据库立马又被新流量给打死了。这就是我理解的缓存雪崩。

我心想：同一时间大面积失效，瞬间Redis跟没有一样，那这个数量级别的请求直接打到数据库几乎是灾难性的，你想想如果挂的是一个用户服务的库，那其他依赖他的库所有接口几乎都会报错，如果没做熔断等策略基本上就是瞬间挂一片的节奏，你怎么重启用户都会把你打挂，等你重启好的时候，用户早睡觉去了。

解决方案

缓存失效时的雪崩效应对底层系统的冲击非常可怕。有一个简单方案就是将缓存失效时间分散开，比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

如果Redis是集群部署，将热点数据均匀分布在不同的Redis库中也能避免全部失效。
或者设置热点数据永不过期，有更新操作就更新缓存就好了（比如更新了首页商品，那你刷下缓存就好了，不要设置过期时间），电商首页的数据也可以用这个操作，保险。

面试官：那你了解缓存穿透和击穿么，可以说说他们跟雪崩的区别吗？

缓存穿透 与 缓存击穿

我：缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。而用户（黑客）不断发起请求，这就是漏洞。

举个栗子：我们数据库的id都是从1自增的，如果发起id=-1的数据或者id特别大不存在的数据，这样的不断攻击导致数据库压力很大，严重会击垮数据库。

我又接着说：至于缓存击穿嘛，这个跟缓存雪崩有点像，但是又有一点不一样，缓存雪崩是因为大面积的缓存失效，打崩了DB，而缓存击穿不同的是缓存击穿是指一个Key非常热点，在不停地扛着大量的请求，大并发集中对这一个点进行访问，当这个Key在失效的瞬间，持续的大并发直接落到了数据库上，就在这个Key的点上击穿了缓存。并发的请求可能会瞬间把后端DB压垮。

面试官露出欣慰的眼光：那他们分别怎么解决？

缓存穿透我会在接口层增加校验，比如用户鉴权，参数做校验，不合法的校验直接return，比如id做基础校验，id<=0直接拦截。
从缓存取不到的数据，在数据库中也没有取到，这时也可以将key-value对写为key-null，缓存有效时间可以设置短点，如30秒（设置太长会导致正常情况也没法使用）。这样可以防止攻击用户反复用同一个id暴力攻击。

Redis里还有一个高级用法**布隆过滤器（Bloom Filter）**这个也能很好的预防缓存穿透的发生，他的原理也很简单，就是利用高效的数据结构和算法快速判断出你这个Key是否在数据库中存在，不存在你return就好了，存在你就去查DB刷新KV再return。但布隆过滤器有一定的误判性。

缓存击穿的话，主要有三种解决方法：

1. 使用互斥锁(mutex key):这种解决方案思路比较简单，就是只让一个线程构建缓存，其他线程等待构建缓存的线程执行完，重新从缓存获取数据就可以了。

2. "提前"使用互斥锁(mutex key)：在value内部设置1个超时值(timeout1), timeout1比实际的缓存失效时间timeout(timeout2)小。当从cache读取到timeout1发现它已经过期时候，马上获取新的数据到cache并延长timeout1并重新设置到cache。

3. “永远不过期”：然后通过定时job去刷新缓存。 

加锁伪代码如下：

public function getData($key)
{
	$data = redis->get($key);
    if (!is_null($data)) {
        //缓存未过期
        if ($data['expire'] > time()){
            return $data['data'];
        }
        //加锁失败说明已经有请求执行加锁，返回之前的缓存数据
        if (!Redis::setnx($lockKey,1)) {
            return $data['data'];
        }
    }
    usleep(100);
    $data_new = $this->searchDB($key);
    $data = [
        'data' => $data_new,
        'expire' => time() + $expire
    ];
    $r = redis->set($key, $data, $expire);
    //解锁
    redis->del($lockKey);
    return $data['data'];
}

今天就分享到这里，预知后事如何且听下回分解。

更多精彩欢迎关注公众号。