前言
Redis 为什么那么快？
除了它是内存数据库，使得所有的操作都在内存上进行之外，还有一个重要因素，它实现的数据结构，使得我们对数据进行增删查改操作时，Redis 能高效地处理。
因此，这次我们就来好好聊一下 Redis 数据结构：String（字符串）对象、List（列表）对象、Hash（哈希）对象、Set（集合）对象和 Zset（有序集合）。
底层（3.0和3.2之后有变化）对应的分别是：SDS、双向链表、压缩列表、哈希表、跳表、整数集合、quicklist、listpack
特别说明下，void * key 和 void * value 指针指向的是 Redis 对象，Redis 中的每个对象都由 redisObject 结构表示，如下图：
对象结构里包含的成员变量：
type，标识该对象是什么类型的对象（String 对象、 List 对象、Hash 对象、Set 对象和 Zset 对象）；
encoding，标识该对象使用了哪种底层的数据结构；
ptr，指向底层数据结构的指针。
SDS
Redis 是用 C 语言实现的，但是它没有直接使用 C 语言的 char* 字符数组来实现字符串，而是自己封装了一个名为简单动态字符串（simple dynamic string，SDS） 的数据结构来表示字符串，也就是 Redis 的 String 数据类型的底层数据结构是 SDS。
C 语言字符串的缺陷
获取字符串长度的时间复杂度为 O(N),需要便利字符串数组个数得出长度。
字符串的结尾是以 “\0” 字符标识，字符串里面不能包含有 “\0” 字符，因此不能保存二进制数据；
字符串操作函数不高效且不安全，比如有缓冲区溢出的风险（无法预估改变后数据的大小是否会超出原始分配内存大小），有可能会造成程序运行终止
SDS 结构设计
下图就是 Redis 5.0 的 SDS 的数据结构：
结构中的每个成员变量分别介绍下：
len，记录了字符串长度。这样获取字符串长度的时候，只需要返回这个成员变量值就行，时间复杂度只需要 O(1)。
alloc，分配给字符数组的空间长度。这样在修改字符串的时候，可以通过 alloc - len 计算出剩余的空间大小，可以用来判断空间是否满足修改需求，如果不满足的话，就会自动将 SDS 的空间扩展至执行修改所需的大小，然后才执行实际的修改操作，所以使用 SDS 既不需要手动修改 SDS 的空间大小，也不会出现前面所说的缓冲区溢出的问题。
flags，用来表示不同类型的 SDS。一共设计了 5 种类型，分别是 sdshdr5、sdshdr8、sdshdr16、sdshdr32 和 sdshdr64，后面再说明区别之处。
buf[]，字符数组，用来保存实际数据。不仅可以保存字符串，也可以保存二进制数据。
总的来说，Redis 的 SDS 结构在原本字符数组之上，增加了三个元数据：len、alloc、flags，用来解决 C 语言字符串的缺陷。
SDS 结构中有个 flags 成员变量，表示的是 SDS 类型。
Redis 一共设计了 5 种类型，分别是 sdshdr5、sdshdr8、sdshdr16、sdshdr32 和 sdshdr64。
这 5 种类型的主要区别就在于，它们数据结构中的 len 和 alloc 成员变量的数据类型不同。
比如 sdshdr16 和 sdshdr32 这两个类型，它们的定义分别如下：
struct__attribute__((__packed__))sdshdr16{
uint16_t len;
uint16_t alloc;
unsigned char flags;
char buf[];
};
struct__attribute__((__packed__))sdshdr32{
uint32_t len;
uint32_t alloc;
unsigned char flags;
char buf[];
};
可以看到：
sdshdr16 类型的 len 和 alloc 的数据类型都是 uint16_t，表示字符数组长度和分配空间大小不能超过 2 的 16 次方。
sdshdr32 类型的 len 和 alloc 的数据类型都是 uint32_t，表示字符数组长度和分配空间大小不能超过 2 的 32 次方。
之所以 SDS 设计不同类型的结构体，是为了能灵活保存不同大小的字符串，从而有效节省内存空间。比如，在保存小字符串时，结构体占用空间也比较少。
除了设计不同类型的结构体，Redis 在编程上还使用了专门的编译优化来节省内存空间，即在 struct 声明了 __attribute__ ((packed)) ，它的作用是：告诉编译器取消结构体在编译过程中的优化对齐，按照实际占用字节数进行对齐（如果没有次声明，则会将结构体中的所有变量按最大的变量内存对其分配，导致没有使用这么多内存的用量浪费资源）。
链表
链表节点结构设计
链表结构设计
链表的优势与缺陷
Redis 的链表实现优点如下：
listNode 链表节点的结构里带有 prev 和 next 指针，获取某个节点的前置节点或后置节点的时间复杂度只需 O(1)，而且这两个指针都可以指向 NULL，所以链表是无环链表；
list 结构因为提供了表头指针 head 和表尾节点 tail，所以获取链表的表头节点和表尾节点的时间复杂度只需 O(1)；
list 结构因为提供了链表节点数量 len，所以获取链表中的节点数量的时间复杂度只需 O(1)；
listNode 链表节点使用 void* 指针保存节点值，并且可以通过 list 结构的 dup、free、match 函数指针为节点设置该节点类型特定的函数，因此链表节点可以保存各种不同类型的值。
链表的缺陷也是有的：
链表每个节点之间的内存都是不连续的，意味着无法很好利用 CPU 缓存。能很好利用 CPU 缓存的数据结构就是数组，因为数组的内存是连续的，这样就可以充分利用 CPU 缓存来加速访问。
还有一点，保存一个链表节点的值都需要一个链表节点结构体的分配，内存开销较大。
因此，Redis 3.0 的 List 对象在数据量比较少的情况下，会采用「压缩列表」作为底层数据结构的实现，它的优势是节省内存空间，并且是内存紧凑型的数据结构。
不过，压缩列表存在性能问题（具体什么问题，下面会说），所以 Redis 在 3.2 版本中设计了新的数据结构 quicklist，并将 List 对象的底层数据结构改由 quicklist 实现。
然后在 Redis 5.0 设计了新的数据结构 listpack，沿用了压缩列表紧凑型的内存布局，最终在最新的 Redis 版本，将 Hash 对象和 Zset 对象的底层数据结构实现之一的压缩列表，替换成由 listpack 实现。
哈希表
哈希表是一种保存键值对（key-value）的数据结构。
哈希表中的每一个 key 都是独一无二的，程序可以根据 key 查找到与之关联的 value，或者通过 key 来更新 value，又或者根据 key 来删除整个 key-value 等等。
在讲压缩列表的时候，提到过 Redis 的 Hash 对象的底层实现之一是压缩列表（最新 Redis 代码已将压缩列表替换成 listpack）。Hash 对象的另外一个底层实现就是哈希表。
哈希表优点在于，它能以 O(1) 的复杂度快速查询数据。怎么做到的呢？将 key 通过 Hash 函数的计算，就能定位数据在表中的位置，因为哈希表实际上是数组，所以可以通过索引值快速查询到数据。
但是存在的风险也是有，在哈希表大小固定的情况下，随着数据不断增多，那么哈希冲突的可能性也会越高。
解决哈希冲突的方式，有很多种。
Redis 采用了「链式哈希」来解决哈希冲突，在不扩容哈希表的前提下，将具有相同哈希值的数据串链接起来，以便这些数据在表中仍然可以被查询到。
哈希表结构设计
哈希表节点结构
dictEntry 结构里不仅包含指向键和值的指针，还包含了指向下一个哈希表节点的指针，这个指针可以将多个哈希值相同的键值对链接起来，以此来解决哈希冲突的问题，这就是链式哈希。
不过，链式哈希局限性也很明显，随着链表长度的增加，在查询这一位置上的数据的耗时就会增加，毕竟链表的查询的时间复杂度是 O(n)。
要想解决这一问题，就需要进行 rehash，也就是对哈希表的大小进行扩展。
rehash
随着数据逐步增多，触发了 rehash 操作，这个过程分为三步：
给「哈希表 2」 分配空间，一般会比「哈希表 1」 大 2 倍；
将「哈希表 1」的数据迁移到「哈希表 2」中；
迁移完成后，「哈希表 1」的空间会被释放，并把「哈希表 2」设置为「哈希表 1」，然后在「哈希表 2」新创建一个空白的哈希表，为下次 rehash 做准备。
这个过程看起来简单，但是其实第二步很有问题，如果「哈希表 1」的数据量非常大，那么在迁移至「哈希表 2」的时候，因为会涉及大量的数据拷贝，此时可能会对 Redis 造成阻塞，无法服务其他请求。
渐进式 rehash
渐进式 rehash 步骤如下：
给「哈希表 2」分配空间；
在 rehash 进行期间，每次哈希表元素进行新增、删除、查找或者更新操作时，Redis 除了会执行对应的操作之外，还会顺序将「哈希表 1」中索引位置上的所有 key-value 迁移到「哈希表 2」 上；
随着处理客户端发起的哈希表操作请求数量越多，最终在某个时间内，会把「哈希表 1」的所有 key-value 迁移到「哈希表 2」，从而完成 rehash 操作。
rehash 触发条件
rehash 的触发条件跟负载因子（load factor）有关系。
负载因子可以通过下面这个公式计算：
触发 rehash 操作的条件，主要有两个：
当负载因子大于等于 1 ，并且 Redis 没有在执行 bgsave 命令或者 bgrewiteaof 命令时，也就是没有执行 RDB 快照或没有进行 AOF 重写的时候，就会进行 rehash 操作。
当负载因子大于等于 5 时，此时说明哈希冲突非常严重了，不管有没有在执行 RDB 快照或 AOF 重写，都会强制进行 rehash 操作。
整数集合
整数集合是 Set 对象的底层实现之一。当一个 Set 对象只包含整数值元素，并且元素数量不多时，就会使用整数集这个数据结构作为底层实现。
整数集合结构设计
可以看到，保存元素的容器是一个 contents 数组，虽然 contents 被声明为 int8_t 类型的数组，但是实际上 contents 数组并不保存任何 int8_t 类型的元素，contents 数组的真正类型取决于 intset 结构体里的 encoding 属性的值。比如：
如果 encoding 属性值为 INTSET_ENC_INT16，那么 contents 就是一个 int16_t 类型的数组，数组中每一个元素的类型都是 int16_t；
如果 encoding 属性值为 INTSET_ENC_INT32，那么 contents 就是一个 int32_t 类型的数组，数组中每一个元素的类型都是 int32_t；
如果 encoding 属性值为 INTSET_ENC_INT64，那么 contents 就是一个 int64_t 类型的数组，数组中每一个元素的类型都是 int64_t；
不同类型的 contents 数组，意味着数组的大小也会不同。
整数集合的升级操作
整数集合会有一个升级规则，就是当我们将一个新元素加入到整数集合里面，如果新元素的类型（int32_t）比整数集合现有所有元素的类型（int16_t）都要长时，整数集合需要先进行升级，也就是按新元素的类型（int32_t）扩展 contents 数组的空间大小，然后才能将新元素加入到整数集合里，当然升级的过程中，也要维持整数集合的有序性。
整数集合升级的过程不会重新分配一个新类型的数组，而是在原本的数组上扩展空间，然后再将每个元素按间隔类型大小分割，如果 encoding 属性值为 INTSET_ENC_INT16，则每个元素的间隔就是 16 位。
跳表
Redis 只有在 Zset 对象的底层实现用到了跳表，跳表的优势是能支持平均 O(logN) 复杂度的节点查找。
Zset 对象是唯一一个同时使用了两个数据结构来实现的 Redis 对象，这两个数据结构一个是跳表，一个是哈希表。这样的好处是既能进行高效的范围查询，也能进行高效的单点查询。
quicklist
在 Redis 3.0 之前，List 对象的底层数据结构是双向链表或者压缩列表。在 Redis 3.2 的时候，List 对象的底层改由 quicklist 数据结构实现。
其实 quicklist 就是「双向链表 + 压缩列表」组合，因为一个 quicklist 就是一个链表，而链表中的每个元素又是一个压缩列表。
在前面讲压缩列表的时候，也提到了压缩列表的不足，虽然压缩列表是通过紧凑型的内存布局节省了内存开销，但是因为它的结构设计，如果保存的元素数量增加，或者元素变大了，压缩列表会有「连锁更新」的风险，一旦发生，会造成性能下降。
quicklist 解决办法，通过控制每个链表节点中的压缩列表的大小或者元素个数，来规避连锁更新的问题。因为压缩列表元素越少或越小，连锁更新带来的影响就越小，从而提供了更好的访问性能。
quicklist 结构设计
在向 quicklist 添加一个元素的时候，不会像普通的链表那样，直接新建一个链表节点。而是会检查插入位置的压缩列表是否能容纳该元素，如果能容纳就直接保存到 quicklistNode 结构里的压缩列表，如果不能容纳，才会新建一个新的 quicklistNode 结构。
quicklist 会控制 quicklistNode 结构里的压缩列表的大小或者元素个数，来规避潜在的连锁更新的风险，但是这并没有完全解决连锁更新的问题。
listpack
quicklist 虽然通过控制 quicklistNode 结构里的压缩列表的大小或者元素个数，来减少连锁更新带来的性能影响，但是并没有完全解决连锁更新的问题。
因为 quicklistNode 还是用了压缩列表来保存元素，压缩列表连锁更新的问题，来源于它的结构设计，所以要想彻底解决这个问题，需要设计一个新的数据结构。
于是，Redis 在 5.0 新设计一个数据结构叫 listpack，目的是替代压缩列表，它最大特点是 listpack 中每个节点不再包含前一个节点的长度了，压缩列表每个节点正因为需要保存前一个节点的长度字段，就会有连锁更新的隐患。
我看了 Redis 的 Github，在最新 6.2 发行版本中，Redis Hash 对象、Set 对象的底层数据结构的压缩列表还未被替换成 listpack，而 Redis 的最新代码（还未发布版本）已经将所有用到压缩列表底层数据结构的 Redis 对象替换成 listpack 数据结构来实现，估计不久将来，Redis 就会发布一个将压缩列表替代为 listpack 的发行版本。
listpack 结构设计
主要包含三个方面内容：
encoding，定义该元素的编码类型，会对不同长度的整数和字符串进行编码；
data，实际存放的数据；
len，encoding+data 的总长度。
可以看到，listpack 没有压缩列表中记录前一个节点长度的字段了，listpack 只记录当前节点的长度，当我们向 listpack 加入一个新元素的时候，不会影响其他节点的长度字段的变化，从而避免了压缩列表的连锁更新问题。
*附加
Redis实现分布式锁
常见的单体架构解决线程问题使用lock来解决，实际上是通过监控数值的内存二进制1和0来控制获取锁和释放锁，那在分布式架构中这种方式显然不适用，那么下面就使用redis来实现分布式锁，除了redis还可以使用数据库和zookeeper来实现
选用Redis实现分布式锁原因：
（1）Redis有很高的性能，单命令操作线程不进行I/O操作；
（2）Redis命令对此支持较好，实现起来比较方便
实现方式
添加一个key返回bool结果，并设置过期时间，避免死锁，且在执行完所有逻辑后删除该key,形成闭环。
如果不存在该key则获取锁，存在则表示其他线程正在使用，从而实现分布式锁，但如果在删除key时出现故障，将导致分布式锁失效，这里也提供一个更好的方式，使用redis的Lua脚本打包进行实现
Redis之I/O多路复用
1.客户端发送socket（套接字，文件句柄）连接
2.redis进程scoket server进行连接，并产生事件，由IO多路复用程序负责监听
3.当某个socket实例被监听到需要进行操作时，IO多路复用程序将socket套接字对象添加到队列中
4.在文件事件分配器之前需要进行解析指令操作，再将指令给到命令请求处理器执行，执行完后，通过scoket文件句柄返回给对应的socket(在新版本中，解析指令和返回结果变为多线程处理，但执行命令还是由单线程处理)
模型类型
1.select：轮询IO多路复用程序内核
2.epoll：采用事件处理