参考：https://www.cnblogs.com/uniqueDong/p/15114305.html
"统计类型：二值状态统计；聚合统计；排序统计；基数统计。
1、当我们遇到的统计场景只需要统计数据的二值状态，比如用户是否存在、 ip 是否是黑名单、以及签到打卡统计等场景就可以考虑使用Redis Bitmap。
给一个 userId ，判断用户登陆状态；
两亿用户最近 7 天的签到情况，统计 7 天内连续签到的用户总数；
-- 定义7个BitMap分别代表一天。并对7天数据取XOR/OR； 整体内存评估（ 一个一亿个位的 Bitmap占用的内存开销，大约占 12 MB 的内存（10^8/8/1024/1024），7 天的 Bitmap 的内存开销约为 84 MB。）
统计每天的新增与第二天的留存用户数；
2、基数统计：统计一个集合中不重复元素的个数，常见于计算独立用户数（UV）。
选型：Redis HyperLogLog（每个 HyperLogLog 最多只需要花费 12KB 内存就可以计算 2 的 64 次方个元素的基数。）
统计网站的对访客（Unique Visitor，UV）量
最新评论列表
根据播放量音乐榜单"
二值状态场景，我们就可以利用 Bitmap 来实现。比如登陆状态我们用一个 bit 位表示，一亿个用户也只占用 一亿 个 bit 位内存 ≈ （100000000 / 8/ 1024/1024）12 MB。
Bitmap 提供了 GETBIT、SETBIT 操作，通过一个偏移值 offset 对 bit 数组的 offset 位置的 bit 位进行读写操作，需要注意的是 offset 从 0 开始。
只需要一个 key = login_status 表示存储用户登陆状态集合数据， 将用户 ID 作为 offset，在线就设置为 1，下线设置 0。通过 GETBIT判断对应的用户是否在线。 50000 万 用户只需要 6 MB 的空间。
SETBIT <key> <offset> <value>
GETBIT <key> <offset> 获取 key 的 value 在 offset 处的 bit 位的值，当 key 不存在时，返回 0。
判断 ID = 10086 的用户的登陆情况：
SETBIT login_status 10086 1 执行以下指令，表示用户已登录。
GETBIT login_status 10086 检查该用户是否登陆，返回值 1 表示已登录。
SETBIT login_status 10086 0 登出，将 offset 对应的 value 设置成 0。
在签到统计中，每个用户每天的签到用 1 个 bit 位表示，一年的签到只需要 365 个 bit 位。一个月最多只有 31 天，只需要 31 个 bit 位即可。
统计编号 89757 的用户在 2021 年 5 月份的打卡情况要如何进行？
key 可以设计成 uid:sign:{userId}:{yyyyMM}，月份的每一天的值 - 1 可以作为 offset（因为 offset 从 0 开始，所以 offset = 日期 - 1）。
SETBIT uid:sign:89757:202105 15 1 记录用户在 2021 年 5 月 16 号打卡
GETBIT uid:sign:89757:202105 15 判断编号 89757 用户在 2021 年 5 月 16 号是否打卡
BITCOUNT uid:sign:89757:202105 统计该用户在 5 月份的打卡次数
如何统计这个月首次打卡时间呢？
Redis 提供了 BITPOS key bitValue [start] [end]指令，返回数据表示 Bitmap 中第一个值为 bitValue 的 offset 位置。
记录了一个亿的用户连续 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 的字符串序列。
统计一个集合中不重复元素的个数，常见于计算独立用户数（UV）
实现基数统计最直接的方法，就是采用集合（Set）这种数据结构，当一个元素从未出现过时，便在集合中增加一个元素；如果出现过，那么集合仍保持不变。
当页面访问量巨大，就需要一个超大的 Set 集合来统计，将会浪费大量空间。另外，这样的数据也不需要很精确，到底有没有更好的方案呢？
Redis HyperLogLog 是一种不精确的去重基数方案，它的统计规则是基于概率实现的，标准误差 0.81%，这样的精度足以满足 UV 统计需求了。
每个 HyperLogLog 最多只需要花费 12KB 内存就可以计算 2 的 64 次方个元素的基数。
Redis 对 HyperLogLog 的存储进行了优化，在计数比较小的时候，存储空间采用系数矩阵，占用空间很小。
只有在计数很大，稀疏矩阵占用的空间超过了阈值才会转变成稠密矩阵，占用 12KB 空间。
PFADD Redis主从同步原理:uv userID1 userID 2 useID3 将访问页面的每个用户 ID 添加到 HyperLogLog 中。
PFCOUNT Redis主从同步原理:uv 利用 PFCOUNT 获取 「Redis主从同步原理」页面的 UV值。
PFMERGE destkey sourcekey [sourcekey ...] 将多个 HyperLogLog 合并在一起形成一个新的 HyperLogLog 值
微信公众号的后台回复列表（不要杠，举例子），每一公众号对应一个 List，这个 List 保存该公众号的所有的用户评论。
LPUSH 码哥字节 1 2 3 4 5 6
LRANGE key star stop 获取列表指定区间内的元素。
注意，并不是所有最新列表都能用 List 实现，对于因为对于频繁更新的列表，list类型的分页可能导致列表元素重复或漏掉。
ZRANGEBYSCORE
ZREVRANGE
指的就是统计多个集合元素的聚合结果，比如说：
码老湿，什么样的场景会用到交集、差集、并集呢？
Redis 的 Set 类型支持集合内的增删改查，底层使用了 Hash 数据结构，无论是 add、remove 都是 O(1) 时间复杂度。
并且支持多个集合间的交集、并集、差集操作，利用这些集合操作，解决上边提到的统计问题。
比如 QQ 中的共同好友正是聚合统计中的交集。我们将账号作为 Key，该账号的好友作为 Set 集合的 value。
模拟两个用户的好友集合：
SADD user:码哥字节 R大 Linux大神 PHP之父
SADD user:大佬 Linux大神 Python大神 C++菜鸡
统计两个用户的共同好友只需要两个 Set 集合的交集，如下命令：
SINTERSTORE user:共同好友 user:码哥字节 user:大佬
命令的执行后，「user:码哥字节」、「user:大佬」两个集合的交集数据存储到 user:共同好友这个集合中。
比如，统计某个 App 每日新增注册用户量，只需要对近两天的总注册用户量集合取差集即可。
比如，2021-06-01 的总注册用户量存放在 key = user:20210601 set 集合中，2021-06-02 的总用户量存放在 key = user:20210602 的集合中。
如下指令，执行差集计算并将结果存放到 user:new 集合中。
SDIFFSTORE user:new user:20210602 user:20210601
执行完毕，此时的 user:new 集合将是 2021/06/02 日新增用户量。
除此之外，QQ 上有个可能认识的人功能，也可以使用差集实现，就是把你朋友的好友集合减去你们共同的好友即是可能认识的人。
还是差集的例子，统计 2021/06/01 和 2021/06/02 两天总共新增的用户量，只需要对两个集合执行并集。
SUNIONSTORE userid:new user:20210602 user:20210601
此时新的集合 userid:new 则是两日新增的好友。
Set 的差集、并集和交集的计算复杂度较高，在数据量较大的情况下，如果直接执行这些计算，会导致 Redis 实例阻塞。
所以，可以专门部署一个集群用于统计，让它专门负责聚合计算，或者是把数据读取到客户端，在客户端来完成聚合统计，这样就可以规避由于阻塞导致其他服务无法响应。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。