吃透了这些Redis知识点，面试官一定觉得你很NB

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连接。

除此之外，选择单线程还有以下这些原因：

1、redis都是对内存的操作，速度极快(10W+QPS)

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

3、如果使用了多线程，则需要多线程同步，这样实现起来会变的复杂

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

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

6、还有就是单线程天然支持原子操作，而且单线程的代码写起来更简单

事务

事务大家都知道，就是把多个操作捆绑在一起，要么都执行(成功了)，要么一个也不执行(回滚了)。redis也是支持事务的，但可能和你想要的不太一样，一起来看看吧。

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

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

redis事务具有以下特点：

1、如果开始执行事务前出错，则所有命令都不执行

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

3、如果执行过程中遇到错误，会继续执行下去，不会停止的

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

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

不支持回滚的理由：

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

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

3、redis还认为，回滚并不能解决所有问题

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

管道

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

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

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

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

协议

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

发送请求的协议：

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

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

*3rn$3rnSETrn$4rnnamern$8rnlixinjiern

接受响应的协议：

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

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

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

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

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

例如，

+OKrn

-ERR Operation againstrn

:1000rn

$6rnfoobarrn

*2rn$3rnfoorn$3rnbarrn

可见redis的协议设计的非常简单。

（编辑：辽源站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!