本文摘自PHP中文网，作者青灯夜游，侵删。
在移动应用的业务场景中，我们需要保存这样的信息：一个 key 关联了一个数据集合，同时还要对集合中的数据进行统计排序。【相关推荐：Redis视频教程】
常见的场景如下：
- 给一个 userId ，判断用户登陆状态；
- 两亿用户最近 7 天的签到情况，统计 7 天内连续签到的用户总数；
- 统计每天的新增与第二天的留存用户数；
- 统计网站的对访客（Unique Visitor，UV）量
- 最新评论列表
- 根据播放量音乐榜单
通常情况下，我们面临的用户数量以及访问量都是巨大的，比如百万、千万级别的用户数量，或者千万级别、甚至亿级别的访问信息。
所以，我们必须要选择能够非常高效地统计大量数据（例如亿级）的集合类型。
如何选择合适的数据集合，我们首先要了解常用的统计模式，并运用合理的数据了性来解决实际问题。
四种统计类型：
二值状态统计；
聚合统计；
排序统计；
基数统计。
本文将用到 String、Set、Zset、List、hash 以外的拓展数据类型 Bitmap、HyperLogLog 来实现。
文章涉及到的指令可以通过在线 Redis 客户端运行调试，地址：try.redis.io/，超方便的说。
寄语
多分享多付出，前期多给别人创造价值并且不计回报，从长远来看，这些付出都会成倍的回报你。
特别是刚开始跟别人合作的时候，不要去计较短期的回报，没有太大意义，更多的是锻炼自己的视野、视角以及解决问题的能力。
二值状态统计
码哥，什么是二值状态统计呀？
也就是集合中的元素的值只有 0 和 1 两种，在签到打卡和用户是否登陆的场景中，只需记录签到(1)或 未签到(0)，已登录(1)或未登陆(0)。
假如我们在判断用户是否登陆的场景中使用 Redis 的 String 类型实现（key -> userId，value -> 0 表示下线，1 - 登陆），假如存储 100 万个用户的登陆状态，如果以字符串的形式存储，就需要存储 100 万个字符串了，内存开销太大。
对于二值状态场景，我们就可以利用 Bitmap 来实现。比如登陆状态我们用一个 bit 位表示，一亿个用户也只占用 一亿 个 bit 位内存 ≈ （100000000 / 8/ 1024/1024）12 MB。
1 |
|
什么是 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 的优势。
判断用户登陆态
怎么用 Bitmap 来判断海量用户中某个用户是否在线呢？
Bitmap 提供了 GETBIT、SETBIT 操作，通过一个偏移值 offset 对 bit 数组的 offset 位置的 bit 位进行读写操作，需要注意的是 offset 从 0 开始。
只需要一个 key = login_status 表示存储用户登陆状态集合数据， 将用户 ID 作为 offset，在线就设置为 1，下线设置 0。通过 GETBIT判断对应的用户是否在线。 50000 万 用户只需要 6 MB 的空间。
SETBIT 命令
1 |
|
设置或者清空 key 的 value 在 offset 处的 bit 值（只能是 0 或者 1）。
GETBIT 命令
1 |
|
获取 key 的 value 在 offset 处的 bit 位的值，当 key 不存在时，返回 0。
假如我们要判断 ID = 10086 的用户的登陆情况：
第一步，执行以下指令，表示用户已登录。
1 |
|
第二步，检查该用户是否登陆，返回值 1 表示已登录。
1 |
|
第三步，登出，将 offset 对应的 value 设置成 0。
1 |
|
用户每个月的签到情况
在签到统计中，每个用户每天的签到用 1 个 bit 位表示，一年的签到只需要 365 个 bit 位。一个月最多只有 31 天，只需要 31 个 bit 位即可。
比如统计编号 89757 的用户在 2021 年 5 月份的打卡情况要如何进行？
key 可以设计成 uid:sign:{userId}:{yyyyMM}，月份的每一天的值 - 1 可以作为 offset（因为 offset 从 0 开始，所以 offset = 日期 - 1）。
第一步，执行下面指令表示记录用户在 2021 年 5 月 16 号打卡。
1 |
|
第二步，判断编号 89757 用户在 2021 年 5 月 16 号是否打卡。
1 |
|
第三步，统计该用户在 5 月份的打卡次数，使用 BITCOUNT 指令。该指令用于统计给定的 bit 数组中，值 = 1 的 bit 位的数量。
1 |
|
这样我们就可以实现用户每个月的打卡情况了，是不是很赞。
如何统计这个月首次打卡时间呢？
Redis 提供了 BITPOS key bitValue [start] [end]指令，返回数据表示 Bitmap 中第一个值为 bitValue 的 offset 位置。
在默认情况下， 命令将检测整个位图， 用户可以通过可选的 start 参数和 end 参数指定要检测的范围。
所以我们可以通过执行以下指令来获取 userID = 89757 在 2021 年 5 月份首次打卡日期：
1 |
|
需要注意的是，我们需要将返回的 value + 1 表示首次打卡的天，因为 offset 从 0 开始。
连续签到用户总数
在记录了一个亿的用户连续 7 天的打卡数据，如何统计出这连续 7 天连续打卡用户总数呢？
我们把每天的日期作为 Bitmap 的 key，userId 作为 offset，若是打卡则将 offset 位置的 bit 设置成 1。
key 对应的集合的每个 bit 位的数据则是一个用户在该日期的打卡记录。
一共有 7 个这样的 Bitmap，如果我们能对这 7 个 Bitmap 的对应的 bit 位做 『与』运算。
同样的 UserID offset 都是一样的，当一个 userID 在 7 个 Bitmap 对应对应的 offset 位置的 bit = 1 就说明该用户 7 天连续打卡。
结果保存到一个新 Bitmap 中，我们再通过 BITCOUNT 统计 bit = 1 的个数便得到了连续打卡 7 天的用户总数了。
Redis 提供了 BITOP operation destkey key [key ...]这个指令用于对一个或者多个 键 = key 的 Bitmap 进行位元操作。
opration 可以是 and、OR、NOT、XOR。当 BITOP 处理不同长度的字符串时，较短的那个字符串所缺少的部分会被当做 0 。
空的 key 也被看作是包含 0 的字符串序列。
便于理解，如下图所示：
3 个 Bitmap，对应的 bit 位做「与」操作，结果保存到新的 Bitmap 中。
操作指令表示将 三个 bitmap 进行 AND 操作，并将结果保存到 destmap 中。接着对 destmap 执行 BITCOUNT 统计。
1 2 3 4 |
|
简单计算下 一个一亿个位的 Bitmap占用的内存开销，大约占 12 MB 的内存（10^8/8/1024/1024），7 天的 Bitmap 的内存开销约为 84 MB。同时我们最好给 Bitmap 设置过期时间，让 Redis 删除过期的打卡数据，节省内存。
小结
思路才是最重要，当我们遇到的统计场景只需要统计数据的二值状态，比如用户是否存在、 ip 是否是黑名单、以及签到打卡统计等场景就可以考虑使用 Bitmap。
只需要一个 bit 位就能表示 0 和 1，在统计海量数据的时候将大大减少内存占用。
基数统计
基数统计：统计一个集合中不重复元素的个数，常见于计算独立用户数（UV）。
实现基数统计最直接的方法，就是采用集合（Set）这种数据结构，当一个元素从未出现过时，便在集合中增加一个元素；如果出现过，那么集合仍保持不变。
当页面访问量巨大，就需要一个超大的 Set 集合来统计，将会浪费大量空间。
另外，这样的数据也不需要很精确，到底有没有更好的方案呢？
这个问题问得好，Redis 提供了 HyperLogLog 数据结构就是用来解决种种场景的统计问题。
HyperLogLog 是一种不精确的去重基数方案，它的统计规则是基于概率实现的，标准误差 0.81%，这样的精度足以满足 UV 统计需求了。
关于 HyperLogLog 的原理过于复杂，如果想要了解的请移步：
- https://www.zhihu.com/question/53416615
- https://en.wikipedia.org/wiki/HyperLogLog
网站的 UV
通过 Set 实现
一个用户一天内多次访问一个网站只能算作一次，所以很容易就想到通过 Redis 的 Set 集合来实现。
用户编号 89757 访问 「Redis 为什么这么快 」时，我们将这个信息放到 Set 中。
1 |
|
当用户编号 89757 多次访问「Redis 为什么这么快」页面，Set 的去重功能能保证不会重复记录同一个用户 ID。
通过 SCARD 命令，统计「Redis 为什么这么快」页面 UV。指令返回一个集合的元素个数（也就是用户 ID）。
1 |
|
通过 Hash 实现
码老湿，还可以利用 Hash 类型实现，将用户 ID 作为 Hash 集合的 key，访问页面则执行 HSET 命令将 value 设置成 1。
即使用户重复访问，重复执行命令，也只会把这个 userId 的值设置成 “1"。
最后，利用 HLEN 命令统计 Hash 集合中的元素个数就是 UV。
如下：
1 2 3 |
|
HyperLogLog 王者方案
码老湿，Set 虽好，如果文章非常火爆达到千万级别，一个 Set 就保存了千万个用户的 ID，页面多了消耗的内存也太大了。同理，Hash数据类型也是如此。咋办呢？
利用 Redis 提供的 HyperLogLog 高级数据结构（不要只知道 Redis 的五种基础数据类型了）。这是一种用于基数统计的数据集合类型，即使数据量很大，计算基数需要的空间也是固定的。
每个 HyperLogLog 最多只需要花费 12KB 内存就可以计算 2 的 64 次方个元素的基数。
Redis 对 HyperLogLog 的存储进行了优化，在计数比较小的时候，存储空间采用系数矩阵，占用空间很小。
只有在计数很大，稀疏矩阵占用的空间超过了阈值才会转变成稠密矩阵，占用 12KB 空间。
PFADD
将访问页面的每个用户 ID 添加到 HyperLogLog 中。
1 |
|
PFCOUNT
利用 PFCOUNT 获取 「Redis主从同步原理」页面的 UV值。
相关阅读 >>
更多相关阅读请进入《Redis》频道 >>
数据库系统概念 第6版
本书主要讲述了数据模型、基于对象的数据库和XML、数据存储和查询、事务管理、体系结构等方面的内容。
