基于 Redis 实现用户签到和 UV 统计

一、用户签到

1.1 BitMap 用法

1.1.1 简介

        假如我们用一张表来存储用户签到信息，其结构应该如下：

        假如有 1000万用户，平均每人每年签到次数为 10 次，则这张表一年的数据量为 1亿条，每签到一次需要使用（8 + 8 + 1 + 1 + 3 + 1）共 22 字节的内存，一个月则最多需要 600 多字节。这样是非常耗费数据库存储空间的。

        我们按月来统计用户签到信息，签到记录为1，未签到则记录为0，如下图：

        把每一个 bit 位对应当月的每一天，形成了映射关系。用 0 和 1 标示业务状态，这种思路就称为位图（BitMap） 。

        Redis 中是利用 string 类型数据结构实现 BitMap，因此最大上限是 512M，转换为 bit 则是 2^32 个 bit 位。这样存储起来就完全不耗费存储空间了。

1.1.2 常用命令

        SETBIT：向指定位置（offset）存入一个0或1

        GETBIT ：获取指定位置（offset）的bit值

        BITCOUNT ：统计 BitMap 中值为 1 的 bit 位的数量

        BITFIELD ：操作（查询、修改、自增）BitMap 中 bit 数组中的指定位置（offset）的值

        BITFIELD_RO ：获取 BitMap 中 bit 数组，并以十进制形式返回

        BITOP ：将多个 BitMap 的结果做位运算（与 、或、异或）

        BITPOS ：查找 bit 数组中指定范围内第一个 0 或 1 出现的位置

# 0 号脚标放值为 1
127.0.0.1:6379> setbit x 0 1
(integer) 0
# 1 号脚标放值为 1
127.0.0.1:6379> setbit x 1 1
(integer) 0
# 获取 0 号脚标放的值
127.0.0.1:6379> getbit x 0
(integer) 1
127.0.0.1:6379> getbit x 1
(integer) 1
127.0.0.1:6379> bitcount x
(integer) 2
127.0.0.1:6379> setbit x 3 1
(integer) 0
127.0.0.1:6379> bitpos x 0
(integer) 2

1.2、签到功能

1.2.1 需求描述

        实现签到接口，将当前用户当天签到信息保存到 Redis 中，如下图：

        提示：因为 BitMap 底层是基于 String 数据结构，因此其操作也都封装在字符串相关操作中了 。

1.2.2 代码实现

        涉及到的 controller 层代码如下：

    @PostMapping("/sign")
    public Result sign(){
        return userService.sign();
    }

        涉及到的 service 层代码如下：

    @Override
    public Result sign() {
        // 1.获取当前登录用户
        Long userId = UserHolder.getUser().getId();
        // 2.获取日期
        LocalDateTime now = LocalDateTime.now();
        // 3.拼接key
        String keySuffix = now.format(DateTimeFormatter.ofPattern(":yyyyMM"));
        String key = "sign:" + userId + keySuffix;
        // 4.获取今天是本月的第几天
        int dayOfMonth = now.getDayOfMonth();
        // 5.写入Redis SETBIT key offset 1
        stringRedisTemplate.opsForValue().setBit(key, dayOfMonth - 1, true);
        return Result.ok();
    }

        使用 postman 发送请求，如下：

1.3 签到统计

1.3.1 简介

        问题1：什么叫做连续签到天数？从最后一次签到开始向前统计，直到遇到第一次未签到为止，计算总的签到次数，就是连续签到天数。如下图：

        问题2：如何得到本月到今天为止的所有签到数据？

# u 为无符号偏移量
# dayOfMonth 为几号
BITFIELD key GET u[dayOfMonth] 0

        问题3：如何从后向前遍历每个 bit 位？与 1 做与运算，就能得到最后一个 bit 位。随后右移 1 位，下一个 bit 位就成为了最后一个 bit 位。

1.3.2 需求描述

        实现下面接口，统计当前用户截止当前时间在本月的连续签到天数。

1.3.3 代码实现

        涉及到的 controller 层代码如下：

    @GetMapping("/sign/count")
    public Result signCount(){
        return userService.signCount();
    }

        涉及到的 service 层代码如下：

    @Override
    public Result signCount() {
        // 1.获取当前登录用户
        Long userId = UserHolder.getUser().getId();
        // 2.获取日期
        LocalDateTime now = LocalDateTime.now();
        // 3.拼接key
        String keySuffix = now.format(DateTimeFormatter.ofPattern(":yyyyMM"));
        String key = "sign:" + userId + keySuffix;
        // 4.获取今天是本月的第几天
        int dayOfMonth = now.getDayOfMonth();
        // 5.获取本月截止今天为止的所有的签到记录，返回的是一个十进制的数字 BITFIELD sign:5:202203 GET u14 0
        List<Long> result = stringRedisTemplate.opsForValue().bitField(
                key,
                BitFieldSubCommands.create()
                        .get(BitFieldSubCommands.BitFieldType.unsigned(dayOfMonth)).valueAt(0)
        );
        if (result == null || result.isEmpty()) {
            // 没有任何签到结果
            return Result.ok(0);
        }
        Long num = result.get(0);
        if (num == null || num == 0) {
            return Result.ok(0);
        }
        // 6.循环遍历
        int count = 0;
        while (true) {
            // 6.1.让这个数字与1做与运算，得到数字的最后一个bit位  // 判断这个bit位是否为0
            if ((num & 1) == 0) {
                // 如果为0，说明未签到，结束
                break;
            }else {
                // 如果不为0，说明已签到，计数器+1
                count++;
            }
            // 把数字右移一位，抛弃最后一个bit位，继续下一个bit位
            num >>>= 1;
        }
        return Result.ok(count);
    }

二、UV 统计

2.1 HyperLogLog 用法

2.1.1 相关概念

        UV：全称 Unique Visitor，也叫独立访客量，是指通过互联网访问、浏览这个网页的自然人。 1 天内同一个用户多次访问该网站，只记录 1 次。

        PV：全称 Page View，也叫页面访问量或点击量，用户每访问网站的一个页面，记录 1 次 PV，用户多次打开页面，则记录多次 PV。往往用来衡量网站的流量。

        UV 统计在服务端做会比较麻烦，因为要判断该用户是否已经统计过了，需要将统计过的用户信息保存。但是如果每个访问的用户都保存到 Redis 中，数据量会非常恐怖。

2.1.2 简介

        Hyperloglog(HLL) 是从 Loglog 算法派生的概率算法，用于确定非常大的集合的基数，而不需要存储其所有值。相关算法原理大家可以参考这篇文章。

        Redis 中的 HLL 是基于 string 结构实现的，单个 HLL 的内存永远小于 16kb，内存占用低的令人发指！作为代价，其测量结果是概率性的，有小于 0.81％ 的误差。不过对于 UV 统计来说，这完全可以忽略。

2.2 实现 UV 统计

        我们直接利用单元测试，向 HyperLogLog 中添加 100万 条数据，看看内存占用和统计效果如何，代码如下：

    @Test
    void testHyperLogLog() {
        // 准备数组，装用户数据
        String[] users = new String[1000];
        // 数组角标
        int index = 0;
        for (int i = 1; i <= 1000000; i++) {
            // 赋值
            users[index++] = "user_" + i;
            // 每1000条发送一次
            if (i % 1000 == 0) {
                index = 0;
                stringRedisTemplate.opsForHyperLogLog().add("hll1", users);
            }
        }
        // 统计数量
        Long size = stringRedisTemplate.opsForHyperLogLog().size("hll1");
        System.out.println("size = " + size);
    }

        可以看到，插入了 100w 条数据，最终统计的时候不到 100w，但是误差可以忽略。