1 |
|
PFMERGE 使用场景
HyperLogLog 除了上面的 PFADD 和 PFCOIUNT 外，还提供了 PFMERGE ，将多个 HyperLogLog 合并在一起形成一个新的 HyperLogLog 值。
语法
1 |
|
使用场景
比如在网站中我们有两个内容差不多的页面，运营说需要这两个页面的数据进行合并。
其中页面的 UV 访问量也需要合并，那这个时候 PFMERGE 就可以派上用场了，也就是同样的用户访问这两个页面则只算做一次。
如下所示：Redis、MySQL 两个 Bitmap 集合分别保存了两个页面用户访问数据。
1 2 3 4 |
|
将多个 HyperLogLog 合并（merge）为一个 HyperLogLog ， 合并后的 HyperLogLog 的基数接近于所有输入 HyperLogLog 的可见集合（observed set）的并集。
user1、user2 都访问了 Redis 和 MySQL，只算访问了一次。
排序统计
Redis 的 4 个集合类型中（List、Set、Hash、Sorted Set），List 和 Sorted Set 就是有序的。
- List：按照元素插入 List 的顺序排序，使用场景通常可以作为 消息队列、最新列表、排行榜；
- Sorted Set：根据元素的 score 权重排序，我们可以自己决定每个元素的权重值。使用场景（排行榜，比如按照播放量、点赞数）。
最新评论列表
码老湿，我可以利用 List 插入的顺序排序实现评论列表
比如微信公众号的后台回复列表（不要杠，举例子），每一公众号对应一个 List，这个 List 保存该公众号的所有的用户评论。
每当一个用户评论，则利用 LPUSH key value [value ...] 插入到 List 队头。
1 |
|
接着再用 LRANGE key star stop 获取列表指定区间内的元素。
1 2 3 4 5 6 |
|
注意，并不是所有最新列表都能用 List 实现，对于因为对于频繁更新的列表，list类型的分页可能导致列表元素重复或漏掉。
比如当前评论列表 List =｛A, B, C, D｝，左边表示最新的评论，D 是最早的评论。
1 |
|
展示第一页最新 2 个评论，获取到 A、B：
1 2 3 |
|
按照我们想要的逻辑来说，第二页可通过 LRANGE 码哥字节 2 3 获取 C，D。
如果在展示第二页之前，产生新评论 E，评论 E 通过 LPUSH 码哥字节 E 插入到 List 队头，List = ｛E, A, B, C, D ｝。
现在执行 LRANGE 码哥字节 2 3 获取第二页评论发现， B 又出现了。
1 2 3 |
|
出现这种情况的原因在于 List 是利用元素所在的位置排序，一旦有新元素插入，List = ｛E，A，B，C，D｝。
原先的数据在 List 的位置都往后移动一位，导致读取都旧元素。
小结
只有不需要分页（比如每次都只取列表的前 5 个元素）或者更新频率低（比如每天凌晨统计更新一次）的列表才适合用 List 类型实现。
对于需要分页并且会频繁更新的列表，需用使用有序集合 Sorted Set 类型实现。
另外，需要通过时间范围查找的最新列表，List 类型也实现不了，需要通过有序集合 Sorted Set 类型实现，如以成交时间范围作为条件来查询的订单列表。
排行榜
码老湿，对于最新列表的场景，List 和 Sorted Set 都能实现，为啥还用 List 呢？直接使用 Sorted Set 不是更好，它还能设置 score 权重排序更加灵活。
原因是 Sorted Set 类型占用的内存容量是 List 类型的数倍之多，对于列表数量不多的情况，可以用 Sorted Set 类型来实现。
比如要一周音乐榜单，我们需要实时更新播放量，并且需要分页展示。
除此以外，排序是根据播放量来决定的，这个时候 List 就无法满足了。
我们可以将音乐 ID 保存到 Sorted Set 集合中，score 设置成每首歌的播放量，该音乐每播放一次则设置 score = score +1。
ZADD
比如我们将《青花瓷》和《花田错》播放量添加到 musicTop 集合中：
1 |
|
ZINCRBY
《青花瓷》每播放一次就通过 ZINCRBY指令将 score + 1。
1 2 |
|
ZRANGEBYSCORE
最后我们需要获取 musicTop 前十播放量音乐榜单，目前最大播放量是 N ，可通过如下指令获取：
1 |
|
65哥：可是这个 N 我们怎么获取呀？
ZREVRANGE
可通过 ZREVRANGE key start stop [WITHSCORES]指令。
其中元素的排序按 score 值递减(从大到小)来排列。
具有相同 score 值的成员按字典序的逆序(reverse lexicographical order)排列。
1 2 3 |
|
小结
即使集合中的元素频繁更新，Sorted Set 也能通过 ZRANGEBYSCORE 命令准确地获取到按序排列的数据。
在面对需要展示最新列表、排行榜等场景时，如果数据更新频繁或者需要分页显示，建议优先考虑使用 Sorted Set。
聚合统计
指的就是统计多个集合元素的聚合结果，比如说：
- 统计多个元素的共有数据（交集）；
- 统计两个集合其中的一个独有元素（差集统计）；
- 统计多个集合的所有元素（并集统计）。
码老湿，什么样的场景会用到交集、差集、并集呢？
Redis 的 Set 类型支持集合内的增删改查，底层使用了 Hash 数据结构，无论是 add、remove 都是 O(1) 时间复杂度。
并且支持多个集合间的交集、并集、差集操作，利用这些集合操作，解决上边提到的统计问题。
交集-共同好友
比如 QQ 中的共同好友正是聚合统计中的交集。我们将账号作为 Key，该账号的好友作为 Set 集合的 value。
模拟两个用户的好友集合：
1 2 |
|
统计两个用户的共同好友只需要两个 Set 集合的交集，如下命令：
1 |
|
命令的执行后，「user:码哥字节」、「user:大佬」两个集合的交集数据存储到 user:共同好友这个集合中。
差集-每日新增好友数
比如，统计某个 App 每日新增注册用户量，只需要对近两天的总注册用户量集合取差集即可。
比如，2021-06-01 的总注册用户量存放在 key = user:20210601 set 集合中，2021-06-02 的总用户量存放在 key = user:20210602 的集合中。
如下指令，执行差集计算并将结果存放到 user:new 集合中。
1 |
|
执行完毕，此时的 user:new 集合将是 2021/06/02 日新增用户量。
除此之外，QQ 上有个可能认识的人功能，也可以使用差集实现，就是把你朋友的好友集合减去你们共同的好友即是可能认识的人。
并集-总共新增好友
还是差集的例子，统计 2021/06/01 和 2021/06/02 两天总共新增的用户量，只需要对两个集合执行并集。
1 |
|
此时新的集合 userid:new 则是两日新增的好友。
小结
Set 的差集、并集和交集的计算复杂度较高，在数据量较大的情况下，如果直接执行这些计算，会导致 Redis 实例阻塞。
所以，可以专门部署一个集群用于统计，让它专门负责聚合计算，或者是把数据读取到客户端，在客户端来完成聚合统计，这样就可以规避由于阻塞导致其他服务无法响应。
更多编程相关知识，请访问：编程视频！！
以上就是手把手教你使用Redis实现亿级数据统计（实战）的详细内容，更多文章请关注木庄网络博客！
相关阅读 >>
更多相关阅读请进入《Redis》频道 >>
数据库系统概念 第6版
本书主要讲述了数据模型、基于对象的数据库和XML、数据存储和查询、事务管理、体系结构等方面的内容。
