日活、周活数是表示用户参与度的常用指标，是衡量 PMF(Product Market Fit，产品 - 市场匹配) 的一个重要参数。redis 统计日活、周活，主要有三种方式。
使用集合
主要命令
- SADD key member [member …]
时间复杂度:O(N)，N 是被添加的元素的数量
将一个或多个 member 元素加入到集合 key 当中，已经存在于集合的 member 元素将被忽略
- SCARD key
时间复杂度:O(1)
返回集合 key 中元素的数量
- SUNIONSTORE destination key [key …]
时间复杂度:O(N)，N 是所有给定集合的成员数量之和
使用方法
当用户访问一次应用时，将用户id放入当日集合中
127.0.0.1:6379> sadd user_day1 10000
(integer) 1
127.0.0.1:6379> sadd user_day1 10000
(integer) 0
127.0.0.1:6379> sadd user_day1 10001
(integer) 1
127.0.0.1:6379> sadd user_day1 10002
(integer) 1
127.0.0.1:6379> sadd user_day1 10002
(integer) 0
127.0.0.1:6379> sadd user_day1 10003
(integer) 1
127.0.0.1:6379> sadd user_day1 10004
(integer) 1获取应用一天的活跃数量的方式为
127.0.0.1:6379> scard user_day1
(integer) 5获取应用一周的活跃数量的方式为
127.0.0.1:6379> sunionstore user_week1 user_day1 user_day2 user_day3 user_day4 user_day5 user_day6 user_day7
(integer) 5优点
- 可以比较简单的统计日活、周活
- 统计的结果是精确的
缺点
- 集合比较消耗 redis 内存空间，假设每个用户 id 占用10字节(byte)，1亿用户一天就会消耗 950M 的空间，对于 redis 这种内存型存储来说，成本巨大
- 集合中数据量大时，会产生大 key。由于 sunionstore 的时间复杂度是 O(N)， N 是所有给定集合的成员数量之，当进行 sunionstore 合并操作的时候，会导致 redis 出现阻塞，影响 redis 的整体性能。当然，也可以使用分片思想，将大 key 变小，但是随着时间推移，用户数量变多，大 key 风险依然存在
适用场景
- 集合只适用于用户数比较少的场合
使用 bitmap
在计算机里，一个字节(byte)有8个二进制位，即1byte=8bit。
假设有7个数字，我们可以按照编号放进一段连续内存里，对应位置中存在就显示1，其它默认都显示0 比如 3，5，1，7，11，15，4，1
那对应的位置为：
字节 | 0位 | 1位 | 2位 | 3位 | 4位 | 5位 | 6位 | 7位 |
byte0 | 0 | 1(1) | 0 | 1(3) | 0 | 1(5) | 0 | 1(7) |
byte1 | 0 | 0 | 0 | 1(11) | 0 | 0 | 0 | 1(15) |
由于一个二进制位就表示一个数字，该位上只有0，1两个值，所以将数字映射成二进制位后，不仅对数字进行了排序，还做了排重处理，可以用来统计日活、周活。
主要命令
- SETBIT key offset value
时间复杂度:O(1)
- BITCOUNT key [start] [end]
时间复杂度:O(N)
计算给定字符串中，被设置为 1 的比特位的数量
- BITOP OR destkey key [key …]
时间复杂度:O(N)
对一个或多个 key 求逻辑或，并将结果保存到 destkey
使用方法
当用户访问一次应用时，就将该用户 id 的二进制位，置为1
127.0.0.1:6379> setbit user_day1 10000 1
(integer) 0
127.0.0.1:6379> setbit user_day1 10000 1
(integer) 1
127.0.0.1:6379> setbit user_day1 10001 1
(integer) 0
127.0.0.1:6379> setbit user_day1 10002 1
(integer) 0
127.0.0.1:6379> setbit user_day1 10002 1
(integer) 1
127.0.0.1:6379> setbit user_day1 10003 1
(integer) 0
127.0.0.1:6379> setbit user_day1 10004 1
(integer) 0获取应用一天的活跃数量的方式为
127.0.0.1:6379> bitcount user_day1
(integer) 5获取应用一周的活跃数量的方式为
127.0.0.1:6379> bitop OR user_week1 user_day1 user_day2 user_day3 user_day4 user_day5 user_day6 user_day7
127.0.0.1:6379> bitcount user_week1
(integer) 5优点
- 可以比较简单的统计日活、周活
- 统计的结果是精确的
- 占用空间比集合要少，1亿用户一天只需要12M的空间
缺点
- redis setbit，offset 的值最大可到2 ^ 32 - 1，即用户总数量不能大于4294967295，也就是42亿左右。由于日活、周活统计中，offset 是用户 id，所以用户 id 也不能大于4294967295
- 如果 offset 真要达到4294967295，redis 会分配 512M 的存储空间形成大 key，大的内存分配会造成 redis 出现阻塞。bitcount 和 bitop 的时间复杂度是 O(N)，如果对大 key 进行操作，也会导致 redis 出现阻塞
- bitmap 占用的空间的大小，和用户数量是没有关系的，而是取决于最大的用户 id 是多少，哪怕今天只有一个用户访问应用，如果他的用户 id 是1亿，那么今天统计用户活跃的 bitmap 使用空间就是12M
- 对于分维度的统计，比如根据地区统计日活、周活，有的地区用户不多，但是用户 id 非常大，导致该地区当天的 bitmap 使用空间很大
适用场景
- bitmap 适用于用户数在1～2亿左右，且用户 id 比较连续的场合(占用12M~24M空间)，再大就有可能出现性能问题。当然，也可以使用分片思想来解决。
使用 HyperLogLog
HyperLogLog 是一种概率数据结构，用来估算数据的基数，是通过牺牲准确率来减少内存空间的消耗。
主要命令
- PFADD key element [element …]
每添加一个元素的复杂度为 O(1)
添加的元素如果重复，会被忽略
- PFCOUNT key [key …]
当命令作用于单个 HyperLogLog 时，复杂度为 O(1)，并且具有非常低的平均常数时间。当命令作用于 N 个 HyperLogLog 时，复杂度为 O(N)，常数时间也比处理单个 HyperLogLog 时要大得多 。
作用于多个键时，返回所有给定 HyperLogLog 的并集的近似值，这个近似值是通过将所有给定 HyperLogLog 合并至一个临时 HyperLogLog 来计算得出的。
- PFMERGE destkey sourcekey [sourcekey …]
时间复杂度:O(N)，其中 N 为被合并的 HyperLogLog 数量，不过这个命令的常数复杂度比较高 将多个 HyperLogLog 合并为一个 HyperLogLog，合并后的 HyperLogLog 的值接近于所有 HyperLogLog 的并集
使用方法
当用户访问一次应用时，将用户id放入 HyperLogLog 中
127.0.0.1:6379> pfadd user_day1 10000
(integer) 1
127.0.0.1:6379> pfadd user_day1 10000
(integer) 0
127.0.0.1:6379> pfadd user_day1 10001
(integer) 1
127.0.0.1:6379> pfadd user_day1 10002
(integer) 1
127.0.0.1:6379> pfadd user_day1 10002
(integer) 0
127.0.0.1:6379> pfadd user_day1 10003
(integer) 1
127.0.0.1:6379> pfadd user_day1 10004
(integer) 1获取应用一天的活跃数量的方式为
127.0.0.1:6379> pfcount user_day1
(integer) 5获取应用一周的活跃数量的方式为
127.0.0.1:6379> pfmerge user_week1 user_day1 user_day2 user_day3 user_day4 user_day5 user_day6 user_day7
127.0.0.1:6379> pfcount user_week1
(integer) 5
//或者直接使用 pfcount
127.0.0.1:6379> pfcount user_day1 user_day2 user_day3 user_day4 user_day5 user_day6 user_day7
(integer) 5优点
- 可以比较简单的统计日活、周活
- 占用空间比集合和 bitmap 都要少，不管用户有多少(最大 2 ^ 64)，都是只消耗14392字节(约14KB)左右的内存
缺点
- redis HyperLogLog 是一种概率的数据结构，统计的结果不是一个精确值，而是一个带有0.81%误差的近似值
适用场景
- HyperLogLog 适用于用户量巨大，对精度要求不那么高的场景