Redis紧缩列表的细致介绍（示例解说）
此篇文章是主要介绍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字节）。
紧缩列表节点的格局：
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紧缩列表的细致介绍（示例解说）的细致内容，更多请关注 百分百源码网 其它相干文章！
