主要有以下几项原因
Redis为什么可以这么快 - 图1

1、基于内存实现

Mysql的数据存储持久化是存储到磁盘上的，读取数据是内存中如果没有的话，就会产生磁盘I/O，先把数据读取到内存中，再读取数据。而Redis则是直接把数据存储到内存中，减少了磁盘I/O造成的消耗。

2、高效的数据结构

合理的数据结构，就是可以让应用/程序更快。Mysql索引为了提高效率，选择了B+树的数据结构。先看下Redis的数据结构&内部编码图：

2.1 SDS简单动态字符串

Redis没有采用原生C语言的字符串类型而是自己实现了字符串结构-简单动态字符串（simple dynamic string)。
Redis为什么可以这么快 - 图4
图8 C语言字符串类型
Redis为什么可以这么快 - 图5
图9 SDS字符串类型
SDS与C语言字符串的区别：

获取字符串长度：C字符串的复杂度为O(N)，而SDS的复杂度为O(1)。
杜绝缓冲区溢出（C语言每次需要手动扩容），如果C字符串想要扩容，在没有申请足够多的内存空间下，会出现内存溢出的情况，而SDS记录了字符串的长度，如果长度不够的情况下会进行扩容。
减少修改字符串时带来的内存重分配次数。
- 空间预分配，
  - 规则1：修改后长度< 1MB，预分配同样大小未使用空间，free=len；
  - 规则2：修改后长度 >= 1MB，预分配1MB未使用空间。
- 惰性空间释放，SDS 缩短时，不是回收多余的内存空间，而是free记录下多余的空间，后续有变更，直接使用free中记录的空间，减少分配。

2.2 embstr & raw

Redis 的字符串有两种存储方式，在长度特别短时，使用 emb 形式存储(embeded)，当长度超过 44 时，使用 raw 形式存储。
Redis为什么可以这么快 - 图6
图10 embstr和raw数据结构
为什么分界线是 44 呢？
在CPU和主内存之间还有一个高速数据缓冲区，有L1，L2，L3三级缓存，L1级缓存时距离CPU最近的，CPU会有限从L1缓存中获取数据，其次是L2，L3。
Redis为什么可以这么快 - 图7
图11 CPU三级缓存
L1最快但是其存储空间也是有限的，大概64字节，抛去对象固定属性占用的空间，以及‘\0’，剩余的空间最多是44个字节，超过44字节L1缓存就会存不下。
Redis为什么可以这么快 - 图8
图12 SDS在L1缓存中的存储方式

2.3 字典(DICT)

Redis 作为 K-V 型内存数据库，所有的键值就是用字典来存储。字典就是哈希表，比如HashMap，通过key就可以直接获取到对应的value。而哈希表的特性，在O（1）时间复杂度就可以获得对应的值。

【Objective-c】
//字典结构数据
typedef struct dict {
    dictType *type;  //接口实现，为字典提供多态性
    void *privdata;  //存储一些额外的数据
    dictht ht[2];   //两个hash表
    long rehashidx. //渐进式rehash时记录当前rehash的位置
} dict;

两个hashtable通常情况下只有一个hashtable是有值的，另外一个是在进行rehash的时候才会用到，在扩容时逐渐的从一个hashtable中迁移至另外一个hashtable中，搬迁结束后旧的hashtable会被清空。
Redis为什么可以这么快 - 图9
图13 Redis hashtable

【Objective-c】
//hashtable的结构如下：
typedef struct dictht {
   dictEntry **table;  //指向第一个数组
   unsigned long size;  //数组的长度
   unsigned long sizemask; //用于快速hash定位
   unsigned long used; //数组中元素的个数
} dictht;
typedef struct dictEntry {
   void *key;
   union {
       void *val;
       uint64_t u64;
       int64_t s64;
       double d;   //用于zset，存储score值
       } v;
       struct dictEntry *next;
} dictEntry;

Redis为什么可以这么快 - 图10
图14 Redis hashtable

2.4 压缩列表（ziplist）

redis为了节省内存空间，zset和hash对象在数据比较少的时候采用的是ziplist的结构，是一块连续的内存空间，并且支持双向遍历。
Redis为什么可以这么快 - 图11
图15 ziplist数据结构

2.5 跳跃表

跳跃表是Redis特有的数据结构，就是在链表的基础上，增加多级索引提升查找效率。
跳跃表支持平均 O（logN）,最坏 O（N）复杂度的节点查找，还可以通过顺序性操作批量处理节点。

Redis为什么可以这么快 - 图12
图16 跳跃表数据结构

3 合理的数据编码

Redis 支持多种数据类型，每种基本类型，可能对多种数据结构。什么时候使用什么样的数据结构，使用什么样的编码，是redis设计者总结优化的结果。

String：如果存储数字的话，是用int类型的编码;如果存储非数字，小于等于39字节的字符串，是embstr；大于39个字节，则是raw编码。
List：如果列表的元素个数小于512个，列表每个元素的值都小于64字节（默认），使用ziplist编码，否则使用linkedlist编码。
Hash：哈希类型元素个数小于512个，所有值小于64字节的话，使用ziplist编码,否则使用hashtable编码。
Set：如果集合中的元素都是整数且元素个数小于512个，使用intset编码，否则使用hashtable编码。
Zset：当有序集合的元素个数小于128个，每个元素的值小于64字节时，使用ziplist编码，否则使用skiplist（跳跃表）编码

4 合理的线程模型

4.1、单线程模型

首先是单线程模型-避免了上下文切换造成的时间浪费，单线程指的是网络请求模块使用了一个线程，即一个线程处理所有网络请求，其他模块仍然会使用多线程；在使用多线程的过程中，如果没有一个良好的设计，很有可能造成在线程数增加的前期吞吐率增加，后期吞吐率反而增长没有那么明显了。
多线程的情况下通常会出现共享一部分资源，当多个线程同时修改这一部分共享资源时就需要有额外的机制来进行保障，就会造成额外的开销。
Redis为什么可以这么快 - 图13
图17 线程数与吞吐率关系

另外一点则是I/O多路复用模型，在不了解原理的情况下，我们类比一个实例：在课堂上让全班30个人同时做作业，做完后老师检查，30个学生的作业都检查完成才能下课。如何在有限的资源下，以最快的速度下课呢？

第一种：安排一个老师，按顺序逐个检查。先检查A，然后是B，之后是C、D…这中间如果有一个学生卡住，全班都会被耽误。这种模式就好比用循环挨个处理socket，根本不具有并发能力。这种方式只需要一个老师，但是耗时时间会比较长。
第二种：安排30个老师，每个老师检查一个学生的作业。这种类似于为每一个socket创建一个进程或者线程处理连接。这种方式需要30个老师（最消耗资源），但是速度最快。
第三种：安排一个老师，站在讲台上，谁解答完谁举手。这时C、D举手，表示他们作业做完了，老师下去依次检查C、D的答案，然后继续回到讲台上等。此时E、A又举手，然后去处理E和A。这种方式可以在最小的资源消耗的情况下，最快的处理完任务。
4.2、IO多路复用

图18 I/O多路复用
多路I/O复用技术可以让单个线程高效的处理多个连接请求，而Redis使用epoll作为I/O多路复用技术的实现。并且，Redis自身的事件处理模型将epoll中的连接、读写、关闭都转换为事件，不在网络I/O上浪费过多的时间。

5、使用场景

6、总结

基于以上的内容，我们可以了解到Redis为什么可以这么快的原因：

纯内存操作，内存的访问是非常迅速的；
多路复用的I/O模型，可以高并发的处理更多的请求；
精心设计的高效的数据结构；
合理的内部数据编码，对内存空间的高效实用。

总之，Redis为了高性能，从各个方面都做了很多优化，在使用Redis的过程中，掌握了其运行原理，才能在使用的过程中注意到那些操作会影响到Redis的性能。

Redis为什么可以这么快