浅谈redis key值内存消耗以及性能影响

一、redis key数量为1千万时。

存储value为"0"，比较小。如果value较大，则存储内存会增多

redis key数量为一千万时，使用了865m的内存。

# keyspace
db0:keys=11100111,expires=0,avg_ttl=0
内存使用情况
# memory
used_memory:907730088
used_memory_human:865.68m
used_memory_rss:979476480
used_memory_rss_human:934.10m
used_memory_peak:1258244232
used_memory_peak_human:1.17g
used_memory_peak_perc:72.14%
used_memory_overhead:580102896
used_memory_startup:765664
used_memory_dataset:327627192
used_memory_dataset_perc:36.12%
total_system_memory:8365256704
total_system_memory_human:7.79g
used_memory_lua:37888
used_memory_lua_human:37.00k

二、redis key数量为1千5百万时。

redis key数量为一千五百万时，使用了1.13g的内存。

# keyspace
db0:keys=15100031,expires=0,avg_ttl=0
# memory
used_memory:1211733288
used_memory_human:1.13g
used_memory_rss:1247817728
used_memory_rss_human:1.16g
used_memory_peak:1258244232
used_memory_peak_human:1.17g
used_memory_peak_perc:96.30%
used_memory_overhead:740104496
used_memory_startup:765664
used_memory_dataset:471628792
used_memory_dataset_perc:38.95%
total_system_memory:8365256704
total_system_memory_human:7.79g
used_memory_lua:37888
used_memory_lua_human:37.00k

三、redis key数量为一千五百万时压测

redis-benchmark -h 127.0.0.1 -p 6379 -c 1000 -n 10000 -t get -q
get: 34364.26 requests per second

四、使用map将key值打散存储，小key为1千五百万

使用hset存储打散为1024个key时,存储大小为921m，比直接存储节省了200m。

# memory
used_memory:966758968
used_memory_human:921.97m
used_memory_rss:1002913792
used_memory_rss_human:956.45m
used_memory_peak:1749456304
used_memory_peak_human:1.63g
used_memory_peak_perc:55.26%
used_memory_overhead:1929880
used_memory_startup:765664
used_memory_dataset:964829088
used_memory_dataset_perc:99.88%
total_system_memory:8365256704
total_system_memory_human:7.79g
used_memory_lua:37888
used_memory_lua_human:37.00k 
# keyspace
db0:keys=1024,expires=0,avg_ttl=0

五、使用hset存储打散为256个key

存储大小为1.09g，比直接存储小了80m。

used_memory:1170356864
used_memory_human:1.09g
used_memory_rss:1190223872
used_memory_rss_human:1.11g
used_memory_peak:1749456304
used_memory_peak_human:1.63g
used_memory_peak_perc:66.90%
used_memory_overhead:33759246
used_memory_startup:765664
used_memory_dataset:1136597618
used_memory_dataset_perc:97.18%
total_system_memory:8365256704
total_system_memory_human:7.79g

六、进行hget的压力测试

 redis-benchmark -h 127.0.0.1 -p 6379 -c 1000 -n 10000 -t hget myhash rand_int rand_int rand_int 
====== myhash rand_int rand_int rand_int ======
 10000 requests completed in 0.22 seconds
 1000 parallel clients
 3 bytes payload
 keep alive: 1 
46511.63 requests per second

七、总结

可见，当存储量特别大的时候，可以将key进行hash分散处理，可以减少存储内存。

并且当key的数量很大的时候，redis取值性能还是很高的。

补充：redis 单key值过大 优化方式

redis使用过程中经常会有各种大key的情况， 比如：

1： 单个简单的key存储的value很大

2： hash， set，zset，list 中存储过多的元素（以万为单位）

由于redis是单线程运行的，如果一次操作的value很大会对整个redis的响应时间造成负面影响，所以，业务上能拆则拆，下面举几个典型的分拆方案。

1、单个简单的key存储的value很大

1.1、 改对象需要每次都整存整取

可以尝试将对象分拆成几个key-value， 使用multiget获取值，这样分拆的意义在于分拆单次操作的压力，将操作压力平摊到多个redis实例中，降低对单个redis的io影响；

1.2、该对象每次只需要存取部分数据

可以像第一种做法一样，分拆成几个key-value， 也可以将这个存储在一个hash中，每个field代表一个具体的属性，使用hget,hmget来获取部分的value，使用hset，hmset来更新部分属性

2、 hash， set，zset，list 中存储过多的元素

类似于场景一种的第一个做法，可以将这些元素分拆。

以hash为例，原先的正常存取流程是 hget(hashkey, field) ; hset(hashkey, field, value)

现在，固定一个桶的数量，比如 10000， 每次存取的时候，先在本地计算field的hash值，模除 10000， 确定了该field落在哪个key上。

newhashkey = hashkey + (*hash*(field) % 10000）;  
hset (newhashkey, field, value) ; 
hget(newhashkey, field)

set, zset, list 也可以类似上述做法.

但有些不适合的场景，比如，要保证 lpop 的数据的确是最早push到list中去的，这个就需要一些附加的属性，或者是在 key的拼接上做一些工作（比如list按照时间来分拆）。

以上为个人经验，希望能给大家一个参考，也希望大家多多支持。如有错误或未考虑完全的地方，望不吝赐教。