redis中的大key和unlink操作
1、什么是 bigkey
Key 本身的数据量过大：一个 String 类型的 Key，它的值为 5 MB。
Key 中的成员数过多：一个 ZSET 类型的 Key，它的成员数量为 10,000 个。
Key 中成员的数据量过大：一个 Hash 类型的 Key，它的成员数量虽然只有 1,000 个但这些成员的 Value（值）总大小为 100 MB。
2、bigkey 的影响
集群架构下，某个数据分片的内存使用率远超其他数据分片，无法使数据分片的内存资源达到均衡
如果 bigkey 一直在增长，会导致 Redis 内存 OOM，影响读写性能
因为 Redis 是单线程的，对 bigkey 的增删改操作，会导致超时，甚至阻塞服务
对大 Key 执行删除操作，易造成主库较长时间的阻塞，进而可能引发同步中断或主从切换
3、如何避免 bigkey
如果是 hash 的话，通过一定规则拆分到不同 hash 中，特别是在集群中很有效果
堆积大量过期数据会造成大 Key 的产生，例如在 HASH 数据类型中以增量的形式不断写入大量数据而忽略了数据的时效性。可以通过定时任务的方式对失效数据进行清理。
对大 Key 进行直接删除
4、如何查看 bigkey
可以通过 Redis 客户端命令查看：

redis-cli --bigkeys

Scanning the entire keyspace to find biggest keys as well as

average sizes per key type. You can use -i 0.1 to sleep 0.1 sec

per 100 SCAN commands (not usually needed).

[00.00%] Biggest string found so far '"frontLastPullSysMsgId:1257:964350"' with 5 bytes
[00.00%] Biggest string found so far '"exam_data:1233:913172:39017:140692"' with 8885 bytes
[00.01%] Biggest string found so far '"exam_data:319:877777:14274:126728"' with 14875 bytes
[00.03%] Biggest list found so far '"live_merge:154_159588"' with 9 items
[00.06%] Biggest string found so far '"exam_data:319:1101505:52328:151653"' with 19125 bytes
[00.07%] Biggest hash found so far '"timer_ids:company_id:1134:sys_id:5"' with 11 fields
[00.17%] Biggest string found so far '"exam_data:908:644980:22627:146279"' with 31320 bytes
[00.30%] Biggest hash found so far '"timer_ids:company_id:927:sys_id:5"' with 130 fields
[00.73%] Biggest hash found so far '"timer_ids:company_id:264:sys_id:2"' with 551 fields
[01.19%] Biggest string found so far '"exam_data:973:693508:33936:128891"' with 40643 bytes
[03.09%] Biggest hash found so far '"timer_ids:company_id:1183:sys_id:5"' with 625 fields
[03.29%] Biggest hash found so far '"timer_ids:company_id:1183:sys_id:2"' with 1410 fields
[06.39%] Biggest string found so far '"exam_data:301:104065:51535:165675"' with 127069 bytes
[06.75%] Biggest hash found so far '"websocket_duration"' with 1560568 fields
[37.36%] Biggest string found so far '"exam_data:301:104065:51536:165675"' with 128746 bytes
[81.08%] Sampled 1000000 keys so far

-------- summary -------

Sampled 1233274 keys in the keyspace!
Total key length in bytes is 48419022 (avg len 39.26)

Biggest list found '"live_merge:154_159588"' has 9 items
Biggest hash found '"websocket_duration"' has 1560568 fields
Biggest string found '"exam_data:301:104065:51536:165675"' has 128746 bytes

14 lists with 47 items (00.00% of keys, avg size 3.36)
2736 hashs with 1726892 fields (00.22% of keys, avg size 631.17)
1230524 strings with 1649082886 bytes (99.78% of keys, avg size 1340.15)
0 streams with 0 entries (00.00% of keys, avg size 0.00)
0 sets with 0 members (00.00% of keys, avg size 0.00)
0 zsets with 0 members (00.00% of keys, avg size 0.00)
优点：方便、快速、安全
缺点：分析结果不可定制化，准确性与时效性差
可以使用 redis-rdb-tools 或者 xueqiu/rdr，有对应的图形界面看着也很清晰

优点：支持定制化分析，对线上服务无影响
缺点：时效性差，RDB 文件较大时耗时较长
5、如何删除 bigkey
Redis 4.0 及之后版本：您可以通过 UNLINK 命令安全地删除大 Key 甚至特大 Key，该命令能够以非阻塞的方式，逐步地清理传入的 Key。
Redis 4.0 之前的版本：建议先通过 SCAN 命令读取部分数据，然后进行删除，避免一次性删除大量 key 导致 Redis 阻塞。
清理 HASH 数据时，建议通过 HSCAN 命令配合 HDEL 命令对失效数据进行清理，避免清理大量数据造成 Redis 阻塞。
6、UNLINK
Redis 4.0 开始引入了 UNLINK 命令，他和 del 的作用是一样的。但是区别就在于 del 是单线程的，如果删除的是 bigkey 的话，会导致整个服务都被占用。

UNLINK 其实就是把 del 的操作分到了 2 个线程里面：

在主线程中，从整个键空间中删除键
在另一个线程回收内存
虽然分在了 2 个线程里，但是操作也是安全的，并不会带来我删着删着又被读到了的并发问题。因为它（在主线程中）从键空间中删除了对象，因此任何 Redis 命令都无法访问它。

如果你有很大的值，速度会显着提高——UNLINK 是一个 O(1) 操作（每个键；在主线程中），而不管键中保存的值的大小。使用 DEL 删除一个大值可能需要几百毫秒或更长时间，而 UNLINK 将在不到一毫秒的时间内完成（包括网络往返）。

但是并不是说 del 无用武之地了，当需要实时响应的时候最好还是 del，因为毕竟 UNLINK 是一个异步操作。