Redis Big Key问题
数据量大的 key ，由于其数据大小远大于其他key，导致经过分片之后，某个具体存储这个 big key 的实例内存使用量远大于其他实例，造成内存不足，拖累整个集群的使用。big key 在不同业务上，通常体现为不同的数据，比如：
- 论坛中的大型持久盖楼活动；
- 聊天室系统中热门聊天室的消息列表；
带来的问题
bigkey 通常会导致内存空间不平衡，超时阻塞，如果 key 较大，redis 又是单线程，操作 bigkey 比较耗时，那么阻塞 redis 的可能性增大。每次获取 bigKey 的网络流量较大，假设一个 bigkey 为 1MB,每秒访问量为 1000，那么每秒产生 1000MB 的流量，对于普通千兆网卡，按照字节算 128M/S 的服务器来说可能扛不住。而且一般服务器采用单机多实例方式来部署，所以还可能对其他实例造成影响。
- 如果是集群模式下，无法做到负载均衡，导致请求倾斜到某个实例上，而这个实例的QPS会比较大，内存占用也较多；对于Redis单线程模型又容易出现CPU瓶颈，当内存出现瓶颈时，只能进行纵向库容，使用更牛逼的服务器。
- 涉及到大key的操作，尤其是使用hgetall、lrange、get、hmget 等操作时，网卡可能会成为瓶颈，也会到导致堵塞其它操作，qps 就有可能出现突降或者突升的情况，趋势上看起来十分不平滑，严重时会导致应用程序连不上，实例或者集群在某些时间段内不可用的状态。
- 假如这个key需要进行删除操作，如果直接进行DEL 操作，被操作的实例会被Block住，导致无法响应应用的请求，而这个Block的时间会随着key的变大而变长。
什么是 big key
- 字符串类型：一般认为超过 10k 的就是 bigkey，但是这个值和具体的 OPS 相关。
- 非字符串类型：体现在哈希，列表，集合类型元素过多。
寻找big key
redis-cli自带--bigkeys。
$ redis-cli -p 999 --bigkeys -i 0.1 #Scanning the entire keyspace to find biggest keys as well as average sizes per key type. You can use -i 0.1 to sleep 0.1 sec per 100 SCAN commands (not usually needed).
获取生产Redis的rdb文件，通过rdbtools分析rdb生成csv文件，再导入MySQL或其他数据库中进行分析统计，根据size_in_bytes统计bigkey
$ git clone https://github.com/sripathikrishnan/redis-rdb-tools $ cd redis-rdb-tools $ sudo python setup.py install $ rdb -c memory dump-10030.rdb > memory.csv
通过python脚本，迭代scan key，每次scan 1000，对扫描出来的key进行类型判断，例如：string长度大于10K，list长度大于10240认为是big bigkeys
其他第三方工具，例如：redis-rdb-cli
优化big key
优化big key的原则就是string减少字符串长度，list、hash、set、zset等减少成员数。
string类型的big key，建议不要存入redis，用文档型数据库MongoDB代替或者直接缓存到CDN上等方式优化。有些 key 不只是访问量大，数据量也很大，这个时候就要考虑这个 key 使用的场景，存储在redis集群中是否是合理的，是否使用其他组件来存储更合适；如果坚持要用 redis 来存储，可能考虑迁移出集群，采用一主一备（或1主多备）的架构来存储。
单个简单的key存储的value很大
该对象需要每次都整存整取: 可以尝试将对象分拆成几个key-value， 使用multiGet获取值，这样分拆的意义在于分拆单次操作的压力，将操作压力平摊到多个redis实例中，降低对单个redis的IO影响； 该对象每次只需要存取部分数据: 可以像第一种做法一样，分拆成几个key-value，也可以将这个存储在一个hash中，每个field代表一个具体的属性，使用hget,hmget来获取部分的value，使用hset，hmset来更新部分属性。
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按照时间来分拆）。
到此这篇关于Redis Value过大问题(键值过大)的文章就介绍到这了,更多相关Redis 键值过大内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！
