Redis 为什么快?单线程IO多路复用都是什么?

今天这个视频来讲一下Redis为什么这么快。首先这个地方有一个requestpersecond，这个是我从Redis官网最新拿到的Benchmark，大家可以来参考一下Redis的性能是多么的炸裂。Redis为什么这么快？我个人从网上搜罗了一圈，大概总结为以下四点。

·第一点就是它存储使用的内存。

·第二点就是它内部是单线程。

·第三点它使用了10多路复用。

·第四点就是它底层有一些非常不错的数据结构。

·首先来看存储这一块，来了一张图，首先是harddrive RAM，这个也是存储介质的进化的过程。之前存到硬盘上面，现在都会向内存来移动，所以在使用内存以后，第一个肯定是速度更快了，另外一个就是它相较于硬盘来讲有更高的吞吐和低延迟。

·第三点就是它在代码实现上面是更加的简单一些，因为不需要再去打开一个流，然后就是各种操作，最后还要想着去关闭资源，关闭流。在使用内存的时候只需要去考虑的一点就是系统将来需要多大的内存去支撑，也就是要预估一下内存的大小，不要等到去写的时候内存不够了就有点尴尬。

·讲完了内存以后来讲一下线程这一块，Redis它是单线程，为什么Redis当初的作者不去使用现在多核CPU的多线程的性能优势？这个来分析一下。

→首先来传统意义上面讲一下单线程和多线程大概是什么？我这里举了一个例子，比如代码里面需要去处理一些数据，然后去操作一些文件。单线程的方式是什么样的？首先它是要做任务一，然后做任务二，然后任务三，任务四，也就是说每一个任务都需要去等待前一个任务执行完毕了以后才可以去走它自己的逻辑。

→在多线程的时候，这个地方比如线程池初始化了三个线程，线程是可以去复用的。因为可以看到任务2和任务4都在线程2里面完成了，这个时候在相同的时间线里面去执行的代码逻辑或者处理的任务就会更多，因为它们是并行去做的。

这个就是多核CPU多线程的优势，它也会存在一些其他的问题，就是由多线程导致的一些问题，比如第一个线程上下文的切换，另外一点就是为了达到资源的互斥，因为很有可能多个线程去操作的是同一个资源，比如a线程在读，b线程在写，这个时候肯定是要保证原子性、数据一致性，肯定是必须要去加锁。

当加锁了以后，这又是一笔非常不小的额外性能的开销。基于上面这两点已经脑袋变大了，包括自己再去写多线程的时候也是很谨慎的。所以在使用多线程的时候，它的相应的复杂度以及代码的维护或者后面测试的复杂度也会相应的提升。

所以最终是选择使用了单线程的线程模型。作为Redis本身来讲，它是内存的非关系型数据库，它的性能瓶颈其实不在CPU，最核心的瓶颈是在内存，就是内存分配的大小，包括key的存活以及key的失效，这个是它的瓶颈。还有就是读写的时候网络的带宽以及传输过程当中的I0的效率。

讲完了这两点以后，接下来看一下IO的模型。直接说结果，Redis实际上使用的是10多路复用的模型。其实IO的模型是有五六种，今天就简单讲一下这三种。

·第一个是阻塞I0模型。

·第二个是非阻塞I0模型。

·第三个是I0多了复用。

阻塞I0模型怎么理解？就是阻塞了，还怎么理解？就是我向socket的，或者服务端去请求一些数据的时候，问他有没有准备好，能不能给我，这个时候需要阻塞在这，不给就不能去干别的事。

非阻塞性io不阻塞了，怎么实现的不阻塞？其实是有一个线程是不断的去轮询，如果还没有给我，可以去干点别的事情，一旦轮询的时候得到了结果，就跳出结束轮询。

·最后再来看一下io多路复用，io多路复用可能讲起来点挺多的，而且挺复杂，比如selectpoll或者epoll之类的这种东西。

简单举一个生活当中的例子，比如昨天去电影院看电影，就发现了中控那个地方有一个大屏，就是会显示123456789个放映厅，电影还有多长时间结束。一旦某个放映厅电影结束了以后，中控大屏会收到一个通知，拿到了通知以后就会去拿起对讲机告诉对应的服务员，可以去清场了，可以去打扫卫生了，相应的工作人员会在后面去换下一场电影的碟片。

也就是基于io多路复用可以实现Redis单线程，可以去处理多个io的请求。这个其实是组成了Redis内部的threadedio，也就是线程模型和io模型大概是这个样子。

接下来讲一下Redis底层的一些优秀的数据结构。

·首先来看一下绿色的这一部分，它是在客户端经常使用到的那些比较上层的数据结构，比如string、list、hash、sorted、set，还有set。

·再来看一下高阶的数据结构对应底层c语言实现的这些数据结构分别是怎么样的关系。string其实就是一个简单动态字符串，list、是双向链表和压缩列表，hash也用到了压缩列表，里面还有一个hash表，sorted set里面是一个跳表，主要核心是一个跳表，set是一个整数数组。基于跳表在网上也找到了这样的示例图，我觉得人家讲的挺好的。

比如这个地方需要去找到12的元素，在跳表里面是存了多级索引的，并且是有序的。大家可以看到第一级的索引比如找到了7，发现最大的7还是不满足，就往下找，找到了10还是不行，再往下找就找到了12。比起传统的链表从头开始找，再找到12，其实它的性能是有了很大的提升。

虽然它增加了索引会多出来一些存储的空间，但是它通过空间来换时间，所以就能够相应的去减少搜索的次数，提升查询的性能。

最后在讲到Redis的时候不得不去和之前用过的Memcached来进行对比，其实这里非常言简意赅的列出了它们两个的区别。首先Redis是计算向数据移动，Memcached是数据向计算移动。

举一个非常简单的例子，比如现在需要去拿到某一个用户得了多少分，在设计数据结构的时候肯定是用hash，就是大的key叫scores或者叫user_scores，里面存的是用户的ID对应它的统计的分数，当然是缓存的分数。

如果用Memcached在客户端想要去检索某个ID的分数应该怎么做？首先是通过大key把东西全部拿到代码里面来，然后反序列化一样通过ID去拿到对应的分数，这个其实就是数据向计算移动，显然是不太能够应对现阶段的。这些复杂的业务逻辑和场景。

如果同样的事情用Redis来做应该怎么做？首先Redis本身就有一个结构，数据结构叫做hash，比如用hget，然后大k加小k就能够拿到了对应的分数，所以这个就是计算向数据移动了。

所以这个就解释了它们两个根本的区别，也就是现在为什么更多的公司选择去使用Redis而放弃Memcached。

如果大家对于Redis为什么这么快这个话题比较感兴趣，大家也可以在弹幕或者是留言来沟通来补充一下。

以上就是本期视频的全部内容了，如果你觉得这个视频做的还不错，请帮忙点赞、投币、分享，一键三连支持我一下，没有关注的同学也可以点个关注，下个视频再见，peace。