Redis的ziplist的数据结构是怎样的?[面试5.0]
redis的ziplist数据结构
zlbytes: 压缩列表的字节长度,占4个字节,图中zlbytes表示压缩列表总字节长度为80字节
zltail: 压缩列表尾元素相对于压缩列表起始地址的偏移量,占4个字节,若P为压缩列表起始地址的指针,那么P+60就是entry尾节点的地址
zllen: 压缩列表的元素个数,占2个字节,图中为3即表示3个entry
zlend: 压缩列表的结尾,占1个字节,恒为0xFF
previous entry length(即prevrawlen): 前一个元素的字节长度
前一节点的长度小于254字节时previous entry length为1字节
前一节点的长度大于等于254字节时previous entry length为5字节
该属性会关系到一个连锁更新机制
encoding: 当前元素的编码,以及长度
content: entry节点的内容,可以是一个字节数组或一个整数,值的类型和长度由encoding属性决定
连锁更新:
前一个元素的字节长度由于内存重分配大于等于254时,会导致后边的entry的prevrawlen属性依次连锁扩容
连锁更新最坏情况下需要对压缩列表进行N次空间重分配(entry个数为N),每次空间重分配最坏情况下需要进行N次长度计算(单个Entry节点的长度),所以最坏的情况下为O(N^2),但出现连锁更新的情况比较少,必须要满足如下条件:
压缩列表里恰好有多个连续的,长度介于250到253字节之间的节点
即便出现连锁更新,只要被更新节点数目不多,影响就不大,纯内存操作还是挺快的
ziplist的优点:
ziplist比起skiplist少了指针,比较节省内存
ziplist的缺点:
由于ziplist内存连续,其增删改都需要对内存的申请和释放,存在对整块内存的拷贝,增删改性能都不好