1. key名设计
(1)【建议】: 可读性和可管理性
以业务名(或数据库名)为前缀(防止key冲突)，用冒号分隔，比如业务名:表名:id
(2)【建议】：简洁性
保证语义的前提下，控制key的长度，当key较多时，内存占用也不容忽视，例如：
(3)【强制】：不要包含特殊字符
反例：包含空格、换行、单双引号以及其他转义字符
2. value设计
(1)【强制】：拒绝bigkey(防止网卡流量、慢查询)
string类型控制在10KB以内，hash、list、set、zset元素个数不要超过5000。
反例：一个包含200万个元素的list。
非字符串的bigkey，不要使用del删除，使用hscan、sscan、zscan方式渐进式删除，同时要注意防止bigkey过期时间自动删除问题(例如一个200万的zset设置1小时过期，会触发del操作，造成阻塞，而且该操作不会不出现在慢查询中(latency可查))，查找方法和删除方法
(2)【推荐】：选择适合的数据类型。
例如：实体类型(要合理控制和使用数据结构内存编码优化配置,例如ziplist，但也要注意节省内存和性能之间的平衡)
反例：
正例:
(3)【推荐】：控制key的生命周期，redis不是垃圾桶。
建议使用expire设置过期时间(条件允许可以打散过期时间，防止集中过期)，不过期的数据重点关注idletime。
1.【推荐】 O(N)命令关注N的数量
例如hgetall、lrange、smembers、zrange、sinter等并非不能使用，但是需要明确N的值。有遍历的需求可以使用hscan、sscan、zscan代替。
2.【推荐】：禁用命令
禁止线上使用keys、flushall、flushdb等，通过redis的rename机制禁掉命令，或者使用scan的方式渐进式处理。
3.【推荐】合理使用select
redis的多数据库较弱，使用数字进行区分，很多客户端支持较差，同时多业务用多数据库实际还是单线程处理，会有干扰。
4.【推荐】使用批量操作提高效率
原生命令：例如mget、mset。
非原生命令：可以使用pipeline提高效率。
但要注意控制一次批量操作的元素个数(例如500以内，实际也和元素字节数有关)。
注意两者不同：
5.【建议】Redis事务功能较弱，不建议过多使用
Redis的事务功能较弱(不支持回滚)，而且集群版本(自研和官方)要求一次事务操作的key必须在一个slot上(可以使用hashtag功能解决)
6.【建议】Redis集群版本在使用Lua上有特殊要求：
1.所有key都应该由 KEYS 数组来传递，redis.call/pcall 里面调用的redis命令，key的位置，必须是KEYS array, 否则直接返回
error，"-ERR bad lua script for redis cluster, all the keys that the script uses should be passed using the KEYS array"
2.所有key，必须在1个slot上，否则直接返回
error, "-ERR eval/evalsha command keys must in same slot"
7.【建议】必要情况下使用monitor命令时，要注意不要长时间使用。
1.【推荐】
避免多个应用使用一个Redis实例
正例：不相干的业务拆分，公共数据做服务化。
2.【推荐】
使用带有连接池的数据库，可以有效控制连接，同时提高效率：
3.【建议】
高并发下建议客户端添加熔断功能(例如netflix hystrix)
4.【推荐】
设置合理的密码，如有必要可以使用SSL加密访问（阿里云Redis支持）
5.【建议】
根据自身业务类型，选好maxmemory-policy(最大内存淘汰策略)，设置好过期时间。
默认策略是volatile-lru，即超过最大内存后，在过期键中使用lru算法进行key的剔除，保证不过期数据不被删除，但是可能会出现OOM问题。
其他策略如下：
allkeys-lru：根据LRU算法删除键，不管数据有没有设置超时属性，直到腾出足够空间为止。
allkeys-random：随机删除所有键，直到腾出足够空间为止。
volatile-random:随机删除过期键，直到腾出足够空间为止。
volatile-ttl：根据键值对象的ttl属性，删除最近将要过期数据。如果没有，回退到noeviction策略。
noeviction：不会剔除任何数据，拒绝所有写入操作并返回客户端错误信息"(error) OOM command not allowed when used memory"，此时Redis只响应读操作。
【强制】：拒绝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。
二、危害
bigkey可以说就是Redis的老鼠屎，具体表现在：
1.内存空间不均匀：这样会不利于集群对内存的统一管理，存在丢失数据的隐患。
2.超时阻塞：由于Redis单线程的特性，操作bigkey的通常比较耗时，也就意味着阻塞Redis可能性越大，这样会造成客户端阻塞或者引起故障切换，它们通常出现在慢查询中。
例如，在Redis发现了这样的key，你就等着DBA找你吧。。
127.0.0.1:6379> hlen big:hash(integer) 2000000 127.0.0.1:6379> hgetall big:hash 1) "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 bytes Biggest list found 'taskflow:175448' has 97478 items Biggest set found 'redisServerSelect:set:11597' has 49 members Biggest hash found 'loginUser:t:20180905' has 863 fields Biggest zset found 'hotkey:scan:instance:zset' has 3431 members 40 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对问题的排查非常方便，但是在使用它时候也有几点需要注意。
再来看一个场景：
你好，麻烦帮我查一下Redis里大于10KB的所有key
您好，帮忙查一下Redis中长度大于5000的hash key
是不是发现用--bigkeys不行了（当然如果改源码也不是太难），但有没有更快捷的方法，Redis提供了debug object ${key}命令获取键值的相关信息：
127.0.0.1:6379> hlen big:hash (integer) 5000000 127.0.0.1:6379> debug object big:hash Value at:0x7fda95b0cb20 refcount:1 encoding:hashtable serializedlength:87777785 lru:9625559 lru_seconds_idle:2 (1.08s)
其中serializedlength表示key对应的value序列化之后的字节数，当然如果是字符串类型，完全看可以执行strlen，例如：
127.0.0.1:6379> strlen key (integer) 947394
这样你就可以用scan + debug object的方式遍历Redis所有的键值，找到你需要阈值的数据了。
但是在使用debug object时候一定要注意以下几点：
(1) debug object bigkey本身可能就会比较慢，它本身就会存在阻塞Redis的可能
(2) 建议在从节点执行
(3) 建议在节点本地执行
(4) 如果不关系具体字节数，完全可以使用scan + strlen|hlen|llen|scard|zcard替代，他们都是o(1)
3 memory usage
上面的debug object可能会比较危险、而且不太准确（序列化后的长度），有没有更准确的呢？Redis 4.0开始提供memory usage命令可以计算每个键值的字节数（自身、以及相关指针开销，具体的细节后面有文章会分析），例如下面是一次执行结果：
127.0.0.1:6379> memory usage big:hash (integer) 318663444
下面我们来对比就可以看出来，当前系统就一个key，总内存消耗是400MB左右，memory usage相比debug object还是要精确一些的。
127.0.0.1:6379> dbsize (integer) 1 127.0.0.1:6379> hlen big:hash (integer) 5000000 #约300MB 127.0.0.1:6379> memory usage big:hash (integer) 318663444 #约85MB 127.0.0.1:6379> debug object big:hash Value at:0x7fda95b0cb20 refcount:1 encoding:hashtable serializedlength:87777785 lru:9625814 lru_seconds_idle:9 (1.06s) 127.0.0.1:6379> info memory # Memory used_memory_human:402.16M
如果你使用Redis 4.0+，你就可以用scan + memory usage(pipeline)了，而且很好的一点是,memory不会执行很慢，当然依然是建议从节点 + 本地 。
4.客户端
上面三种方式都有一个问题，就是马后炮，如果想很实时的找到bigkey，一方面你可以试试修改Redis源码，还有一种方式就是可以修改客户端，以jedis为例，可以在关键的出入口加上对应的检测机制，例如以Jedis的获取结果为例子：
protected Object readProtocolWithCheckingBroken() {
Object o = null;
try {
o = Protocol.read(inputStream);
return o;
}catch(JedisConnectionException exc) {
UsefulDataCollector.collectException(exc, getHostPort(), System.currentTimeMillis());
broken = true;
throw exc;
}finally {
if(o != null) {
if(o instanceof byte[]) {
byte[] bytes = (byte[]) o;
if (bytes.length > threshold) {
// 做很多事情，例如用ELK完成收集和展示
}
}
}
}
}
5.监控报警
bigkey的大操作，通常会引起客户端输入或者输出缓冲区的异常，Redis提供了info clients里面包含的客户端输入缓冲区的字节数以及输出缓冲区的队列长度，可以重点关注下：
127.0.0.1:6379> info clients client_longest_output_list:xxxxxc lient_biggest_input_buf:xxxxx
如果想知道具体的客户端，可以使用client list命令来查找
redis-cli client list id=3 addr=127.0.0.1:58500 fd=8 name= age=3978 idle=25 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=26263554 events=r cmd=hgetall
6.改源码
这个其实也是能做的，但是各方面成本比较高，对于一般公司来说不适用。
我个人的最佳实践就是：
(1) Redis端与客户端相结合：--bigkeys临时用、scan长期做排除隐患（尽可能本地化）、客户端实时监控。
(2) 监控报警要跟上
(3) debug object尽量少用
(4) 所有数据平台化
(5) 要和开发同学强调bigkey的危害
五、如何删除
如果发现了bigkey，而且确认是垃圾是不是直接del就可以了，来看一组数据：
可以看到对于string类型，删除速度还是可以接受的。但对于二级数据结构，随着元素个数的增长以及每个元素字节数的增大，删除速度会越来越慢，存在阻塞Redis的隐患。所以在删除它们时候建议采用渐进式的方式来完成：hscan、ltrim、sscan、zscan。
如果你使用Redis 4.0+，一条异步删除unlink就解决，就可以忽略下面内容。
1.字符串：
一般来说，对于string类型使用del命令不会产生阻塞。
del bigkey
2.hash
使用hscan命令，每次获取部分(例如100个)field-value，在利用hdel删除每个field(为了快速可以使用pipeline)。public void delBigHash(String bigKey) {
Jedis jedis = new Jedis("127.0.0.1", 6379);
// 游标
String cursor = "0";
while(true) {
ScanResult<Map.Entry<String, String>> scanResult = jedis.hscan(bigKey, cursor, new ScanParams().count(100));
// 每次扫描后获取新的游标
cursor = scanResult.getStringCursor();
// 获取扫描结果
List<Entry<String, String>> list = scanResult.getResult();
if(list == null || list.size() == 0) {
continue;
}
String[] fields = getFieldsFrom(list);
// 删除多个field
jedis.hdel(bigKey, fields);
// 游标为0时停止
if(cursor.equals("0")) {
break;
}
}
// 最终删除key
jedis.del(bigKey);
}
/**
* 获取field数组
*/
private String[] getFieldsFrom(List<Entry<String, String>> list) {
List<String> fields = new ArrayList<String>();
for (Entry<String, String> entry : list) {
fields.add(entry.getKey());
}
return fields.toArray(new String[fields.size()]);
}
3.list
Redis并没有提供lscan这样的API来遍历列表类型，但是提供了ltrim这样的命令可以渐进式的删除列表元素，直到把列表删除。
public void delBigList(String bigKey) {
Jedis jedis = new Jedis("127.0.0.1", 6379);
long llen = jedis.llen(bigKey);
int counter = 0;
int left = 100;
while(counter < llen) {
// 每次从左侧截掉100个
jedis.ltrim(bigKey, left, llen);
counter += left;
}
// 最终删除key
jedis.del(bigKey);
}
4.set
使用sscan命令，每次获取部分(例如100个)元素，在利用srem删除每个元素。
ublic void delBigSet(String bigKey) {
Jedis jedis = new Jedis("127.0.0.1", 6379);
// 游标
String cursor = "0";
while(true) {
ScanResult<String> scanResult = jedis.sscan(bigKey, cursor, new ScanParams().count(100));
// 每次扫描后获取新的游标
cursor = scanResult.getStringCursor();
// 获取扫描结果
List<String> list = scanResult.getResult();
if(list == null || list.size() == 0) {
continue;
}
jedis.srem(bigKey, list.toArray(new String[list.size()]));
// 游标为0时停止
if(cursor.equals("0")) {
break;
}
}
// 最终删除key
jedis.del(bigKey);
}
5.sorted set
使用zscan命令，每次获取部分(例如100个)元素，在利用zremrangebyrank删除元素。public void delBigSortedSet(String bigKey) {
long startTime = System.currentTimeMillis();
Jedis jedis = new Jedis(HOST, PORT);
// 游标
String cursor = "0";
while(true) {
ScanResult<Tuple> scanResult = jedis.zscan(bigKey, cursor, new ScanParams().count(100));
// 每次扫描后获取新的游标
cursor = scanResult.getStringCursor();
// 获取扫描结果
List<Tuple> list = scanResult.getResult();
if(list == null || list.size() == 0) {
continue;
}
String[] members = getMembers(list);
jedis.zrem(bigKey, members);
// 游标为0时停止
if(cursor.equals("0")) {
break;
}
}
// 最终删除key
jedis.del(bigKey);
}
public void delBigSortedSet2(String bigKey) {
Jedis jedis = new Jedis(HOST, PORT);
long zcard = jedis.zcard(bigKey);
int counter = 0;
int incr = 100;
while(counter < zcard) {
jedis.zremrangeByRank(bigKey, 0, 100);
// 每次从左侧截掉100个
counter += incr;
}
// 最终删除key
jedis.del(bigKey);
}
六、如何优化
1.拆
big list： list1、list2、...listN
big hash：可以做二次的hash，例如hash%100
日期类：key20190320、key20190321、key_20190322。
2.本地缓存
减少访问redis次数，降低危害，但是要注意这里有可能因此本地的一些开销（例如使用堆外内存会涉及序列化，bigkey对序列化的开销也不小）
7、总结：
由于开发人员对Redis的理解程度不同，在实际开发中出现bigkey在所难免，重要的能通过合理的检测机制及时找到它们，进行处理。作为开发人员应该在业务开发时不能将Redis简单暴力的使用，应该在数据结构的选择和设计上更加合理，例如出现了bigkey，要思考一下可不可以做一些优化(例如二级索引)尽量的让这些bigkey消失在业务中，如果bigkey不可避免，也要思考一下要不要每次把所有元素都取出来(例如有时候仅仅需要hmget，而不是hgetall)，删除也是一样，尽量使用优雅的方式来处理。
京公网安备 11010802035086号