redis中的bitmap_Redis中的Bitmap偏移过大的问题

redis hash 数据结构大家通常都会用到，而 bitmap 则是一种更省内存的数据结构，可以用来快速查询、去重等。

今天用两个 setbit 命令，让 redis bitmap 内存占用飙升到 512 MB......

设置 bitmap 前 redis 内存如下：

操作 bitmap，只用两个 setbit 操作。注意了....

一顿骚操作后，redis 内存使用如下：

内存暴涨，发现没有？？？

为什么？

bitmap 内存暴涨原因：

bitmap 在 redis 中按 string 来存储，因此上限是 512MB(2^32 bits). 因此当我的第二个 setbit 值为 2^32-1=4294967295 时，由于 redis 没有采用压缩实现，就会直接申请到 512MB 内存空间来存储 2^32-1 bit 位置的值 1，中间的 bit 也会全填上 0.

而 guava 中 EWAHCompressedBitmap 是一种压缩的 bitmap 实现，将 64 bit 作为一个 word(一个 long 的长度)，4个 word 作为一组，并在每一组的第一个 word 引入了 Running Length Word (携带跨度信息 word，类似路标)概念，其他三个 word 为 Literal Word(直接存储信息的 word)。在压缩 bitmap 实现下，本文的两个 setbit 操作就不会使 EWAHCompressedBitmap 内存占用暴涨，而是只会使用 2组 word，即 64 bytes.

不过即使通过压缩节省了空间，google 官方仍建议使用者从小到大来插入数据......

所以为了测试，给 redis bitmap 试了两个骚操作，结果证明 redis bitmap 没有用压缩结构实现.

参考文章：

小灰的 bitmap 算法整合版：https://mp.weixin.qq.com/s/xxauNrJY9HlVNvLrL5j2hg

redis bitmap command：https://redis.io/commands/setbit

解决方案：

https://blog.csdn.net/weixin_40721856/article/details/103112042

1、首先按天维护一个String值，就是将每天的最大id保存一下。我们叙述方便，将其记为 maxId。

2、每一天维护bitmap的时候，位置数值-昨天的maxid。

例如：昨天最大的id是10000，今天的id肯定是从10000以后开始的。

以我们要存储10005这个数值来计算，我们先拿到昨天的maxId(10000)，然后用10005-10000 =5 来表示这个id，只需要将今天的bitmap的第五位设置成1就可以解决这个问题了。