小对象压缩存储
如果Redis内部管理的集合数据结构很小,他会使用紧凑存储形式压缩存储。
Redis的ziplist是一个紧凑的字节数组结构,如下图所示,每个元素之间都是紧挨着的。
如果他存储的是hash结构,那么key和value会作为两个entry相邻存在一起。
如果他存储的是zset,那么value和score会作为两个entry相邻在一起。
Redis的intset是一个紧凑的整数数组结构,他用于存放元素都是整数的并且元素个数较少的set集合。
如果整数可以用uint16表示,那么intset的元素就是16位的数组,如果新加入的整数超过了uint16的表示范围,那么就使用uint32表示,如果新加入的元素超过了uint32,那么就使用了uint64。Redis支持set集合动态从uint16升级到uint32,在升级到uint64。
如果set里存储的是字符串,那么sadd立即升级为hashtable结构。
存储界限
当集合对象的元素不断增加,或者某个value值过大,这种小对象存储也会被升级为标准结构。Redis规定在小对象存储结构的限制条件如下
hash-max-zipmap-entries 512 # hash 的元素个数超过 512 就必须用标准结构存储
hash-max-zipmap-value 64 # hash 的任意元素的 key/value 的长度超过 64 就必须用标准结构存储
list-max-ziplist-entries 512 # list 的元素个数超过 512 就必须用标准结构存储
list-max-ziplist-value 64 # list 的任意元素的长度超过 64 就必须用标准结构存储
zset-max-ziplist-entries 128 # zset 的元素个数超过 128 就必须用标准结构存储
zset-max-ziplist-value 64 # zset 的任意元素的长度超过 64 就必须用标准结构存储
set-max-intset-entries 512 # set的整数元素个数超过512就必须用标准结构存储
Redis内存回收机制
Redis并不总是可以将空闲内存立即返回给操作系统。
如果当前Redis内存有10G,当删除了1GB的key后,再去观察内存,会发现内存变化不会太大,原因是操作系统回收内存是以页为单位,如果这个页上只要有一个key还在使用,那么他就不能被回收。Redis虽然删除了1GB的key,但是这些key分散到了很多页面中,每个页面都还有key存在,这就导致了Redis内存不会立即被回收。
不过,如果执行了flushdb,然后在观察内存会发现内存确实被回收了。原因是所有的key都被删除掉了,大部分之前使用的页面都完全干净了。
Redis虽然无法保证立即回收已经删除的key的内存,但是他会重用那些尚未回收的空闲内存。
内存分配算法
内存分配是一个非常复杂的课题,需要适当的算法划分内存页,需要考虑内存碎片,需要平衡性能和效率。Redis为了保持自身结构的简单,在内存分配这里直接使用了第三方内存分配库,如使用jemalloc(facebook)库来管理内存,也可以切换到tcmalloc(google)。因为jemalloc相比tcmalloc性能稍好,所以Redis默认使用了jemalloc。