亿级数据统计

常见的场景如下：

• 给一个 userId ，判断用户登陆状态
• 两亿用户最近 7 天的签到情况，统计 7 天内连续签到的用户总数
• 统计每天的新增与第二天的留存用户数
• 统计网站的对访客（Unique Visitor，UV）量
• 最新评论列表
• 根据播放量音乐榜单

通常情况下，我们面临的用户数量以及访问量都是巨大的，比如百万、千万级别的用户数量，或者千万级别、甚至亿级别的访问信息。所以，我们必须要选择能够非常高效地统计大量数据（例如亿级）的集合类型。

如何选择合适的数据集合，我们首先要了解常用的统计模式，并运用合理的数据来解决实际问题。四种统计类型：

• 二值状态统计
• 聚合统计
• 排序统计
• 基数统计

二值统计

什么是二值状态统计呀？

也就是集合中的元素的值只有 0 和 1 两种，在签到打卡和用户是否登陆的场景中，只需记录签到(1)或 未签到(0)，已登录(1)或未登陆(0)。假如我们在判断用户是否登陆的场景中使用 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 呢？

Bitmap 的底层数据结构用的是 String 类型的 SDS 数据结构来保存位数组，Redis 把每个字节数组的 8 个 bit 位利用起来，每个 bit 位 表示一个元素的二值状态（不是 0 就是 1）。可以将 Bitmap 看成是一个 bit 为单位的数组，数组的每个单元只能存储 0 或者 1，数组的下标在 Bitmap 中叫做 offset 偏移量。为了直观展示，我们可以理解成 buf 数组的每个字节用一行表示，每一行有 8 个 bit 位，8 个格子分别表示这个字节中的 8 个 bit 位，如下图所示：

8 个 bit 组成一个 Byte，所以 Bitmap 会极大地节省存储空间。 这就是 Bitmap 的优势。

当遇到的统计场景只需要统计数据的二值状态，比如用户是否存在、 ip 是否是黑名单、以及签到打卡统计等场景就可以考虑使用 Bitmap。只需要一个 bit 位就能表示 0 和 1。在统计海量数据的时候将大大减少内存占用。