前言
不知你大规模的用过 Redis 吗？还是仅仅作为缓存的工具了？在 Redis 中应用最多的就是汇合了，举个例子，如下场景：
- 签到零碎中，一天对应一系列的用户签到记录。
- 电商零碎中，一个商品对应一系列的评论。
- 交友零碎中，某个用户的一系列的好友。
Redis 中汇合的特点无非是一个 Key 对应一系列的数据，然而数据的作用往往是为了统计的，比方：
- 交友零碎中，须要统计每天的新增好友，以及单方的独特好友。
- 电商零碎中，须要统计评论列表中的最新评论。
- 签到零碎中，须要统计间断一个月的签到的用户数量。
大型互联网利用中，数据量是微小的，少说百万，千万，甚至是一个亿，比方电商巨头淘宝，交友巨头微信、微博；办公巨头钉钉等，哪一个的用户不是上亿？
只有针对不同场景，抉择适合的汇合，统计能力更不便。
聚合统计
聚合统计 指的是多个元素聚合的后果，比方统计多个汇合的 交加 、 并集 、 差集
在你须要对多个汇合做聚合统计的时候，Set 汇合是个不错的抉择，除了其中无反复的数据外，Redis 还提供了对应的 API
交加
在上述的例子中交友零碎中统计单方的独特好友正是聚合统计中的 交加。
在 Redis 中能够 userid 作为 key，好友的userid 作为value，如下图：
统计两个用户的独特好友只须要两个 Set 汇合的交加，命令如下；
`SINTERSTORE userid:new userid:20002 userid:20003
`
上述命令运行实现后，userid:new这个 key 中存储的将是 userid:20002、userid:20003 两个汇合的交加。
差集
举个例子：假如交友零碎中须要统计每日新增的好友，此时就须要对邻近两天的好友汇合取差集了，比方 2020/11/1 日的好友是 set1，2020/11/2 日的好友是 set2，此时只须要对set1 和set2做差集。
此时的构造应该如何设计呢？如下图：
userid:20201101这个 key 记录了 userid 用户的 2020/11/1 日的好友汇合。
差集很简略，只须要执行 SDIFFSTORE 命令，如下：
SDIFFSTORE user:new userid:20201102 userid:20201101
执行结束，此时的 user:new 这汇合将是 2020/11/2 日新增的好友。
这里还有一个更贴切的例子，微博上有个可能意识的人性能，能够应用差集，即是你敌人的好友减去你们独特的好友即是可能意识的人。
并集
还是差集的那个例子，假如须要统计 2020/11/01 和2020/11/2总共新增的好友，此时只须要对这两日新增好友的汇合做一个并集。命令如下：
`SUNIONSTORE userid:new userid:20201102 userid:20201101
`
此时新的汇合 userid:new 则是两日新增的好友。
总结
Set汇合的交差并的计算复杂度很高，如果数据量很大的状况下，可能会造成 Redis 的阻塞。
那么如何躲避阻塞呢？倡议如下：
- 在
Redis集群当选一个从库专门负责聚合统计，这样就不会阻塞主库和其余的从库了 - 将数据交给客户端，由客户端进行聚合统计。
排序统计
在一些电商网站中能够看到商品的评论总是最新的在下面，这个是怎么做的呢？
最新评论列表蕴含了所有的评论，这就要 汇合对元素进行保序存储 了。也就是说汇合中的元素必须按序存储，称之为有序汇合。
Redis中的四种汇合中 List 和Sorted Set属于有序汇合。
然而 List 和Sorted Set有何区别呢？到底应用哪一种呢？
List 是依照元素进入程序进行排序，而 Sorted Set 能够依据元素权重来排序。 比方能够依据元素插入汇合的工夫确定权值，先插入的元素权重小，后插入的元素权重大。
针对这一例子中，显然这两种都是可能满足要求的，List 中分页查问命令 LRANGE 和Sorted Set分页查问命令ZRANGEBYSCORE。
然而就灵活性来说，List 必定不适宜，List 只能依据先后插入的程序排序，然而大多数的场景中可能并不只是依照工夫先后排序，可能还会依照一些特定的条件，此时 Sorted Set 就很适合了，只须要依据独有的算法生成相应的权重即可。
二值状态统计
二值状态指的是取值 0 或者 1 两种；在签到打卡的场景中，只须要记录签到（1）和未签到（0）两种状态，这就是典型的二值状态统计。
二值状态的统计能够应用 Redis 的扩大数据类型 Bitmap，底层应用String 类型实现，能够把它看成是一个 bit 数组。对于具体内容后续介绍 ………
在签到统计中，0和 1 只占了一个 bit，即便一年的签到数据才 365 个bit 位。大大减少了存储空间。
Bitmap 提供了 GETBIT/SETBIT 操作，应用一个偏移值 offset 对 bit 数组的某一个 bit 位进行读和写。不过，须要留神的是，Bitmap 的偏移量是从 0 开始算的，也就是说 offset 的最小值是 0。当应用 SETBIT 对一个 bit 位进行写操作时，这个 bit 位会被设置为 1。Bitmap 还提供了 BITCOUNT 操作，用来统计这个 bit 数组中所有1 的个数。
键值如何设计呢？key 能够是 userid:yyyyMM，即是惟一 id 加上月份。假如员工 id 为10001，须要统计2020/11 月份的签到打卡记录。
第一步，执行命令设置值，假如 11 月 2 号打卡了，命令如下：
SETBIT userid:10001:202011 1 1
BitMap 是从下标 0 开始，因而 2 号则是下标为 1，值设置为 1 则示意胜利打卡了。
第二步，查看该用户 11 月 2 号是否打卡了，命令如下：
GETBIT userid:10001:202011 1
第三步，统计 11 月的打卡次数，命令如下：
`BITCOUNT userid:10001:202011
`
那么问题来了，须要统计你这个签到零碎中间断 20 天的签到打卡的用户的总数，如何解决呢？假如用户一个亿。
比方须要统计 2020/11/01 到2020/11/20天中间断打卡的人数，如何统计呢？
Bitmap中还反对同时对多个 BitMap 按位做 与、或 、 异或 操作，命令如下图：
思路来了，咱们能够将每天的日期作为一个 key，对应的BitMap 存储一亿个用户当天的打卡状况。如下图：
此时咱们只须要对 2020/11/1 到2020/11/20号的 Bitmap 做按位 与操作，最终失去的一个 Bitmap 中每个 bit 地位对应的值则代表间断 20 天打卡的状况，只有间断 20 天全副打卡，所在的 bit 位的值才为 1。如下图：
最终能够应用 BITCOUNT 命令进行统计。
能够尝试计算下内存开销，每天应用 1 个 1 亿位的 Bitmap，大概占 12MB 的内存（10^8/8/1024/1024），20 天的 Bitmap 的内存开销约为 240MB，内存压力不算太大。不过，在理论利用时，最好对 Bitmap 设置过期工夫，让 Redis 主动删除不再须要的签到记录，以节俭内存开销。
如果波及到二值状态，比方用户是否存在，签到打卡，商品是否存在等状况能够应用 Bitmap，能够无效的节俭内存空间。
基数统计
基数统计指统计一个汇合中不反复元素的个数。
举个栗子：电商网站中通常须要统计每个网页的 UV 来确定权重，网页的 UV 必定是须要去重的，在 Redis 类型中 Set 反对去重，第一工夫必定想到的是 Set。
然而这里有一个问题，Set底层应用的是哈希表和整数数组，如果一个网页的 UV 达到千万级别的话（一个电商网站中何止一个页面），那么对于内存的耗费极大。
Redis 提供了一个扩大类型 HyperLogLog 用于基数统计，计算 2^64 个元素大略只须要 12KB 的内存空间
是不是很心动？然而 HyperLogLog 是存在误差 的，大略是在0.81%，如果须要精准的统计，还是须要应用Set。对于这种网页的 UV 来说，足够了。
在统计网页 UV 的时候，只须要将用户的惟一 id 存入 HyperLogLog 中，如下：
`PFADD p1:uv 10001 10002 10003 10004
`
如果存在反复的元素，将会主动去重。
统计也很简略，应用 PFCOUNT 命令，如下：
`PFCOUNT p1:uv
`
总结
本文介绍了统计的几种类型以及应该用什么汇合存储，为了不便了解，作者将反对状况和优缺点汇总了一张表格，如下图：
Set和 Sorted Set 反对交加、并集的聚合运算，然而 Sorted Set 不支差集运算。
Bitmap也能对多个 Bitmap 做与、异或、或的聚合运算。
List和 SortedSet 都反对排序统计，然而 List 是依据元素先后插入程序排序，Sorted Set 反对权重，绝对于 List 排序来说更加灵便。
对于二值状态统计，判断某个元素是否存在等场景，倡议应用Bitmap，节俭的内存空间。
对于基数统计，在大数据量、不要求精准的状况倡议应用 HyperLogLog，节俭内存空间；对于精准的基数统计，最好还是应用Set 汇合。