3天时间,我是如何解决redis bigkey 删除问题的?( 二 )


删除时间测试下面测试和服务器硬件、Redis版本比较相关 , 可能在不同的服务器上执行速度不太相同 , 但是能提供一定的参考价值
表12-3展示了删除512KB~10MB的字符串类型数据所花费的时间 , 总体来说由于字符串类型结构相对简单 , 删除速度比较快 , 但是随着value值的不断增大 , 删除速度也逐渐变慢 。
3天时间,我是如何解决redis bigkey 删除问题的?文章插图
删除时间测试
非字符串类删除测试表12-4展示了非字符串类型的数据结构在不同数量级、不同元素大小下对bigkey执行del命令的时间 , 总体上看元素个数越多、元素越大 , 删除时间越长 , 相对于字符串类型 , 这种删除速度已经足够可以阻塞Redis 。

  • 表12-4
删除hash、list、set、sorted set四种数据结构不同数量不同元素大小的耗时
3天时间,我是如何解决redis bigkey 删除问题的?文章插图
不同元素大小的耗时
从上分析可见 , 除了string类型 , 其他四种数据结构删除的速度有可能很慢 , 这样增大了阻塞Redis的可能性 。
如何提升删除的效率既然不能用del命令 , 那有没有比较优雅的方式进行删除呢 , 这时候就需要将第2章介绍的scan命令的若干类似命令拿出来:sscan、hscan、zscan 。
string字符串删除一般不会造成阻塞
del bigkeyhash、list、set、sorted set【3天时间,我是如何解决redis bigkey 删除问题的?】下面以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 ,
(1)要思考一下可不可以做一些优化(例如拆分数据结构)尽量让这些bigkey消失在业务中 ,
(2)如果bigkey不可避免 , 也要思考一下要不要每次把所有元素都取出来(例如有时候仅仅需要hmget , 而不是hgetall) 。
(3)最后 , 可喜的是 , Redis将在4.0版本支持lazy delete free的模式 , 那时删除bigkey不会阻塞Redis 。
如何优雅的删除重构重新构建自己的业务 key 。
让 key/value 更加小 , 使用纯字符串 。
  • 缺点
有时候难以对旧的代码进行兼容 , 调整难度较大 。
使用 lazy free这个是 redis 4.0 以后的特性 。
可能会受限于版本 , 导致无法使用 。
  • 查看版本
redis 压缩包有文件 cat 00-RELEASENOTES 可以查看对应的版本信息 。
Redis 2.8 release notes=======================** IMPORTANT ** Check the 'Migrating from 2.6 to 2.8' section at the end ofthis file for information about what changed between 2.6 and2.8 and how this may affect your application.--------------------------------------------------------------------------------Upgrade urgency levels:LOW:No need to upgrade unless there are new features you want to use.MODERATE: Program an upgrade of the server, but it's not urgent.HIGH:There is a critical bug that may affect a subset of users. Upgrade!CRITICAL: There is a critical bug affecting MOST USERS. Upgrade ASAP.----------------------------------------------------------------------------------[ Redis 2.8.6 ] Release date: 13 Feb 2014可知当前版本为:2.8.6
使用 expire 设置过期需要熟知 redis 的淘汰策略 。
(1)惰性淘汰
(2)定时删除
(3)定期删除
其中定期删除 , 是一个异步的进程去处理的 , 不会阻塞主进程 。
其中设置超时时间 , 是为了限制每一次的操作时间 , 从而更好的清空数据 , 释放内存 。