假如我们在判断用户是否登陆的场景中使用 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
什么是 Bitmap 呢?
Bitma