阿里云的redis规范( 二 ) _redis

noeviction：不会剔除任何数据，拒绝所有写入操作并返回客户端错误信息"(error) OOM command not allowed when used memory"，此时Redis只响应读操作。
bigkey【强制】：拒绝bigkey(防止网卡流量、慢查询)
string类型控制在10KB以内，hash、list、set、zset元素个数不要超过5000 。
反例：一个包含200万个元素的list 。
非字符串的bigkey，不要使用del删除，使用hscan、sscan、zscan方式渐进式删除，同时要注意防止bigkey过期时间自动删除问题(例如一个200万的zset设置1小时过期，会触发del操作，造成阻塞，而且该操作不会出现在慢查询中(latency可查))
一、什么是bigkey
在Redis中，一个字符串最大512MB，一个二级数据结构（例如hash、list、set、zset）可以存储大约40亿个(2^32-1)个元素，但实际上中如果下面两种情况，我就会认为它是bigkey 。

字符串类型：它的big体现在单个value值很大，一般认为超过10KB就是bigkey 。
非字符串类型：哈希、列表、集合、有序集合，它们的big体现在元素个数太多。

二、危害
bigkey可以说就是Redis的老鼠屎，具体表现在：
1.内存空间不均匀：这样会不利于集群对内存的统一管理，存在丢失数据的隐患。
2.超时阻塞：由于Redis单线程的特性，操作bigkey的通常比较耗时，也就意味着阻塞Redis可能性越大，这样会造成客户端阻塞或者引起故障切换，它们通常出现在慢查询中。
例如，在Redis发现了这样的key，你就等着DBA找你吧。。
127.0.0.1:6379> hlen big:hash(integer) 2000000127.0.0.1:6379> hgetall big:hash1) "a"2) "1"此处省略400万行3.网络拥塞：
bigkey也就意味着每次获取要产生的网络流量较大，假设一个bigkey为1MB，客户端每秒访问量为1000，那么每秒产生1000MB的流量，对于普通的千兆网卡(按照字节算是128MB/s)的服务器来说简直是灭顶之灾，而且一般服务器会采用单机多实例的方式来部署，也就是说一个bigkey可能会对其他实例造成影响，其后果不堪设想。
4.过期删除：
有个bigkey，它安分守己（只执行简单的命令，例如hget、lpop、zscore等），但它设置了过期时间，当它过期后，会被删除，如果没有使用Redis 4.0的过期异步删除(lazyfree-lazy-expire yes)，就会存在阻塞Redis的可能性，而且这个过期删除不会从主节点的慢查询发现（因为这个删除不是客户端产生的，是内部循环事件，可以从latency命令中获取或者从slave节点慢查询发现）。
5.迁移困难：
当需要对bigkey进行迁移（例如Redis cluster的迁移slot），实际上是通过migrate命令来完成的，migrate实际上是通过dump + restore + del三个命令组合成原子命令完成，如果是bigkey，可能会使迁移失败，而且较慢的migrate会阻塞Redis 。
三、怎么产生的？
一般来说，bigkey的产生都是由于程序设计不当，或者对于数据规模预料不清楚造成的，来看几个：
(1) 社交类：粉丝列表，如果某些明星或者大v不精心设计下，必是bigkey 。
(2) 统计类：例如按天存储某项功能或者网站的用户集合，除非没几个人用，否则必是bigkey 。
(3) 缓存类：将数据从数据库load出来序列化放到Redis里，这个方式非常常用，但有两个地方需要注意，第一，是不是有必要把所有字段都缓存，第二，有没有相关关联的数据。
例如我之前遇到过一个例子，该同学将某明星一个专辑下所有视频信息都缓存一个巨大的json中，造成这个json达到6MB，后来这个明星发了一个官宣。。。这个我就不多说了，领盒饭去吧。
四、如何发现
1.redis-cli --bigkeys
redis-cli提供了--bigkeys来查找bigkey，例如下面就是一次执行结果：
-------- summary -------Biggest string found 'user:1' has 5 bytesBiggest list found 'taskflow:175448' has 97478 itemsBiggest set found 'redisServerSelect:set:11597' has 49 membersBiggest hash found 'loginUser:t:20180905' has 863 fieldsBiggest zset found 'hotkey:scan:instance:zset' has 3431 members40 strings with 200 bytes (00.00% of keys, avg size 5.00)2747619 lists with 14680289 items (99.86% of keys, avg size 5.34)2855 sets with 10305 members (00.10% of keys, avg size 3.61)13 hashs with 2433 fields (00.00% of keys, avg size 187.15)830 zsets with 14098 members (00.03% of keys, avg size 16.99)可以看到--bigkeys给出了每种数据结构的top 1 bigkey，同时给出了每种数据类型的键值个数以及平均大小。
--bigkeys对问题的排查非常方便，但是在使用它时候也有几点需要注意。