Redis内存优化理解和存储总结(2)

2.复杂类型的存储优化，比如Map，List，Set等，这些集合都有一个特点可大可小，根据实际场景来定，一般情况下如果这些集合所包含的Entry不多，并且每个Entry所包含的Value不是很长的情况下，Redis内部使用紧凑格式来存储数据，紧凑格式存储数据在查询场景的算法复杂度是O(N)，而类似Map或者Set他们的查询算法复杂度都是O(1)那为什么要这么做呢 ？为了能够节省内存空间，在N很小的时候其实和O(1)没什么区别。所以这里不的不介绍紧凑格式的代表ZIPMap，他的数据结构是这样：

  www.2cto.com  

 

可以看出，这个结构中初始情况只有2个字节，随着操作的增加它会变长，其中最关键的是一个关于Free这个字段的理解，以Map为例，如果新插入一个Key，那么对应ZipMap就会多出来一长串数据:<len><key><len><free><value>。从图中可以看到插入key1的时候只有绿色的一串，当key2插入的时候就会又出来一个类似的黄色结构串。free的功能是在插入的时候用来冗余空间的，当key所对应的数值发生变化的时候，如果数据变的比之前短了，那么free的长度就变大，这个时候不需要做ZipMap的resize操作，如果数据长度变长了，并且在free能够足以支持新数据的范围之内，那么free就被利用起来，并且也不需要做Resize。这个时候会有空间的浪费或者说碎片。空间换时间吧，没什么好说的。当然Redis的代码中还有另外一个参数ZIPMAP_VALUE_MAX_FREE，这个参数可以用来设置如果Free的大小超过了这个值，那么ZipMap会发生Resize（收缩），从而节约空间。
 

接触的不久，先说这么多好了。

 

 

 

作者 DAGiGi