用户不存在,那么必然没可能签到, 两个集合的对应位都是0,结果为0.
所以结果中,为1的只有一种可能:用户存在且没有签到,正好是我们所求的结果..... -> 有限制,但是业务中很多数据都可以转换为布尔类型.比如上面的例子中, 业务原意:用户每天的签到记录,以用户为维度. 我们可以转换为: 每天的每个用户是否签到,就变为了布尔类型的数据....我们使用JDK中的BitSet来试一下,在运行过程中打断点看一下内部的数组是什么样子.如下图:
将其序列化输出到文件,文件大小如下图:
可以看到,我们为了保存1和1亿这两个数字,花费了一个一千多万长度的...可以看到long数组的长度仅仅为4,且输出的文件大小为96byte.
这就很符合预期了....用户签到/抢购等唯一限制
用户签到每天只能一次,抢购活动中只能购买一件,这些需求导致的有一种查询请求,给定的id做没做过某事.而且一般这种需求都无法接受你去查库的延迟.当然你查一次库之后在redis中写入