Redis 实战篇：巧用Bitmap 实现亿级海量数据统计

假如我们在判断用户是否登陆的场景中使用 Redis 的 String 类型实现（key -> userId，value -> 0 表示下线，1 - 登陆），假如存储 100 万个用户的登陆状态，如果以字符串的形式存储，就需要存储 100 万个字符串了，内存开销太大。

码哥，为什么 String 类型内存开销大？

String 类型除了记录实际数据以外，还需要额外的内存记录数据长度、空间使用等信息。

当保存的数据包含字符串，String 类型就使用简单动态字符串（SDS）结构体来保存，如下图所示：

• len：占 4 个字节，表示 buf 的已用长度。

• alloc：占 4 个字节，表示 buf 实际分配的长度，通常 > len。

• buf：字节数组，保存实际的数据，Redis 自动在数组最后加上一个 “\0”，额外占用一个字节的开销。

所以，在 SDS 中除了 buf 保存实际的数据， len 与 alloc 就是额外的开销。

另外，还有一个 RedisObject 结构的开销，因为 Redis 的数据类型有很多，而且，不同数据类型都有些相同的元数据要记录（比如最后一次访问的时间、被引用的次数等）。

所以，Redis 会用一个 RedisObject 结构体来统一记录这些元数据，同时指向实际数据。

对于二值状态场景，我们就可以利用 Bitmap 来实现。比如登陆状态我们用一个 bit 位表示，一亿个用户也只占用 一亿 个 bit 位内存 ≈ （100000000 / 8/ 1024/1024）12 MB。

大概的空间占用计算公式是：($offset/8/1024/1024) MB