Redis 优雅删除BigKey

本文主要是介绍Redis 优雅删除BigKey，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

危害

• 内存空间不均匀（平衡）：如 Redis Cluster 中，bigkey 会造成节点的内存空间分布不均匀
• 超时阻塞：由于 Redis 单线程的特性，操作 bigkey 会较耗时，意味着阻塞 Redis 可能性较大。
• 网络阻塞：获取 bigkey 的网络传输较大，不仅影响客户端，而且影响其他节点；如：bigkey 为 1MB，每秒 1000次，每秒产生的流量 1000MB/s

如何发现

• redis-cli --bigkeys 可统计 bigkey 的分布
• 判定一个 key 是否为 bigkey
  • 执行 debug object key 查看 serializedlength 属性即可，该值为对应 value 序列化后的字节数；其中 encoding 可查看 key 的数据类型。
  • strlen key 可查看 key 的字节数；部分数据类型不支持

注：serializedlength 不代表真实的字节大小，返回的是对象使用 RDB 编码序列化后的长度，值会偏小。但对排查 bigkey 有一定辅助作用，因为并不是每种数据类型都支持 strlen 的方法。

实际生产环境发现 bigkey 的两种方式：

• 被动收集：客户端记录异常后记录 key，统一排查
• 主动监测（推荐）：scan+debug object，如果怀疑存在 bigkey，可以使用 scan 命令渐进的扫描所有 key，分别计算每个 key 的 serializedlength ，找出 bigkey。

开发提醒：

• 如果键值较多：scan+debug object 会比较慢，可利用 pipeline 机制完成。
• 对与元素个数较多的数据结构，如：hash、list等，debug object 会比较慢，存在阻塞 Redis 的可能。
• 如果有从节点，可以考虑从节点上执行。

如何删除

如发现 bigkey 后，无论什么命令，最都可直接使用 del 将其删除。但实际情况并非如此，不同的数据类型，不同的元素个数等不尽相同，删除可能会造成 redis 阻塞。

耗时对比

删除字符串类型，不同大小的耗时对比：

总结：string 类型随着 value 值的不断增大，删除速度也逐渐减慢。

删除 hash、list、set、sorted set 四种数据类型，不同数量，不同元素大小的耗时对比：

总结：非字符串类型，元素的个数越多，元素越大，删除时间越长。且该删除时间，足够引起 Redis 阻塞。

如何优雅删除

如何优雅的删除，且不影响 Redis 阻塞？相关 scan 命令如：sscan、hscan、zscan。

• string 类型：直接使用 del 命令即可，一般不会产生阻塞。
• hash、list、set、sorted set 类型：可使用 scan 命令，如：sscan、hscan、zscan
  • 思路：采用 scan 命令，删除每个元素后，在执行 del key。
  • 切记：执行最后需删除 del key。

最佳实践

• 数据结构合理的选择和设计，如存在 bigkey，可考虑进行拆分
• 数据读取，无需将每个数据都查询出来（如：推荐 hmget 而不是 hgetall）
• Redis 4.0 版本支持 lazy delete free 模式，这时操作删除 bigkey 不会阻塞 Redis 

这篇关于Redis 优雅删除BigKey的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！