深入解读Redis 开发规范，别只会 set、get！

来源：阿飞的博客

jianshu.com/p/932b69c8aa2f

Key命名设计：可读性、可管理性、简介性

规范建议使用冒号即:进行分割拼接，因为很多Redis客户端是根据冒号分类的，如下图所示：

Value设计：拒绝大容量key

规范建议String类型的Value控制在10KB以内，这是因为Redis随着Value不断增长，在超过10KB后，会产生一个非常奇妙的性能拐点。如下图所示：

假设内网带宽是百兆网卡，即100MB，假设你的Redis中有一个大Key的Value长度是10KB，并且这个Key的QPS是1W，那么这一个Key就会把带宽打满：10KB*10000=100MB。那么你的网速就像卡顿，对应能影响极大。

控制Key的生命周期：设定合理过期时间

尽可能对每一个Key都设置过期时间，这个是非常有益处的。否则，日积月累，你的Redis集群中有N多个key和value。这时候你可能无法分清哪些数据哪些是有价值的，那些已经成为垃圾数据。设置过期时间就能解决这个问题。

时间复杂度为O(n)的命令需要注意N的数量

这个建议的意思是，以List类型为例，LINDEX、LREM等命令的时间复杂度就是O(n)。也就是说，随着List中元素数量越来越多，这些命令的性能越来越差。而Redis又是单线程的，如果出现一个慢命令，会导致系统卡顿，这是使用Redis的大忌。

JDK8为什么要对HashMap进行链条冲突优化？当entry数量不少于64时，如果冲突链表长度达到8，就会将其转成红黑树。因为链表长度越长，性能会越来越差。

禁用命令

这些命令应该在搭建Redis环境的时候就要禁用掉（在config配置文件中通过rename-command禁用）。FLUSHDB和FLUSHALL这两个命令会清空数据，后果可想而知。

至于KEYS命令，还记得那个由于使用这个命令导致几百万损失的案例吗？

这是个鲜血淋漓的列子，我们一定会要事先做好代码规范，提前避免。

推荐使用批量操作提升操作效率

批量命令主要分为两类，原生命令和非原生命令：

• 原生命令包括：例如mget、mset、hmget、hmset、LPUSH key value集合等。
• 非原生命令包括：Pipeline。

合理使用这些命令对操作性能提升是极其巨大的，尤其在单机Redis或者Sentinel模式下。因为这两种架构不涉及跨Slot，Redis集群性能也有提升，但是使用会受到一些限制，例如不支持跨Slot的操作。

当然批量虽好，但不要贪多。俗话说的好，贪多嚼不烂。一般不要超过1000，具体限制还与操作数据大小有关。

monitor命令控制使用时间

monitor命令一般是用来观察redis服务端都在执行哪些命令并实时输出，例如在其他redis-cli中执行两个set命令，在monitor中监控结果如下：

afeiMacBook-Pro:redis-3.2.11 afei$ src/redis-cli monitor
OK
1573915193.053188 [0 127.0.0.1:55357] "COMMAND"
1573915197.087383 [0 127.0.0.1:55357] "set" "name" "afei"
1573915217.938838 [0 127.0.0.1:55357] "set" "公 众 号" "阿飞的博客"

之所以规范建议控制monitor命令的使用时间，是因为随着monitor命令执行时间越来越长，会导致越来越多的数据积压在输出缓冲区，从而导致输出缓冲区占用内存越来越大。而且，这种影响会由于Redis并发越高，而更加放大。关于这个问题，美团有一个很经典的案例，感兴趣的同学可以搜索关键词：“美团在REDIS上踩过的一些坑-3.REDIS内存占用飙升 ”。

写在最后

总而言之，任何一门技术都有利有弊，技术的世界里没有绝对的，只有更合适的技术。所以，我们需要先对生产环境非常熟悉，然后知道它所擅长的和它的弱点，再结合实际情况才能设计出更合理的架构！