列表类型 作为 Redis 最重要的数据类型之一，广泛使用在 各种列表业务、消息队列 等场景

实际前面我们一直没有提到一种 数据结构 快速列表 quicklist，就是为了等这一刻，因为 快速列表 是 列表类型的专属 数据结构，而且 其实现 基础为 压缩列表 ziplist 和 双端链表 ……

字符串类型 在 Redis 中属于最常见也是最简单的数据类型，底层实现主要为 sds 简单动态字符串结构

字符串类型 底层实现为 简单动态字符串数据结构，所以是 二进制安全的，意味着可以存储任何格式数据，不过长度要求不能高于 512MB…

此 承前 数据结构，启后 数据类型

前面我们介绍了 各种数据结构 ( sds、dict、skiplist、intset、ziplist 等 )，作为 Redis 对外提供的 各种数据类型的 底层组成部分；但是 各种数据类型的 键值对 并不是直接使用 这些数据结构，而是基于这些 数据结构 构建了一个 对象系统 ( 字符串对象、列表对象、哈希对象、集合对象 、有序集合对象 )，每种对象都 至少使用了一种 我们之前提到的 数据结构

压缩列表ziplist 是由一系列特殊编码的连续内存块组成的顺序型数据结构，即 将一系列数据与其编码信息存储在一块物理上连续的内存空间上，但是 逻辑上却是分作多个部分，其目的是在一定可控的时间复杂读条件下尽可能的减少不必要的内存开销，从而达到节省内存的效果

Redis 中 压缩列表 是 列表键和哈希键 的底层实现之一，当一个 列表键只包含少量列表项 并且每个列表项 要么是比较小的整数值或者比较短的字符串 的时候，那么就会使用 压缩列表进行表示，同理 哈希键的情况也是一样的

压缩列表 的实现原理主要体现在 编码 这个词上，所以我们后续更多以 编码 角度去解读…

书里总爱写到喜出望外的傍晚

骑的单车还有他和她的对谈

女孩的白色衣裳男孩爱看她穿

好多桥段

好多都浪漫

好多人心酸

好聚好散

好多天都看不完

刚才吻了你一下你也喜欢对吗

Redis 作为内存存储系统，在内存节约方面肯定会有所特点，而且 Redis 在这方面要求极其苛刻，比较明显的就是 整数集合intset 和 压缩列表ziplist 两个结构

这次我们就以 整数集合 intset 作为主题 ~~~

整数集合intset 是 集合键的底层实现之一，当一个集合只包含整数元素，而且集合的元素数量不多时（限制值默认 server.set_max_intset_entries = OBJ_SET_MAX_INTSET_ENTRIES = 512），Redis 就会使用整数集合作为集合键的底层实现

跳跃表 ( skiplist ) 为一种随机化的数据结构，以有序的方式在层次化的链表中保存元素，通过在每个节点中维持多个指向其他节点的指针，从而达到快速访问的目的。

跳跃表在 Redis 主要是作为 有序集合ZSET 类型数据 的底层实现之一，如果有序集合里面包含的数量比较多，或者 成员元素的 键比较长（必须大于 zset-max-ziplist-value 设置的值 默认 64，否则使用 ziplist ）；

假如有个至少数十万的数据需要进行按顺序存放，并且能按照最低复杂度 增删改查。一般情况下都是使用线性的 链表 和 数组 实现，但是无论数组还是链表在 写入的时候都是一个效率很低的操作：遍历获取存入位置，最快的方法就是使用 二分查找，链表不能使用 二分查找，但是呢，数组又需要 插入位置之后的所有元素后移；总结来说，数组的插入复杂度是 O(n)，链表的查找复杂度是 O(n)，所以使用普通的线性表是一个恐怖的操作。

so，这个时候 跳跃表 ( skiplist ) 就出现了…

跳跃表 ( skiplist ) 在 增删改查 的复杂度上平均能达到 O(log n)，最坏O(n)，至于为什么 Redis 使用了 skiplist 而不是各种比如 红黑树 的平衡树呢，且看下面详解 < 挖坑 跑 >~~~

字典是 构建 Redis 底层结构的重要数据结构，比如 命令表 commands、数据库、哈希键 等，尤其数据库部分，对数据库的增、删、查、改都是建立在对字典的操作上

字典 是一种保存键值对的抽象数据结构；在字典中，一个键 key 与 一个值 value 进行关联，组成键值对，一般又称 符号表 / 关联数组 / map 映射等；字典中的键都是独一无二的，程序可以在字典中根据键查找与之关联的值，或者通过键来更新值，又或者根据键来删除整个键值对 等等；通常高级语言都会内置实现好的 字典数据结构，比如 PHP 的关联数组、Java 的 MAP 等都是如此