3天时间，我是如何解决redis bigkey 删除问题的？( 二 ) 问题的出现一个平淡无奇的工作日

主动检测：scan+debug object：如果怀疑存在bigkey ，可以使用scan命令渐进的扫描出所有的key ，分别计算每个key的serializedlength ，找到对应bigkey进行相应的处理和报警，这种方式是比较推荐的方式。
如何删除因为 redis 是单线程的，删除比较大的 keys 就会阻塞其他的请求。
当发现Redis中有bigkey并且确认要删除时，如何优雅地删除bigkey？
无论是什么数据结构， del命令都将其删除。
但是相信通过上面的分析后你一定不会这么做，因为删除bigkey通常来说会阻塞Redis服务。
下面给出一组测试数据分别对string、hash、list、set、sorted set五种数据结构的bigkey进行删除， bigkey的元素个数和每个元素的大小不尽相同。
删除时间测试下面测试和服务器硬件、Redis版本比较相关，可能在不同的服务器上执行速度不太相同，但是能提供一定的参考价值
表12-3展示了删除512KB~10MB的字符串类型数据所花费的时间，总体来说由于字符串类型结构相对简单，删除速度比较快，但是随着value值的不断增大，删除速度也逐渐变慢。
文章插图
删除时间测试
非字符串类删除测试表12-4展示了非字符串类型的数据结构在不同数量级、不同元素大小下对bigkey执行del命令的时间，总体上看元素个数越多、元素越大，删除时间越长，相对于字符串类型，这种删除速度已经足够可以阻塞Redis 。

表12-4

删除hash、list、set、sorted set四种数据结构不同数量不同元素大小的耗时

文章插图
不同元素大小的耗时
从上分析可见，除了string类型，其他四种数据结构删除的速度有可能很慢，这样增大了阻塞Redis的可能性。
如何提升删除的效率既然不能用del命令，那有没有比较优雅的方式进行删除呢，这时候就需要将第2章介绍的scan命令的若干类似命令拿出来：sscan、hscan、zscan 。
string字符串删除一般不会造成阻塞
del bigkeyhash、list、set、sorted set下面以hash为例子，使用hscan命令，每次获取部分（例如100个）fieldvalue ，再利用hdel删除每个field（为了快速可以使用Pipeline）：

public void delBigHash(String bigKey) {Jedis jedis = new Jedis(“127.0.0.1”, 6379);// 游标String cursor = “0”;while (true) {ScanResult scanResult = jedis.hscan(bigKey, cursor, new ScanParams().count(100));// 每次扫描后获取新的游标cursor = scanResult.getStringCursor();// 获取扫描结果List list = scanResult.getResult();if (list == null || list.size() == 0) {continue;}String[] fields = getFieldsFrom(list);// 删除多个fieldjedis.hdel(bigKey, fields);// 游标为0时停止if (cursor.equals(“0”)) {break;}}// 最终删除keyjedis.del(bigKey);}/*** 获取field数组* @param list* @return*/private String[] getFieldsFrom(List list) {List fields = new ArrayList();for(Entry entry : list) {fields.add(entry.getKey());}return fields.toArray(new String[fields.size()]);}

请勿忘记每次执行到最后执行del key操作。
最佳实践思路由于开发人员对Redis的理解程度不同，在实际开发中出现bigkey在所难免，重要的是，能通过合理的检测机制及时找到它们，进行处理。
作为开发人员在业务开发时应注意不能将Redis简单暴力的使用，应该在数据结构的选择和设计上更加合理，例如出现了bigkey ，