Redis存储优化--小对象压缩

客官°小女子只卖身不卖艺 2022-12-21 03:20 97阅读 0赞

#### 小对象压缩 ####

*  Redis是一种内存数据库，内存是计算机中一种比较宝贵的资源，如果我们不注意节约，Redis很可能出现内存不足，最终导致崩溃。Redis为了优化数据结构的内存占用，增加了非常多的优化点，这些优化也是牺牲代码的可读性为代价，但是对于解决的内存问题来说是非常值得的，尤其是对于Redis这种内存数据库

##### 32bit VS 64bit #####

*  Redis如果使用32bit版本，内部存储所有数据结构使用的指针空间占用会少一半,如果Redis使用内存不会超过2^32 = 4GB，可以考虑32bit进行编译，能节约大量内存。4GB容量对小站点来说戳戳由于。不足可以增加节点
    
     *  指针是寻址，存储的是地址信息，32bit系统能表示的总大小是2^32 位，所以指针能表示的寻址最大值也就是 2 ^32，同理64bit 系统占用2 ^ 64

##### 小对象压缩 #####

*  如果Redis内部管理的集合数据结构很小，他会使用紧凑型存储形式压缩存储，只有当集合数据达到一定量级的时候，Redis才会将数据存储称为正常我们熟知的状态。
 *  例如HashMap本来是二维结构，如果内部元素少，使用数组+链表的形式反而浪费空间，因为指针占用空间比数据还要多，还不如使用一维数组进行存储，查找时候元素少，遍历也快，只不过代码略复杂而已。以下案例用一维数组存储HashMap的CUD

public class ArrayMap<K, V> { 
        private List<K> keys = new ArrayList<>();
        private List<V> values = new ArrayList<>();
    
        public V put(K k, V v){ 
            for (int i = 0; i < keys.size(); i++) { 
                if(keys.get(i).equals(k)){ 
                    V oldv = values.get(i);
                    values.set(i, v);
                    return oldv;
                }
            }
            keys.add(k);
            values.add(v);
            return null;
        }
    
        public V get(K k){ 
            for (int i = 0; i < keys.size(); i++) { 
                if(keys.get(i).equals(k)){ 
                    return values.get(i);
                }
            }
            return null;
        }
    
        public V delete(K k){ 
            for (int i = 0; i < keys.size(); i++) { 
                if(keys.get(i).equals(k)){ 
                    keys.remove(k);
                    return values.remove(i);
                }
            }
            return null;
        }
    }

*  同样Redis的ziplist是一个紧凑型的字节数组结构，如下图中所示，每个元素都是紧密相连，中间没有指针用来寻址操作，通过三个全局指针来完成逻辑处理，zlbytes， zltail和zlend。如下：  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpYW9qaWFtaW4wMTAy_size_16_color_FFFFFF_t_70_pic_center]
 *  如果如上结果存储的是hash结构，那么key和value作为两个entry，被相邻的两个entry存储，通过如下方式验证，输出类型是ziplist：

新docker-redis:0>hset hello a 1
    "1"
    新docker-redis:0>hset hello b 2
    "1"
    新docker-redis:0>object encoding hello
    "ziplist"

*  如果存储的类型是zset，那么value和score会作为两个entry被相邻存储

新docker-redis:0>zadd world 1 a
    "1"
    新docker-redis:0>zadd world 2 b
    "1"
    新docker-redis:0>object encoding world
    "ziplist"

*  整数的存储Redis有一个叫intset的整数数组结构，用于存放元素都是整数且元素个数较少的set集合。
 *  如果整数可以用uint16标识，那么intset的元素就是16位的数组，如果新加入的整数超过uint16，那么久用uint32，还不够则用uint64，Redis支持set集合动态从unit16升级到unit32,在到unit64

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpYW9qaWFtaW4wMTAy_size_16_color_FFFFFF_t_70_pic_center 1]

*  如下代码，我们在set集合中存储的数字，他的类型就是intset

新docker-redis:0>sadd hello 1 2
    "2"
    新docker-redis:0>object encoding hello
    "intset"

*  如果set存储的字符串，那么sadd会升级为hashtable结构，

新docker-redis:0>sadd hello yes no
    "2"
    新docker-redis:0>object encoding hello
    "hashtable"

###### 总结 ######

hash - max-z 工pl 工 st entries 512 结构存储  			# hash 的元素个数超过 512 就必须用标准
    hash- max-ziplist-value 64 超过 64 就必须用标准结构存储  	# hash 的任意元素的 key/value 的长度超过64 就必须用标准结构存储
    list-max-ziplist-entries 512 结构存储  					# list 的元素个数超过 512 就必须用标准结构存储
    list-max-z 工plist - 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 就必须用标准结构存储

*  如下测试代码：

public static void main(String[] args) { 
            Jedis jedis = JedisPoolTools.getJedis();
            jedis.del("books");
            for (int i = 0; i < 512; i++) { 
                jedis.hset("books", String.valueOf(i), String.valueOf(i));
            }
            System.out.println(jedis.objectEncoding("books"));
            jedis.hset("books", "hello", "512");
            System.out.println(jedis.objectEncoding("books"));
        }
    //输出如下：
    ziplist
    hashtable

*  当Hash结构元素超过512 ，存储结构发生变化其他的也都同理，我们通过如上总结数据看出，当hash结构的任意entry的value超过64 ，存储结构就升级成标准结构。

##### 内存回收机制 #####

*  Redis并不总是将空闲内存理解归还操作系统
 *  例如Redis内存10GB，当删除1GBkey后，观察内存，并不会太大变化，因为操作系统是以页为单位回收内存，这个页内只要还有一个key，就不会被回收。Redis虽然删除了1GBkey但是这些key是分散到各个page中，每个page都还有其他key，这就导致内不会被立刻回收。
 *  我们执行flushdb，观察内存，他就会重新使用那些尚未回收的空闲内存。就比如一个page中只有一个key，次数set另一个key，他会存储在这个page的空闲内存中。

##### 内存分配算法 #####

*  内存分配是比较复杂的，需要是的划分内存页，考虑内存碎片，需要平衡性能与效率
 *  Redis为保证自身结构简单，目前没有自己做内存分配策略，由第三方库完成此部分内容，
    
     *  Redis可以用jemalloc，facebook的库来管理内存
     *  Redis也可以切换到tcmalloc，google的库来管理
 *  jemalloc性能优于tcmalloc，Redis默认使用jemalloc

新docker-redis:0>info memory
    "# Memory
    used_memory:5110711968
    .....
    mem_fragmentation_ratio:1.33
    mem_allocator:jemalloc-4.0.3
    active_defrag_running:0
    lazyfree_pending_objects:0

*  通过info memory指令可以看到Redis的 mem\_allocator:jemalloc-4.0.3使用的jemalloc-4.0.3

[上一篇：Redis–事务理解][Redis]  
[下一篇：Redis高可用基石–主从同步][Redis 1]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpYW9qaWFtaW4wMTAy_size_16_color_FFFFFF_t_70_pic_center]: /images/20221120/f6c6751d5d2e4b3d9ba1e218aa1eec31.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpYW9qaWFtaW4wMTAy_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221120/96ded97878064fe1a39ef3eeae7b7309.png
[Redis]: https://blog.csdn.net/liaojiamin0102/article/details/109688568
[Redis 1]: https://blog.csdn.net/liaojiamin0102/article/details/109692068