本篇文章为大家展示了复述,数据库中值过大如何解决,内容简明扼要并且容易理解,绝对能使你眼前一亮,通过这篇文章的详细介绍希望你能有所收获。
复述,大关键问题
数据量大的关键,由于其数据大小远大于其他钥匙,导致经过分片之后,某个具体存储这个大关键的实例内存使用量远大于其他实例,造成内存不足,拖累整个集群的使用.big关键在不同业务上,通常体现为不同的数据,比如:
论坛中的大型持久盖楼活动;
<李>聊天室系统中热门聊天室的消息列表;
带来的问题
bigkey通常会导致内存空间不平衡,超时阻塞,如果关键较大,复述,又是单线程,操作bigkey比较耗时,那么阻塞复述的可能性增大。每次获取bigkey的网络流量较大,假设一个bigkey为1 mb,每秒访问量为1000,那么每秒产生1000 mb的流量,对于普通千兆网卡,按照字节算128 m/S的服务器来说可能扛不住。而且一般服务器采用单机多实例方式来部署,所以还可能对其他实例造成影响。
如果是集群模式下,无法做到负载均衡,导致请求倾斜到某个实例上,而这个实例的每秒会比较大,内存占用也较多;对于复述,单线程模型又容易出现CPU瓶颈,当内存出现瓶颈时,只能进行纵向库容,使用更牛逼的服务器。
<李>涉及到大关键的操作,尤其是使用hgetall, lrange,得到hmget等操作时,网卡可能会成为瓶颈,也会到导致堵塞其它操作,每秒就有可能出现突降或者突升的情况,趋势上看起来十分不平滑,严重时会导致应用程序连不上,实例或者集群在某些时间段内不可用的状态。
<李>假如这个关键需要进行删除操作,如果直接进行DEL操作,被操作的实例会被阻塞住,导致无法响应应用的请求,而这个块的时间会随着关键的变大而变长。
什么是大关键
字符串类型:一般认为超过10 k的就是bigkey,但是这个值和具体的行动相关。
<李>非字符串类型:体现在哈希,列表,集合类型元素过多。
寻找大关键
redis-cli自带——bigkeys。
获取生产复述的rdb文件,通过rdbtools分析rdb生成csv文件,再导入MySQL或其他数据库中进行分析统计,根据size_in_bytes统计bigkey
通过python脚本,迭代扫描键,每1000次扫描,对扫描出来的钥匙进行类型判断,例如:弦长度大于10 k,列表长度大于10240认为是大bigkeys
其他第三方工具,例如:redis-rdb-cli
优化大关键
优化大关键的原则就是字符串减少字符串长度,列表,散列,设置,zset等减少成员数。
字符串类型的大钥匙,建议不要存入复述,用文档型数据库MongoDB代替或者直接缓存到CDN上等方式优化。有些关键不只是访问量大,数据量也很大,这个时候就要考虑这个关键使用的场景,存储在复述,集群中是否是合理的,是否使用其他组件来存储更合适;如果坚持要用复述来存储,可能考虑迁移出集群,采用一主一备(或1主多备)的架构来存储。
单个简单的关键存储的价值很大
该对象需要每次都整存整取:可以尝试将对象分拆成几个键值,使用multiGet获取值,这样分拆的意义在于分拆单次操作的压力,将操作压力平摊到多个复述,实例中,降低对单个复述的IO影响;
该对象每次只需要存取部分数据:可以像第一种做法一样,分拆成几个键值,也可以将这个存储在一个散列中,每个领域代表一个具体的属性,使用hget, hmget来获取部分的价值,使用hset, hmset来更新部分属性。
哈希,集,zset,列表中存储过多的元素
可以将这些元素分拆,以希为例,原先的正常存取流程是hget (hashKey、字段);hset (hashKey、字段值)
现在,固定一个桶的数量,比如10000年每次存取的时候,先在本地计算的哈希值,模除10000年,确定了该领域落在哪个关键上。
