前者紧张表示Redis键的占用内存大小；
后者表示Redis凑集数据类型(set/hash/list/sorted set)键，所含有的元素个数。
以下两个示例：
由于内存空间繁芜性处理耗时都非常小，测试 del 200MB String键耗时约1毫秒，
而删除一个含有1kw个字段的Hash键，却会壅塞Redis进程数十秒。以是本文只从韶光繁芜度剖析大的凑集类键。删除这种大键的风险，以及怎么优雅地删除。
Redis大键的利用问题在Redis集群中，运用程序只管即便避免利用大键；直接影响随意马虎导致集群的容量和要求涌现”倾斜问题“，详细剖析见文章：redis-cluster-imbalance。但在实际生产过程中，总会有业务利用不合理，涌现这类大键；当DBA创造后推进业务优化改造，然后删除这个大键；如果直接删除它，DEL命令可能壅塞Redis进程数十秒，对运用程序和Redis集群可用性造成严重的影响。
直接删除大Key的风险
DEL命令在删除单个凑集类型的Key时，命令的韶光繁芜度是O(M)，个中M是凑集类型Key包含的元素个数。
DEL key
Time complexity: O(N) where N is the number of keys that will be removed. When a key to remove holds a value other than a string, the individual complexity for this key is O(M) where M is the number of elements in the list, set, sorted set or hash. Removing a single key that holds a string value is O(1).
问题紧张表现以下方面：
生产环境中碰着过多次因业务删除大Key，导致Redis壅塞，涌现故障切换和运用程序雪崩的故障。测试删除凑集类型大Key耗时，一样平常每秒可清理100w~数百w个元素; 如果数千w个元素的大Key时，会导致Redis壅塞上10秒可能导致集群判断Redis已经故障，涌现故障切换；或运用程序涌现雪崩的情形。解释：Redis是单线程处理。由于Redis是单线程处理，单个耗时过大命令，导致壅塞其他命令，随意马虎引起运用程序雪崩或Redis集群发生故障切换。以是避免在生产环境中利用耗时过大命令。
删除大键的本钱Redis删除大的凑集键的耗时, 测试估算，可参考；和硬件环境、Redis版本和负载等成分有关
当我们创造集群中有大key时，要删除时，若何做到影响最小，或者至少不影响正常业务
如何优雅地删除各种大Key从Redis2.8版本开始支持SCAN命令，通过m次韶光繁芜度为O(1)的办法，遍历包含n个元素的大key.
这样避免单个O(n)的大命令，导致Redis壅塞。 这里删除大key操作的思想也是如此。
Delete Large Hash Key
通过hscan命令，每次获取500个字段，再用hdel命令，每次删除1个字段。
如：//以下均为概述代码，不针对详细措辞，实际利用按详细措辞套用即可
data = hscan(large_hash_key, cursor, count= 500)
for（item in data.items()）{
hdel(large_hash_key, item[0])
}
Delete Large Set Key
删除大set键，利用sscan命令，每次扫描凑集中500个元素，再用srem命令每次删除一个键
data = sscan(large_set_key, cursor, 500)
for（item in data）{
srem(large_size_key, item)
}
Delete Large List Key
删除大的List键，未利用scan命令； 通过ltrim命令每次删除少量元素。
while （llen(large_list_key) > 0）
{
ltrim(large_list_key, 0, -101) //每次只删除最右100个元素
}
Delete Large Sorted set key
删除大的有序凑集键，和List类似，利用sortedset自带的zremrangebyrank命令,每次删除top 100个元素。
while （zcard(large_sortedset_key) > 0）
{
//韶光繁芜度更低 , 每次删除O(log(N)+100)
zremrangebyrank(large_sortedset_key, 0, 99)
}
Redis Lazy Free
该当从3.4版本开始，Redis会支持lazy delete free的办法，删除大键的过程不会壅塞正常要求。
