redis如何找长期有效的大key（Redis大key多key拆分方案）

redis如何找长期有效的大key（Redis大key多key拆分方案）1：单个简单的key存储的value很大业务场景中经常会有各种大key多key的情况， 比如：4：大Bitmap或布隆过滤器（Bloom ）拆分 背景

来源：公众号转行程序员 作者：王炸

目录

1：单个简单的key存储的value很大

2：hash， set，zset，list 中存储过多的元素

3：一个集群存储了上亿的key

4：大Bitmap或布隆过滤器（Bloom ）拆分

背景

业务场景中经常会有各种大key多key的情况， 比如：

1：单个简单的key存储的value很大

2：hash， set，zset，list 中存储过多的元素（以万为单位）

3：一个集群存储了上亿的key，Key 本身过多也带来了更多的空间占用

（如无意外，文章中所提及的hash，set等数据结构均指Redis中的数据结构 ）

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

1：单个简单的key存储的value很大

i：该对象需要每次都整存整取

注意两个地方：1，hash 取模对负数的处理； 2，预分桶的时候， 一个hash 中存储的值最好不要超过 512 ，100 左右较为合适

4：大Bitmap或布隆过滤器（Bloom ）拆分

使用bitmap或布隆过滤器的场景，往往是数据量极大的情况，在这种情况下，Bitmap和布隆过滤器使用空间也比较大，比如用于公司userid匹配的布隆过滤器，就需要512MB的大小，这对redis来说是绝对的大value了。

这种场景下，我们就需要对其进行拆分，拆分为足够小的Bitmap，比如将512MB的大Bitmap拆分为1024个512KB的Bitmap。不过拆分的时候需要注意，要将每个key落在一个Bitmap上。有些业务只是把Bitmap 拆开， 但还是当做一个整体的bitmap看， 所以一个 key 还是落在多个 Bitmap 上，这样就有可能导致一个key请求需要查询多个节点、多个Bitmap。

如下图，被请求的值被hash到多个Bitmap上，也就是redis的多个key上，这些key还有可能在不同节点上，这样拆分显然大大降低了查询的效率。

因此我们所要做的是把所有拆分后的Bitmap当作独立的bitmap，然后通过hash将不同的key分配给不同的bitmap上，而不是把所有的小Bitmap当作一个整体。这样做后每次请求都只要取redis中一个key即可。

有同学可能会问，通过这样拆分后，相当于Bitmap变小了，会不会增加布隆过滤器的误判率？实际上是不会的，布隆过滤器的误判率是哈希函数个数k，集合元素个数n，以及Bitmap大小m所决定的，其约等于

。

因此如果我们在第一步，也就是在分配key给不同Bitmap时，能够尽可能均匀的拆分，那么n／m的值几乎是一样的，误判率也就不会改变。具体的误判率推导可以参考wiki：Bloom_filter

同时，客户端也提供便利的api （>=2.3.4版本）， setBits/ getBits 用于一次操作同一个key的多个bit值 。

建议 ：k 取 13 个， 单个bloomfilter控制在 512KB 以下

以上方案仅供参考，欢迎大家提供其他的优秀方案。