【面试】吃透了这些Redis知识点，面试官必定以为你很NB（干货 | 建议珍藏）

是数据结构而非类型

 

不少文章都会说，redis支持5种经常使用的数据类型，这实际上是存在很大的歧义。redis里存的都是二进制数据，其实就是字节数组（byte[]），这些字节数据是没有数据类型的，只有把它们按照合理的格式解码后，能够变成一个字符串，整数或对象，此时才具备数据类型。

这一点必需要记住。因此任何东西只要能转化成字节数组（byte[]）的，均可以存到redis里。管你是字符串、数字、对象、图片、声音、视频、仍是文件，只要变成byte数组。

所以redis里的String指的并非字符串，它其实表示的是一种最简单的数据结构，即一个key只能对应一个value。这里的key和value都是byte数组，只不过key通常是由一个字符串转换成的byte数组，value则根据实际须要而定。

在特定状况下，对value也会有一些要求，好比要进行自增或自减操做，那value对应的byte数组必需要能被解码成一个数字才行，不然会报错。

那么List这种数据结构，其实表示一个key能够对应多个value，且value之间是有前后顺序的，value值能够重复。

Set这种数据结构，表示一个key能够对应多个value，且value之间是没有前后顺序的，value值也不能够重复。

Hash这种数据结构，表示一个key能够对应多个key-value对，此时这些key-value对之间的前后顺序通常意义不大，这是一个按照名称语义来访问的数据结构，而非位置语义。

Sorted Set这种数据结构，表示一个key能够对应多个value，value之间是有大小排序的，value值不能够重复。每一个value都和一个浮点数相关联，该浮点数叫score。元素排序规则是：先按score排序，再按value排序。

相信如今你对这5种数据结构有了更清晰的认识，那它们的对应命令对你来讲就是小case了。

集群带来的问题与解决思路

若是想学习Java工程化、高性能及分布式、深刻浅出。微服务、Spring，MyBatis，Netty源码分析的朋友能够加个人Java高级交流：787707172，群里有阿里大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给你们。

集群带来的好处是显而易见的，好比容量增长、处理能力加强，还能够按须要进行动态的扩容、缩容。但同时也会引入一些新的问题，至少会有下面这两个。

一是数据分配：存数据时应该放到哪一个节点上，取数据时应该去哪一个节点上找。二是数据移动：集群扩容，新增长节点时，该节点上的数据从何处来；集群缩容，要剔除节点时，该节点上的数据往何处去。

上面这两个问题有一个共同点就是，如何去描述和存储数据与节点的映射关系。又由于数据的位置是由key决定的，因此问题就演变为如何创建起各个key和集群全部节点的关联关系。

集群的节点是相对固定和少数的，虽然有增长节点和剔除节点。但集群里存储的key，则是彻底随机、没有规律、不可预测、数量庞多，还很是琐碎。

这就比如一所大学和它的全部学生之间的关系。若是大学和学生直接挂钩的话，必定会比较混乱。现实是它们之间又加入了好几层，首先有院系，其次有专业，再者有年级，最后还有班级。通过这四层映射以后，关系就清爽不少了。

这实际上是一个很是重要的结论，这个世界上没有什么问题是不能经过加入一层来解决的。若是有，那就再加入一层。计算机里也是这样的。

redis在数据和节点之间又加入了一层，把这层称为槽（slot），因该槽主要和哈希有关，又叫哈希槽。

最后变成了，节点上放的是槽，槽里放的是数据。槽解决的是粒度问题，至关于把粒度变大了，这样便于数据移动。哈希解决的是映射问题，使用key的哈希值来计算所在的槽，便于数据分配。

能够这样来理解，你的学习桌子上堆满了书，乱的很，想找到某本书很是困难。因而你买了几个大的收纳箱，把这些书按照书名的长度放入不一样的收纳箱，而后把这些收纳箱放到桌子上。

这样就变成了，桌子上是收纳箱，收纳箱里是书籍。这样书籍移动很方便，搬起一个箱子就走了。寻找书籍也很方便，只要数一数书名的长度，去对应的箱子里找就好了。

其实咱们也没作什么，只是买了几个箱子，按照某种规则把书装入箱子。就这么简单的举动，就完全改变了原来人心涣散的情况。是否是有点小小的神奇呢。

一个集群只能有16384个槽，编号0-16383。这些槽会分配给集群中的全部主节点，分配策略没有要求。能够指定哪些编号的槽分配给哪一个主节点。集群会记录节点和槽的对应关系。

接下来就须要对key求哈希值，而后对16384取余，余数是几key就落入对应的槽里。slot = CRC16(key) % 16384。

以槽为单位移动数据，由于槽的数目是固定的，处理起来比较容易，这样数据移动问题就解决了。

使用哈希函数计算出key的哈希值，这样就能够算出它对应的槽，而后利用集群存储的槽和节点的映射关系查询出槽所在的节点，因而数据和节点就映射起来了，这样数据分配问题就解决了。

我想说的是，通常的人只会去学习各类技术，高手更在意如何跳出技术，寻求一种解决方案或思路方向，顺着这个方向走下去，八九不离十能找到你想要的答案。

集群对命令操做的取舍

 

客户端只要和集群中的一个节点创建连接后，就能够获取到整个集群的全部节点信息。此外还会获取全部哈希槽和节点的对应关系信息，这些信息数据都会在客户端缓存起来，由于这些信息至关有用。

客户端能够向任何节点发送请求，那么拿到一个key后到底该向哪一个节点发请求呢？其实就是把集群里的那套key和节点的映射关系理论搬到客户端来就好了。

因此客户端须要实现一个和集群端同样的哈希函数，先计算出key的哈希值，而后再对16384取余，这样就找到了该key对应的哈希槽，利用客户端缓存的槽和节点的对应关系信息，就能够找到该key对应的节点了。

接下来发送请求就能够了。还能够把key和节点的映射关系缓存起来，下次再请求该key时，直接就拿到了它对应的节点，不用再计算一遍了。

理论和现实老是有差距的，集群已经发生了变化，客户端的缓存还没来得及更新。确定会出现拿到一个key向对应的节点发请求，其实这个key已经不在那个节点上了。此时这个节点应该怎么办？

这个节点能够去key实际所在的节点上拿到数据再返回给客户端，也能够直接告诉客户端key已经不在我这里了，同时附上key如今所在的节点信息，让客户端再去请求一次，相似于HTTP的302重定向。

这实际上是个选择问题，也是个哲学问题。结果就是redis集群选择了后者。所以，节点只处理本身拥有的key，对于不拥有的key将返回重定向错误，即-MOVED key 127.0.0.1:6381，客户端从新向这个新节点发送请求。

因此说选择是一种哲学，也是个智慧。稍后再谈这个问题。先来看看另外一个状况，和这个问题有些相同点。

redis有一种命令能够一次带多个key，如MGET，我把这些称为多key命令。这个多key命令的请求被发送到一个节点上，这里有一个潜在的问题，不知道你们有没有想到，就是这个命令里的多个key必定都位于那同一个节点上吗？

就分为两种状况了，若是多个key不在同一个节点上，此时节点只能返回重定向错误了，可是多个key彻底可能位于多个不一样的节点上，此时返回的重定向错误就会很是乱，因此redis集群选择不支持此种状况。

若是多个key位于同一个节点上呢，理论上是没有问题的，redis集群是否支持就和redis的版本有关系了，具体使用时本身测试一下就好了。

在这个过程当中咱们发现了一件很有意义的事情，就是让一组相关的key映射到同一个节点上是很是有必要的，这样能够提升效率，经过多key命令一次获取多个值。

那么问题来了，如何给这些key起名字才能让他们落到同一个节点上，难不成都要先计算个哈希值，再取个余数，太麻烦了吧。固然不是这样了，redis已经帮咱们想好了。

能够来简单推理下，要想让两个key位于同一个节点上，它们的哈希值必需要同样。要想哈希值同样，传入哈希函数的字符串必须同样。那咱们只能传进去两个如出一辙的字符串了，那不就变成同一个key了，后面的会覆盖前面的数据。

这里的问题是咱们都是拿整个key去计算哈希值，这就致使key和参与计算哈希值的字符串耦合了，须要将它们解耦才行，就是key和参与计算哈希值的字符串有关可是又不同。

redis基于这个原理为咱们提供了方案，叫作key哈希标签。先看例子，{user1000}.following，{user1000}.followers，相信你已经看出了门道，就是仅使用Key中的位于{和}间的字符串参与计算哈希值。

这样能够保证哈希值相同，落到相同的节点上。可是key又是不一样的，不会互相覆盖。使用哈希标签把一组相关的key关联了起来，问题就这样被轻松愉快地解决了。

相信你已经发现了，要解决问题靠的是巧妙的奇思妙想，而不是非要用牛逼的技术牛逼的算法。这就是小强，小而强大。

最后再来谈选择的哲学。redis的核心就是以最快的速度进行经常使用数据结构的key/value存取，以及围绕这些数据结构的运算。对于与核心无关的或会拖累核心的都选择弱化处理或不处理，这样作是为了保证核心的简单、快速和稳定。

其实就是在广度和深度面前，redis选择了深度。因此节点不去处理本身不拥有的key，集群不去支持多key命令。这样一方面能够快速地响应客户端，另外一方面能够避免在集群内部有大量的数据传输与合并。

单线程模型

 

redis集群的每一个节点里只有一个线程负责接受和执行全部客户端发送的请求。技术上使用多路复用I/O，使用Linux的epoll函数，这样一个线程就能够管理不少socket链接。

除此以外，选择单线程还有如下这些缘由：

一、redis都是对内存的操做，速度极快（10W+QPS）

二、总体的时间主要都是消耗在了网络的传输上

三、若是使用了多线程，则须要多线程同步，这样实现起来会变的复杂

四、线程的加锁时间甚至都超过了对内存操做的时间

五、多线程上下文频繁的切换须要消耗更多的CPU时间

六、还有就是单线程自然支持原子操做，并且单线程的代码写起来更简单

事务

若是想学习Java工程化、高性能及分布式、深刻浅出。微服务、Spring，MyBatis，Netty源码分析的朋友能够加个人Java高级交流：787707172，群里有阿里大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给你们。

事务你们都知道，就是把多个操做捆绑在一块儿，要么都执行（成功了），要么一个也不执行（回滚了）。redis也是支持事务的，但可能和你想要的不太同样，一块儿来看看吧。

redis的事务能够分为两步，定义事务和执行事务。使用multi命令开启一个事务，而后把要执行的全部命令都依次排上去。这就定义好了一个事务。此时使用exec命令来执行这个事务，或使用discard命令来放弃这个事务。

你可能但愿在你的事务开始前，你关心的key不想被别人操做，那么可使用watch命令来监视这些key，若是开始执行前这些key被其它命令操做了则会取消事务的。也可使用unwatch命令来取消对这些key的监视。

redis事务具备如下特色：

一、若是开始执行事务前出错，则全部命令都不执行

二、一旦开始，则保证全部命令一次性按顺序执行完而不被打断

三、若是执行过程当中遇到错误，会继续执行下去，不会中止的

四、对于执行过程当中遇到错误，是不会进行回滚的

看完这些，真想问一句话，你这能叫事务吗？很显然，这并非咱们一般认为的事务，由于它连原子性都保证不了。保证不了原子性是由于redis不支持回滚，不过它也给出了不支持的理由。

不支持回滚的理由：

一、redis认为，失败都是由命令使用不当形成

二、redis这样作，是为了保持内部实现简单快速

三、redis还认为，回滚并不能解决全部问题

哈哈，这就是霸王条款，所以，好像使用redis事务的不太多

管道

 

客户端和集群的交互过程是串行化阻塞式的，即客户端发送了一个命令后必须等到响应回来后才能发第二个命令，这一来一回就是一个往返时间。若是你有不少的命令，都这样一个一个的来进行，会变得很慢。

redis提供了一种管道技术，可让客户端一次发送多个命令，期间不须要等待服务器端的响应，等全部的命令都发完了，再依次接收这些命令的所有响应。这就极大地节省了许多时间，提高了效率。

聪明的你是否是意识到了另一个问题，多个命令就是多个key啊，这不就是上面提到的多key操做嘛，那么问题来了，你如何保证这多个key都是同一个节点上的啊，哈哈，redis集群又放弃了对管道的支持。

不过能够在客户端模拟实现，就是使用多个链接往多个节点同时发送命令，而后等待全部的节点都返回了响应，再把它们按照发送命令的顺序整理好，返回给用户代码。哎呀，好麻烦呀。

协议

 

简单了解下redis的协议，知道redis的数据传输格式。

发送请求的协议：

*参数个数CRLF$参数1的字节数CRLF参数1的数据CRLF...$参数N的字节数CRLF参数N的数据CRLF

例如，SET name lixinjie，实际发送的数据是：

*3\r\n$3\r\nSET\r\n$4\r\nname\r\n$8\r\nlixinjie\r\n

接受响应的协议：

单行回复，第一个字节是+

错误消息，第一个字节是-

整型数字，第一个字节是:

批量回复，第一个字节是$

多个批量回复，第一个字节是*

例如，

+OK\r\n

-ERR Operation against\r\n

:1000\r\n

$6\r\nfoobar\r\n

*2\r\n$3\r\nfoo\r\n$3\r\nbar\r\n

可见redis的协议设计的很是简单。

若是想学习Java工程化、高性能及分布式、深刻浅出。微服务、Spring，MyBatis，Netty源码分析的朋友能够加个人Java高级交流：787707172，群里有阿里大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给你们。