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的问题。