Redis数据类型应用场景

在Redis中常用类型为五个String、List、Hash、Set、Sorted Set，扩展类型为三个GEO、BitMaps、HyperLogLog，那我们对这些类型的特性是否了解呢，什么业务场景下选择什么样的数据类型呢，下面借助多种常见业务场景聊聊数据类型的选择。

聚合计算

聚合计算就是指多个集合间的聚合结果如

交集：统计多个集合间的相同元素。
并集：统计多个集合间的所有元素，相同元素只显示一个。
差集：两个集合对比，统计一个集合对于另外一个集合独有的元素。

有聚合计算功能为Set、Sorted Set两个，但需要注意的是Sorted Set集合没有差集计算功能。

Set聚合运算命令如下

127.0.0.1:6379>?SADD?test1?1?2?3?4?5?6?7
(integer)?7
127.0.0.1:6379>?SADD?test2?3?5?2?9?10
(integer)?5
##?并集计算?如果想将结果存入单独的集合中可以使用SUNIONSTORE
##?SUNION时间复杂度O(N)????SUNIONSTORE时间复杂度O(N)
127.0.0.1:6379>?SUNION?test1?test2
1)?"1"
2)?"2"
3)?"3"
4)?"4"
5)?"5"
6)?"6"
7)?"7"
8)?"9"
9)?"10"
##?差集计算?如果想将结果存入单独的集合中可以使用SDIFFSTORE
##?SDIFF时间复杂度O(N)????SDIFFSTORE时间复杂度O(N)
127.0.0.1:6379>?SDIFF?test1?test2
1)?"1"
2)?"4"
3)?"6"
4)?"7"
##?交集计算?如果想将结果存入单独的集合中可以使用SINTERSTORE
##?SINTER?时间复杂度O(N*M)?N?为给定集合当中基数最小的集合，?M?为给定集合的个数
##?SINTERSTORE?时间复杂度O(N*M)
127.0.0.1:6379>?SINTER?test1?test2
1)?"2"
2)?"3"
3)?"5"

Sorted Set聚合命令如下

127.0.0.1:6379>?ZADD?test1?100?a?99?b?89?c?97?d?101?e
(integer)?5
127.0.0.1:6379>?zadd?test2?110?a?100?b?90?k?99?f
(integer)?4
######################################计算合集##########################
##?numkeys指参与计算key的数量，AGGREGATE统计方式默认是SUM??WEIGHTS指给每个集合元素的score乘上weight（乘法因子）
##?ZUNIONSTORE?destination?numkeys?key?[key?...]?[WEIGHTS?weight]?[AGGREGATE?SUM|MIN|MAX]
##?时间复杂度O(N)+O(Mlog(M))， N为给定有序集基数的总和， M为结果集的基数。
127.0.0.1:6379>?ZUNIONSTORE?test3?5?test1?test2?weights?1?1
(integer)?7
127.0.0.1:6379>?ZRANGE?test3?0?-1?withscores
?1)?"c"
?2)?"89"
?3)?"k"
?4)?"90"
?5)?"d"
?6)?"97"
?7)?"f"
?8)?"99"
?9)?"e"
10)?"101"
11)?"b"
12)?"199"
13)?"a"
14)?"210"
######################################计算并集##########################
##?ZINTERSTORE?destination?numkeys?key?[key?...]?[WEIGHTS?weight]?[AGGREGATE?SUM|MIN|MAX]
##?时间复杂度O(N*K)+O(Mlog(M))， N为给定key中基数最小的有序集， K为给定有序集的数量， M为结果集的基数。
127.0.0.1:6379>?ZINTERSTORE?test3?2?test1?test2?weights?1?1?aggregate?max
(integer)?2
127.0.0.1:6379>?
127.0.0.1:6379>?
127.0.0.1:6379>?ZRANGE?test3?0?-1
1)?"b"
2)?"a"
127.0.0.1:6379>?ZRANGE?test3?0?-1?withscores
1)?"b"
2)?"100"
3)?"a"
4)?"110"

不论是Set还是Sorted Set在聚合运算时的时间复杂度都是较高的，对于大数据的运算就会阻塞主线程。

如果Redis采用的是主从模式建议采用从库计算，但从库计算一定需要注意的是从库不允许写只允许读所以对于SUNIONSTORE、SDIFFSTORE、SINTERSTORE、ZUNIONSTORE、ZINTERSTORE这类需要写入目标集合的命令显然是不可行的，需要根据业务进行取舍。

如果采用的是Cluster集群模式，去执行聚合统计那么可能发生错误，因为聚合包含的key可能不在同一个实例中导致报错，演示如下。

在Cluster集群中存在主节点7002、7003、7004详细信息如下所示。

###?在集群7004中新增set集合key为test
127.0.0.1:7004>?SADD?test?1?2?3?4?5?6?7?8?0?10?5?15?12?13
(integer)?13
###?在集群7003中新增set集合key为test1
127.0.0.1:7003>?SADD?test1?11?4515?12?13
(integer)?4
###?在集群7003中执行聚合命令，报错！！！！！！！
127.0.0.1:7003>?SUNION?test1?test
(error)?CROSSSLOT?Keys?in?request?don't?hash?to?the?same?slot

所以建议把这些统计数据与在线业务数据拆分开，实例单独部署，防止在做统计操作时影响到在线业务。

排序统计

对于排序有很多业务场景如小说热榜、排行榜等，在Redis中具排序功能的是Sorted Set和List，需要注意的是List没有排序命令而是根据写入顺序排序，而Sorted Set则可以通过权重进行排序。

List命令演示如下，如果元素是按顺序入队那么统计没有问题，但如果是中间插入数据需要人为判断过于复杂，在排序统计中不建议使用。

127.0.0.1:6379>?lpush?test?1?2?3?4?5?6?7
(integer)?7
127.0.0.1:6379>?LRANGE?test?0?-1
1)?"7"
2)?"6"
3)?"5"
4)?"4"
5)?"3"
6)?"2"
7)?"1"
127.0.0.1:6379>?rpush?test?0
(integer)?8
127.0.0.1:6379>?LRANGE?test?0?-1
1)?"7"
2)?"6"
3)?"5"
4)?"4"
5)?"3"
6)?"2"
7)?"1"
8)?"0"
127.0.0.1:6379>?lpush?test?-1
(integer)?9
127.0.0.1:6379>?
127.0.0.1:6379>?LRANGE?test?0?-1
1)?"-1"
2)?"7"
3)?"6"
4)?"5"
5)?"4"
6)?"3"
7)?"2"
8)?"1"
9)?"0"

Sorted Set命令演示如下，Sorted Set无论以怎样的方式插入集合都会根据权重进行排序，非常适用于各种排序统计逻辑。

127.0.0.1:6379>?ZADD?test?100??a?80?b?99?c?109?d?40?f?77?h
(integer)?6
127.0.0.1:6379>?ZRANGEBYSCORE?test?-inf?+inf?withscores
?1)?"f"
?2)?"40"
?3)?"h"
?4)?"77"
?5)?"b"
?6)?"80"
?7)?"c"
?8)?"99"
?9)?"a"
10)?"100"
11)?"d"
12)?"109"
127.0.0.1:6379>?ZADD?test?78?q
(integer)?1
127.0.0.1:6379>?
###?ZRANGE和ZRANGEBYSCORE的不同点在于ZRANGE是根据下标范围查询列表
###?ZRANGEBYSCORE根据scores范围查询列表
127.0.0.1:6379>?ZRANGE?test?0?-1
1)?"f"
2)?"h"
3)?"q"
4)?"b"
5)?"c"
6)?"a"
7)?"d"
127.0.0.1:6379>?ZRANGE?test?0?-1?withscores
?1)?"f"
?2)?"40"
?3)?"h"
?4)?"77"
?5)?"q"
?6)?"78"
?7)?"b"
?8)?"80"
?9)?"c"
10)?"99"
11)?"a"
12)?"100"
13)?"d"
14)?"109"

二值状态统计

二值指的是值只有两种状态，最典型的例子就是签到统计，统计是否签到只需要两种状态是和否，只要涉及到两种状态的都可以采用如下的形式。

二值统计可以使用Bitmap来做统计，Bitmap其底层就是String，String类型会被保存为一个字符数组buf[]，而Bitmap就是利用这一特性将数组的每一个bit位利用起来，用来表示一个元素的二值状态，所以可以将Bitmap理解为是一个字符数组构成的。

如需要统计用户id为10001的4月打卡情况可以如下模拟

###?因为Bitmap的offset从0开始，所以在统计的时候从0开始计算
127.0.0.1:6379>?SETBIT?sign:user:10001:202204?0??1
(integer)?0
127.0.0.1:6379>?SETBIT?sign:user:10001:202204?1??1
(integer)?0
127.0.0.1:6379>?SETBIT?sign:user:1000:2022041?2??1
(integer)?0
127.0.0.1:6379>?SETBIT?sign:user:10001:202204?4??1
(integer)?0
127.0.0.1:6379>?SETBIT?sign:user:10001:202204?5??1
(integer)?0
###?统计bit位为1的个数，统计已签到次数
127.0.0.1:6379>?BITCOUNT?sign:user:10001:202204
(integer)?5

如果需要统计4月有多少个用户连续签到，这个可以利用Bitmap的按位运算的特性计算，将key按照时间划分进行统计，采用BITOP做按位运算

BITOP operation destkey key [key …]

operation 支持四种参数

BITOP AND destkey srckey1 srckey2 srckey3 ... srckeyN ，对一个或多个 key 求逻辑并（同为1才为1、只要有0就为0），并将结果保存到 destkey 。

BITOP OR destkey srckey1 srckey2 srckey3 ... srckeyN，对一个或多个 key 求逻辑或（同为0才为0、只要有1就为1），并将结果保存到 destkey 。

BITOP XOR destkey srckey1 srckey2 srckey3 ... srckeyN，对一个或多个 key 求逻辑异或（相异为1、相同为0），并将结果保存到 destkey 。

BITOP NOT destkey srckey，对给定 key 求逻辑非，并将结果保存到 destkey 。

###?采用日期作为key，每个bit位就是一个用户，这样计算占用内存小同时效率高
127.0.0.1:6379>?SETBIT?20220401?0?1
(integer)?0
127.0.0.1:6379>?SETBIT?20220401?1?1
(integer)?0
127.0.0.1:6379>?SETBIT?20220401?2?1
(integer)?0
127.0.0.1:6379>?SETBIT?20220401?3?1
(integer)?0
127.0.0.1:6379>?SETBIT?20220401?4?0
(integer)?0
127.0.0.1:6379>?SETBIT?20220402?0?0
(integer)?1
127.0.0.1:6379>?SETBIT?20220402?1?1
(integer)?0
127.0.0.1:6379>?SETBIT?20220402?2?1
(integer)?0
127.0.0.1:6379>?SETBIT?20220402?3?0
(integer)?0
127.0.0.1:6379>?SETBIT?20220402?4?1
###?按位运算，每天都签到那么对应每天的日期key上相同bit为应都为1
127.0.0.1:6379>?BITOP?and?test?20220402?20220401
(integer)?1
127.0.0.1:6379>?BITCOUNT?test?0?-1
(integer)?2
127.0.0.1:6379>?

基数统计

首先需要了解的是什么为基数，基数就是不会重复的数字，对于基数统计就是统计元素中不会重复的元素，常见于网站的PV（网页点击量一个用户一天内点击多次也只算一次）、UV（独立访客数，一个用户一天内进入多次也只计算一次）统计，这个统计其实方案有很多，如Set、HyperLogLog，甚至可以使用Hash。

Set方案

Set集合本来就是可以去重的，所以在计算时只要将用户id设置到集合中即可

###?用户1001?20220401?访问page1页面
127.0.0.1:6379>?SADD?web:page1:20220401?1001
(integer)?1
###?用户1002?20220401?访问page1页面
127.0.0.1:6379>?SADD?web:page1:20220401?1002
(integer)?1
###?用户1001?20220401?访问page1页面
127.0.0.1:6379>?SADD?web:page1:20220401?1001
(integer)?0
###?统计pv数
127.0.0.1:6379>?SCARD?web:page1:20220401
(integer)?2
127.0.0.1:6379>?
127.0.0.1:6379>?SMEMBERS?web:page1:20220401
1)?"1001"
2)?"1002"

###?用户1001?20220401?进入系统
127.0.0.1:6379>?SADD?web:user:20220401?1001
(integer)?1
###?用户1002?20220401?进入系统
127.0.0.1:6379>?SADD?web:user:20220401?1002
(integer)?1
###?用户1001?20220401?进入系统
127.0.0.1:6379>?SADD?web:user:20220401?1001
(integer)?0
###?统计uv数
127.0.0.1:6379>?SCARD?web:user:20220401
(integer)?2

Hash方案

Hash方案和Set方案类型，Hash方案是利用了Hash中的属性不能重复的特性来处理。

###?用户1001?20220401?访问page1页面
127.0.0.1:6379>?HSET?web:page1:20220401?1001?1
(integer)?1
###?用户1002?20220401?访问page1页面
127.0.0.1:6379>?HSET?web:page1:20220401?1002?1
(integer)?1
###?用户1001?20220401?访问page1页面
127.0.0.1:6379>?HSET?web:page1:20220401?1001?1
(integer)?0
###?统计pv数
127.0.0.1:6379>?HLEN?web:page1:20220401
(integer)?2
###?uv类似

HyperLogLog方案

无论是hash方案还是set方案如果用户数据量逐渐增加，集合的内存消耗也将大幅度提升会出现bigkey的情况，再来看看HyperLogLog，redis官网这样描述：

A HyperLogLog is a probabilistic data structure used in order to count unique things (technically this is referred to estimating the cardinality of a set). Usually counting unique items requires using an amount of memory proportional to the number of items you want to count, because you need to remember the elements you have already seen in the past in order to avoid counting them multiple times. However there is a set of algorithms that trade memory for precision: you end with an estimated measure with a standard error, in the case of the Redis implementation, which is less than 1%. The magic of this algorithm is that you no longer need to use an amount of memory proportional to the number of items counted, and instead can use a constant amount of memory! 12k bytes in the worst case, or a lot less if your HyperLogLog (We’ll just call them HLL from now) has seen very few elements.

译：

HyperLogLog是一种概率数据结构，用于计算唯一的东西(从技术上讲，这指的是估计集合的基数)。通常计算唯一的条目需要使用与要计算的条目数量成比例的内存，因为您需要记住过去已经看到的元素，以避免多次计算它们。然而有一套算法可以用精度换内存，在Redis实现的情况下，你会得到一个标准误差的估计值，误差小于1%。这个算法的神奇之处在于，您不再需要使用与所计数的项目数量成比例的内存，而是可以使用恒定的内存数量!最坏情况下是12k字节，HyperLogLog(从现在开始我们就称它们为HLL)只看到的元素则会少很多。

HyperLogLog代码演示如下

127.0.0.1:6379>?info?memory
#?Memory??初始内存容量
used_memory:927936

#?Memory?第一次添加内存容量
127.0.0.1:6379>?PFADD?web:pv:20220424?1001?1002?1003?1004?1005?1006?1007
(integer)?1
127.0.0.1:6379>?info?memory
used_memory:928080

#?Memory?第二次添加内存容量
127.0.0.1:6379>?PFADD?web:pv:20220424?10101?10102?10103?10104?10105?10106?10017
(integer)?1
127.0.0.1:6379>?info?memory
used_memory:928128

#?Memory?第二次添加内存容量
127.0.0.1:6379>?PFADD?web:pv:20220424?1041201?1042102?1012403?1012404?1012405?1012406?1002317
(integer)?1
127.0.0.1:6379>?info?memory
used_memory:928224

#?Memory?第二次添加内存容量
127.0.0.1:6379>?PFADD?web:pv:20220424?10415201?10425102?10152403?10512404?10125405?10124506?10052317
(integer)?1
127.0.0.1:6379>?info?memory
used_memory:928224

################后续持续加入基数，内存容量保持928224不变基数查询正常#############

###?基数查询
127.0.0.1:6379>?PFCOUNT?web:pv:20220424
(integer)?49

HyperLogLog就是概率性的结构，采取精度换空间的形式，内存消耗是固定的不会随着基数的增加内存增大，所以在业务要求数据精度不高的情况下如统计网站pv、uv这类业务完全可以使用HyperLogLog解决，但如果业务要求精度过高则还是采用Set或者Hash数据类型较为稳妥。