此篇文章是主要引见Redis在数据存储方面的个中一种体式格局，紧缩列表。
本文会引见
1、紧缩列表（ziplist）的运用场景
2.怎样到达勤俭内存的结果？
3.紧缩列表的存储花样
4. 连锁更新的题目
5. conf文件设置。
在实践上的操纵重假如对conf设置文件举行设置，详细上没有确实的一个值，更多是经验值。也有的项目会直接运用底本的默许值。此篇关于更好地明白一个数据库底层的存储逻辑会有一点协助。修学储能，既要博，也要渊。愿望这篇文章对一样也是在进修Redis的列位火伴有点用。（引荐教程：Redis教程）
一、紧缩列表（ziplist）的运用场景：
Redis为了优化数据存储，勤俭内存，在列表、字典（哈希键）和有序鸠合的底层完成了运用紧缩列表这一优化计划。
比方，假如一个哈希键内里存储的字符串比较短，那末Redis就会将它用紧缩列表的花样去存储，即转换为字节数组存储。而一个哈希键内部存储的整数值比较小，一样也会把它存储为紧缩列表的一个节点。同理，列表键的对小数据的存储跟哈希键的操纵相似。
如此说来，紧缩列表并非开发者能够直接挪用的Redis中的一种存储数据构造，而是Redis中为优化数据存储而在底层做的一项勤奋。明白好这点照样比较主要的。
二、怎样到达勤俭内存的结果？
紧缩列表是一种序列化的数据构造，这类数据构造的功用是将一系列数据与其编码信息存储在一块一连的内存地区，这块内存物理上是一连的。但逻辑上被分为多个构成部份，即节点。目标是为了在一定可控的时刻复杂度条件下尽量的削减不必要的内存开支，从而到达节约内存的结果。须要明白是怎样到达勤俭内存作用的，还须要去了解紧缩列表的存储花样。
三、紧缩列表的存储花样：
紧缩列表（ziplist）是Redis列表键、哈希键和有序鸠合键的底层完成之一，其实质是一种序列化的数据存储构造。有别于一般状况下，Redis用双端链表示意列表，运用散列表示意哈希键，用散列表+腾跃表示意有序鸠合。当一个列表或许哈希字典/有序鸠合只包括很少内容，而且每一个列表项或许哈希项/有序鸠合项假如是小整数，或许比较短的字符串。那末Redis就会用紧缩列表来做底层的完成。
紧缩列表由一系列经Redis特别编码的一连内存块构成，每一个内存块称为一个节点（entry），而一个紧缩列表能够包括很多个节点。每一个节点存储的数据花样能够是字节数组（中文字符串等都邑转换为字节数组）或许整数值。
字节数组的长度能够是以下的个中一种：
1. 长度小于即是63字节（2的6次方）
2. 长度小于即是16383字节（2的14次方）
3. 长度小于即是4294967295字节（2的32次方）
整数值多是以下六种中的个中一种：
1. 4位长，介于0-12之间的无标记整数
2. 1字节长的有标记整数
3. 3字节长的有标记整数
4. int16_t范例整数
5. int32_范例整数
6. int64_t范例整数
一般存储花样下和紧缩列表存储花样下的不同点：
列表存储构造典范的为双端链表，每一个值都是用一个节点来示意，每一个节点都邑有指向前一个节点和后一个节点的指针，以及指向节点包括的字符串值的指针。而字符串值又分为3个部份存储，第一部份存储字符串长度，第二部份存储字符串值中盈余可用的字节量，第三部份存储的则是字符串数据自身。所以一个节点每每都须要存储3个指针、2个纪录字符串信息的整数、字符串本省和一个分外的字节。总体上分外的开支是很大的（21字节）。
紧缩列表节点的花样：
每一个节点都有previous_entry_length,encoding,content三个部份构成，在遍历紧缩列表的时刻是从后往前遍历的。
1. previous_entry_length纪录了前一个节点的长度，只要用当前指针减去这个值就能够到达前一个节点的肇端地点。
2. encoding纪录了节点content属性所保留数据的范例和长度
3. content纪录了一个节点的值
明显紧缩列表这类体式格局勤俭了不少存储空间。但同时也会激发下面的题目。
四、连锁更新的题目：
一般而言假如前一个节点的团体长度小于254字节，previous_entry_length属性只须要1个字节的空间来保留这个长度值。而当前一个节点大于254字节的时刻，previous_entry_length属性要用5个字节长的空间来纪录长度值。
当长度为254字节摆布的节点前插进去一个新的节点的时刻，须要增添previous_entry_length来纪录这个节点到新节点的偏移量。这个时刻，这个节点的长度一定就大于254字节了。所以这个节点的后一个节点就不能只用一个字节的previous_entry_length来纪录这个节点的信息了，而是须要5个字节来纪录。假如一连多个节点的长度都为254字节摆布，在个中的某一个节点前/后发作节点的插进去和删除（删除的推理与插进去相反，底本用5字节纪录前一节点的能够变成1字节），都能够激发连锁的更新，明显，如许对体系地运转效力是很不利的。不过，在现实运用中这类状况照样比较少发作的。
而双端链表在节点的更新、增添和删除上显得就会“轻松”很多了。 由于每一个节点存储的信息都是相对自力的。
实践意义：
要预估一个节点也许占有若干字节的存储空间，适当地调解字段的存储花样而不要使存储的字段值占有存储空间落在254字节（撤除encoding属性和previous_entry_length属性）摆布。
Redis中检察字符串和哈希键值的长度相干敕令：
1. 查询字符串键对应的值长度
敕令：
Strlen
比方：
127.0.0.1:6379> strlen m_name
(integer) 8
2. 查询哈希键某一个域长度
敕令：
Hstrlen
比方：
127.0.0.1:6379> hstrlen good_list good_list1
(integer) 226
五、Conf文件设置：
经由过程修正设置文件，能够掌握是不是运用紧缩列表存储相干键的最大元素个数和最大元素的大小
Conf文件中的设置：
1.
[] -max-ziplist-entries ： 示意关于键的最大元素个数，即一个键中在该指定值下的数目的节点个数都邑用紧缩列表来贮存
[] -max-ziplist-value ：示意紧缩列表中每一个节点的最大体积是若干字节
现实运用中，一个列表键/哈希键的某一个元素每每存储着比较大的信息量，会大于64字节，所以设置时很有能够会比64大，同时考虑到现实存储数据的容量大小以及上面谈到的previous_entry_length的大小题目，对[] -max-ziplist-value举行合理的设置。
设置文件内容：
############## ADVANCED CONFIG ########################## 哈希键 # Hashes are encoded using a memory efficient data structure when they have a # small number of entries, and the biggest entry does not exceed a given # threshold. These thresholds can be configured using the following directives. hash-max-ziplist-entries 512 hash-max-ziplist-value 64 有序鸠合键 # Similarly to hashes and lists, sorted sets are also specially encoded in # order to save a lot of space. This encoding is only used when the length and # elements of a sorted set are below the following limits: zset-max-ziplist-entries 128 zset-max-ziplist-value 64 列表键，比较特别，直接运用制订大小kb字节数示意（有些conf文件的列表键与hash键的表达式没太大区分） # Lists are also encoded in a special way to save a lot of space. # The number of entries allowed per internal list node can be specified # as a fixed maximum size or a maximum number of elements. # For a fixed maximum size, use -5 through -1, meaning: # -5: max size: 64 Kb <-- not recommended for normal workloads # -4: max size: 32 Kb <-- not recommended # -3: max size: 16 Kb <-- probably not recommended # -2: max size: 8 Kb <-- good # -1: max size: 4 Kb <-- good # Positive numbers mean store up to _exactly_ that number of elements # per list node. # The highest performing option is usually -2 (8 Kb size) or -1 (4 Kb size), # but if your use case is unique, adjust the settings as necessary. list-max-ziplist-size -2
案例：
修正设置前运用默许设置：
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
127.0.0.1:6379> hstrlen good_list good_list1
(integer) 226
127.0.0.1:6379> object encoding good_list
"hashtable"
修正设置：
hash-max-ziplist-entries 512
hash-max-ziplist-value 254
注重：修正设置后须要重启服务器
127.0.0.1:6379> hstrlen good_list good_list1
(integer) 226
127.0.0.1:6379> object encoding good_list
"ziplist"
能够看到存储体式格局已将变成ziplist
较官方的压力测试和指点发起：
当一个紧缩列表的元素数目上升到几千（现实运用能够远小于这个值）的时刻，紧缩列表的机能能够会下落，由于Redis在操纵这类构造的时刻，编解码会涌现一定的压力。
紧缩列表的长度限定在500-2000以内，每一个元素体积限定在128字节或以下，紧缩列表的的机能都邑处于合理局限以内。
以上就是Redis紧缩列表的细致引见（示例解说）的细致内容，更多请关注ki4网别的相干文章！
