likes
comments
collection
share

Redis使用常见问题注意

作者站长头像
站长
· 阅读数 18

Redis是市面上最经典的一款缓存数据库,在抗高并发流量的时候基本上都会使用Redis。Redis的功能非常强大,但是一定程度上可能由于他的强大,而过度使用甚至滥用,最终导致了严重的线上故障.. 后果...

最近团队中在使用Redis时存储大Value导致宽带被打满的问题... 对个人也造成了一定的影响,Redis的使用注意事项还需要再回顾下,希望大家能引以为戒,正确的使用Redis。

最常见的就是大Key与热点Key问题;

不当使用的影响

一句话就是导致Redis不可用,业务应用也会跟着受到影响,进而可能产生故障,因此要避免不当使用;

1、大Key导致内存问题、宽度问题、RT问题,以及影响应用,应用服务变慢,甚至被拖垮;

2、大Key可能导致某个分片的数据内存使用率远超其他分片,资源利用不均,访问到这个分片的请求都会报错,通过扩容也无法解决问题。

3、热Key可能导致被限流,从而某个Key的访问不符合预期,在某些业务场景下导致资损.. 热Key导致缓存击穿,从而影响业务

使用注意

1. key设置的数据值大于10KB被认做大Key;不要超过

带宽 = QPS * Value大小; 阿里云带宽代理模式下最大为2GB/s,如果value设置了1MB的大小,那么理论上只能抗2048 QPS,试想下一个缓存只能抗2000 QPS,那这个缓存意义不大了。

2. 复杂的数据结构容易产生大Key,集合元素个数不要超过1000个;

建议集合类型的结构,数量不要超过10000个; QPS一定做好限制。 不要使用hgetAll, smemebers等操作。

3. 高并发下用单个Key进行计数,会被限流;

比如对高并发流量进行计数,但是计数的Key是同一个,并且每个请求加1; 建议计数前可以自己先汇总下(一次记30个请求),并且计数的Key可以设置多个count_1,count_2...,最后再进行汇总下;

4. 不要使用PubSub订阅

PubSub如果订阅数过多极易产生问题,如果有发布订阅的需求,最好走MQ,而不是直接使用Redis来实现。 一定要用的话,发布订阅下的Key大小控制1KB以下。

5. Key设置规范;

Redis在搜索的时候只能右模糊匹配,设置左前缀的话,可能数据都会落到某个内存分片上,导致Redis的内存利用率过高,影响整体使用。

一个 key 需要带以下维度:业务、key 用途、变量等,各个维度使用,使用分隔符进行分隔

6. 一个主库不能设置太多的从库

会导致主库的IO增加,影响使用;

禁止的操作

  • 严禁使用 Keys,属于 O(N)操作,会阻塞其他正常命令,在 cluster 上,会是灾难性的操作。
  • 严禁使用 Flush,flush 命令会清空所有数据,属于高危操作。
  • 严禁不设置范围的批量操作,如hgetAll,mget等
  • 禁止长时间 monitor
  • 禁用事务,如无大的必要,建议捕获异常进行回滚;

最后

说下个人的教训,在工作的时候,有同事问我Redis能存储的value最大为多少; 我先回复value过大可能产生阻塞,然后说Redis的Value最大可以设置512MB。

可能同事在想最多可以存储512MB,那我存个几M也不算太大,确实521MB和几MB对比,几MB不大,但是第二天早上电话报警带宽占满,应用由于读数据超时线程阻塞不提供服务,然后产生了线上故障。

最后复盘的时候说这个原因由于我给出了最大为512MB,从而误导了技术方案的设计...(我...)

总结:

  • Redis功能非常强大毋庸置疑,然后也是应用中基本必备的一个组件;
  • 但是不要因为它的功能强大,就滥用能力。 就如同人可以在极限环境下生存,但不要把人一直放在一个极限环境下。
  • 使用Redis的时候一定要注意正确的使用,牢记大Key和热点Key的问题。
转载自:https://juejin.cn/post/7158997731678093326
评论
请登录