https://excelight.github.io/tags/redis/ Recent content in Redis on Excelight's Blog Hugo -- gohugo.io en Thu, 07 Jul 2016 16:04:21 +0800 https://excelight.github.io/posts/redis_sortedset_optimize/ Thu, 07 Jul 2016 16:04:21 +0800 https://excelight.github.io/posts/redis_sortedset_optimize/ 背景 公司的监控系统的缓存是使用的redis中的sorted set的数据结构来存储。但是使用过程中发现redis的内存消耗特别多，甚至撑暴内存，导致引发线上问题。后来经过计算，发现redis实际消耗的内存远比理论应消耗的内存大(理论上一个数据点包含一个时间戳32位，一个数据值最多64位，总共12字节，而实际占用空间达到150字节左右，相差10倍)，这就引发了我们对sorted set的深入研究 如何使用 我们使用sorted set存储监控数据的格式为 key: metric_id (指标id，如cpu,内存) score: unix时间戳 member: unix时间戳|监控数值（如1432343233|60） 获取监控数据的时候使用 ZRANGE metric_id 0 1432343233 就可以得到按时间排序的各个数据点的值 为何占用大量空间 sorted set的存储设计是这样的，在一个key下如果score的个数小于等于128时，采用一个最紧凑的数组来存储，不会占用额外的空间。而当个数大于128时，会使用额外的数据结构一个ziplist用于快速查找对应，一个跳表来排序，这两个数据结构会产生大量空间占用。具体可以参考http://origin.redisbook.com/datatype/sorted_set.html#sorted-set-chapter 如何优化 由于我们使用对监控数据的存储是分不同的粒度来存储的，单个粒度的数据redis中保存的数据最多不超过400个，于是可以选择将redis默认的zset-max-ziplist-entries=128的设置修改为400，即可以达到所有数据都用最简单的数组来存储，节省了大量空间。当然这样子会在效率上产生一定的影响，不过由于我们对数据的插入操作，只会在数组尾部进行，因此不会需要移动内存，而数据清理只会在数组头部进行，也只需要一次memmove即可，所以评估下来造成的效率影响应该可以接受。