Redis为何那么快-----底层原理浅析
Redis为什么这么快
1、完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)；
2、数据结构简单，对数据操作也简单，Redis中的数据结构是专门进行设计的；
3、采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗；
4、使用多路I/O复用模型，非阻塞IO；
5、使用底层模型不同，它们之间底层实现方式以及与客户端之间通信的应用协议不一样，Redis直接自己构建了VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求；
以上几点都比较好理解，下边我们针对多路 I/O 复用模型进行简单的探讨：
（1）多路 I/O 复用模型
多路I/O复用模型是利用 select、poll、epoll 可以同时监察多个流的 I/O 事件的能力，在空闲的时候，会把当前线程阻塞掉，当有一个或多个流有 I/O 事件时，就从阻塞态中唤醒，于是程序就会轮询一遍所有的流（epoll 是只轮询那些真正发出了事件的流），并且只依次顺序的处理就绪的流，这种做法就避免了大量的无用操作。
这里“多路”指的是多个网络连接，“复用”指的是复用同一个线程。采用多路 I/O 复用技术可以让单个线程高效的处理多个连接请求（尽量减少网络 IO 的时间消耗），且 Redis 在内存中操作数据的速度非常快，也就是说内存内的操作不会成为影响Redis性能的瓶颈，主要由以上几点造就了 Redis 具有很高的吞吐量。
Redis的快速很多人都知道是基于内存，但这只是其中的一个方面，其实Redis在底层是一套很完善的多路复用事件处理机制来保证执行的高效率。
线程模型
redis内部使用文件事件处理器 file event handler ,它包含如下几个部分。
- 多个Socket
- IO多路复用程序
- 文件事件分派器
- 事件处理器 (连接应答处理器，命令请求处理器，命令回复处理器）
之所以说redis是单线程其实是指这个文件事件处理器是单线程的，它采用多路复用的方式监听系统上多个socket，将socket上产生的事件压入队列中，由文件事件分派器从队列中取出一个socket根据事件类型发给相应的事件处理器
整个处理过程如图：
处理过程可以分为以下几个步骤：
- 客户端向redis发起一个socket请求，向redis的server socket请求连接，这里命名为socket01
- server socket产生一个AE_READABLE事件，IO多路复用程序监听到事件后将这个socket01压入队列
- 文件事件分派器从队列中取出socket01，交给连接应答处理器
- 连接应答处理器会将socket01的AE_READABLE事件与命令请求处理器相关联
- 假设客户端执行set操作，这时命令请求处理器会从socket01读取key value，在内存中完成key value的设置
- 在内存中完成设置后，会将socket01的AE_WRITEABLE事件与命令回复处理器相关联，然后压入队列中
- 事件分派器拿到socket01后，交给命令回复处理器，由命令回复处理器向socket01写入本次操作的结果，比如OK，之后解除关联
以上就是一个命令在redis中执行的过程
总结一下效率高的原因
-
内存操作
-
IO多路复用机制，减少了阻塞
-
单线程避免了线程切换的开销和竞争问题
-
最最根本的redis是用C语言写的，本来就直接跟操作系统交互，命令执行快得飞起
存内存KV操作快在哪里？
我们从上面的介绍里面我们看到了Redis是一个纯kv的操作。并且Redis绝大部分请求是纯粹的内存操作，所以速度非常快。数据存在内存中，类型与存在hashMap中，那么为什么那么快呢？我们可以一起来看一下几种常用数据结构的对比，和他们的优势。
| 数据结构 | 操作 | 时间复杂度 |
|---|---|---|
| List | insert | O(N) |
| List | select | O(1) |
| Set | insert | O(1) |
| Set | select | O(1) |
| HashMap | insert | O(1) |
| HashMap | select | O(1) |
从上图我们可以看出，HashMap的优势就是查找和操作的时间复杂度都是O（1）,所以Redis内部采用这种结构能够从根本上获得足够的优势，当让，Redis的快速不仅仅是数据结构成就的，还有单程成和异步I/O
Redis使用单线程，相比于多线程快在哪里？
从上面官网的介绍我们看到了，Redis的瓶颈不在线程，不在获取CPU的资源，所以如果使用多线程就会带来多余的资源占用。比如上下文切换、资源竞争、锁的操作。
- 上下文的切换
-
- 上下文其实不难理解，它就是CPU寄存器和程序计数器。主要的作用就是存放没有被分配到资源的线程，多线程操作的时候，不是每一个线程都能够直接获取到CPU资源的，我们之所以能够看到我们电脑上能够运行很多的程序，是应为多线程的执行和CPU不断对多线程的切换。但是总有线程获取到资源，也总有线程需要等待获取资源，这个时候，等待获取资源的线程就需要被挂起，也就是我们的寄存。这个时候我们的上下文就产生了，当我们的上下文再次被唤起，得到资源的时候，就是我们上下文的切换。
- 竞争资源
-
- 竞争资源相对来说比较好理解，CPU对上下文的切换其实就是一种资源分批，但是在切换之前，到底切换到哪一个上下文，就是资源竞争的开始。在我redis中由于是单线程的，所以所有的操作都不会涉及到资源的竞争。
- 锁的消耗
-
- 对于多线程的情况来讲，不能回避的就是锁的问题。如果说多线程操作出现并发，有可能导致数据不一致，或者操作达不到预期的效果。这个时候我们就需要锁来解决这些问题。当我们的线程很多的时候，就需要不断的加锁，释放锁，该操作就会消耗掉我们很多的时间
I/O复用，非阻塞模型
对于I/O阻塞可能有很多人不知道，I/O操作的阻塞到底是怎么引起的，Redis又是怎么解决的呢？
- I/O操作的阻塞：当用户线程发出IO请求之后，内核会去查看数据是否就绪，如果没有就绪就会等待数据就绪，而用户线程就会处于阻塞状态，用户线程交出CPU。当数据就绪之后，内核会将数据拷贝到用户线程，并返回结果给用户线程，用户线程才解除block状态。
- Redis采用多路复用：I/O 多路复用其实是在单个线程中通过记录跟踪每一个sock（I/O流） 的状态来管理多个I/O流。select, poll, epoll 都是I/O多路复用的具体的实现。epoll性能比其他几者要好。redis中的I/O多路复用的所有功能通过包装常见的select、epoll、evport和kqueue这些I/O多路复用函数库来实现的。