Redis大Key分拆方案

本是古典何须时尚 2022-03-18 13:52 685阅读 0赞

业务场景中经常会有各种大key的情况， 比如：   
1. 单个简单的key存储的value很大   
2. hash、set、zset、list中存储过多的元素（以万为单位）   
（文章中所提及的hash，set等数据结构均指redis中的数据结构）

由于redis是单线程运行的，如果一次操作的value很大会对整个redis的响应时间造成负面影响，所以，业务上能拆则拆，下面举几个典型的分拆方案。

1**、单个简单的key存储的value很大**

**      ①改对象需要每次都整存整取 **  
       可以尝试将对象分拆成几个key-value， 使用multiGet获取值，这样分拆的意义在于分拆单次操作的压力，将操作压力平摊到多个redis实例中，降低对单个redis的IO影响；

**      ②该对象每次只需要存取部分数据 **  
       可以像第一种做法一样，分拆成几个key-value，也可以将这个存储在一个hash中，每个field代表一个具体的属性，使用hget，hmget来获取部分的value，使用hset，hmset来更新部分属性

**2、hash、set、zset、list 中存储过多的元素 **

类似于场景一种的第一个做法，可以将这些元素分拆。   
以hash为例，原先的正常存取流程是:   
hget(hashKey, field);   
hset(hashKey, field, value)

现在，固定一个桶的数量，比如10000，每次存取的时候，先在本地计算field的hash值，模除10000，确定该field落在哪个key上。   
newHashKey = hashKey + (hash(field) % 10000);   
hset(newHashKey, field, value);   
hget(newHashKey, field)

set, zset, list 也可以类似上述做法。   
但也有些不适合的场景，比如要保证lpop的数据的确是最早push到list中去的，这个就需要一些附加的属性，或者是在key的拼接上做一些工作（比如list按照时间来分拆）。

建议redis不要使用大key，会带来很多问题。[如何做到阿里云 Redis 开发规范中的拒绝 bigkey][Redis _ bigkey]  
  
原文：[https://blog.csdn.net/foreverling/article/details/77612060][https_blog.csdn.net_foreverling_article_details_77612060]

参考：[https://blog.csdn.net/wwd0501/article/details/92692946][https_blog.csdn.net_wwd0501_article_details_92692946]

[Redis _ bigkey]: https://blog.csdn.net/wwd0501/article/details/92702238
[https_blog.csdn.net_foreverling_article_details_77612060]: https://blog.csdn.net/foreverling/article/details/77612060
[https_blog.csdn.net_wwd0501_article_details_92692946]: https://blog.csdn.net/wwd0501/article/details/92692946