Redis只包含"键"和"值"两部分，键的数据类型是字符串，值的数据类型有字符串、列表、字典、集合、有序集合
列表-->两种实现方法：压缩列表；双向循环链表
当列表中存储的数据量比较小的时候，列表就可以采用压缩列表的方式实现。具体需要满足下面两个条件：
列表中保存的单个数据（有可能是字符串类型的）小于64字节；列表中数据个数少于512个
压缩列表是Redis自己设计的一种数据存储结构，类似于数组，通过一片连续的内存空间，来存储数据。与数组的不同之处在于它允许存储的数据大小不同。“压缩”就是节省内存。之所以说这种存储结构节省内存，是相较于数组的存储思路而言的。数组要求每个元素的大小相同，如果要存储不同长度的字符串，那就需要用最大长度的字符串大小作为元素的大小。当存储小于 20 个字节长度的字符串的时候，便会浪费部分存储空间
压缩列表这种存储结构，一方面比较节省内存，另一方面可以支持不同类型数据的存储。而且，因为数据存储在一片连续的内存空间，通过键来获取值为列表类型的数据，读取的效率也非常高。
当列表中存储的数据量比较大的时候，也就是不能同时满足刚刚讲的两个条件的时候，列表就要通过双向循环链表来实现了。
Redis 的这种双向链表的实现方式，额外定义一个 list 结构体，来组织链表的首、尾指针，还有长度等信息。
字典-->两种实现方法：压缩列表；散列表 字典类型用来存储一组数据对。每个数据对又包含键值两部分。
同样，只有当存储的数据量比较小的情况下，Redis 才使用压缩列表来实现字典类型。具体需要满足两个条件：字典中保存的键和值的大小都要小于 64 字节；字典中键值对的个数要小于 512 个。
当不能同时满足上面两个条件的时候，Redis 就使用散列表来实现字典类型。Redis 使用MurmurHash2这种运行速度快、随机性好的哈希算法作为哈希函数。对于哈希冲突问题，Redis 使用链表法来解决。除此之外，Redis 还支持散列表的动态扩容、缩容。
当数据动态增加之后，散列表的装载因子会不停地变大。为了避免散列表性能的下降，当装载因子大于 1 的时候，Redis 会触发扩容，将散列表扩大为原来大小的 2 倍左右（具体值需要计算才能得到）
当数据动态减少之后，为了节省内存，当装载因子小于 0.1 的时候，Redis 就会触发缩容，缩小为字典中数据个数的大约 2 倍大小（这个值也是计算得到的）。
扩容缩容要做大量的数据搬移和哈希值的重新计算，所以比较耗时。针对这个问题，Redis 使用渐进式扩容缩容策略，将数据的搬移分批进行，避免了大量数据一次性搬移导致的服务停顿。
集合-->两种实现方式：有序数组；散列表 用来存储一组不重复的数据
当要存储的数据，同时满足下面这样两个条件的时候，Redis 就采用有序数组，来实现集合这种数据类型。
存储的数据都是整数；存储的数据元素个数不超过 512 个。
当不能同时满足这两个条件的时候，Redis 就使用散列表来存储集合中的数据。
有序集合-->压缩列表；跳表（查找、插入、删除-->O(logn)）
它用来存储一组数据，并且每个数据会附带一个得分。通过得分的大小，我们将数据组织成跳表这样的数据结构，以支持快速地按照得分值、得分区间获取数据。
当数据量比较小的时候，Redis 会用压缩列表来实现有序集合。具体点说就是，使用压缩列表来实现有序集合的前提，有这样两个：所有数据的大小都要小于 64 字节；元素个数要小于 128 个。
如何将数据结构持久化到硬盘？
第一种是清除原有的存储结构，只将数据存储到磁盘中。当需要从磁盘还原数据到内存的时候，再重新将数据组织成原来的数据结构。实际上，Redis 采用的就是这种持久化思路。不过，这种方式也有一定的弊端。那就是数据从硬盘还原到内存的过程，会耗用比较多的时间。比如，现在要将散列表中的数据存储到磁盘。当从磁盘中，取出数据重新构建散列表的时候，需要重新计算每个数据的哈希值。如果磁盘中存储的是几 GB 的数据，那重构数据结构的耗时就不可忽视了。
第二种方式是保留原来的存储格式，将数据按照原有的格式存储在磁盘中。比如可以将散列表的大小、每个数据被散列到的槽的编号等信息，都保存在磁盘中。有了这些信息，从磁盘中将数据还原到内存中的时候，就可以避免重新计算哈希值。