关于redis:给你一个亿的keysRedis如何统计

前言

不知你大规模的用过 Redis 吗？还是仅仅作为缓存的工具了？在 Redis 中应用最多的就是汇合了，举个例子，如下场景：

1. 签到零碎中，一天对应一系列的用户签到记录。
2. 电商零碎中，一个商品对应一系列的评论。
3. 交友零碎中，某个用户的一系列的好友。

Redis 中汇合的特点无非是一个 Key 对应一系列的数据，然而数据的作用往往是为了统计的，比方：

1. 交友零碎中，须要统计每天的新增好友，以及单方的独特好友。
2. 电商零碎中，须要统计评论列表中的最新评论。
3. 签到零碎中，须要统计间断一个月的签到的用户数量。

大型互联网利用中，数据量是微小的，少说百万，千万，甚至是一个亿，比方电商巨头淘宝，交友巨头微信、微博；办公巨头钉钉等，哪一个的用户不是上亿？

只有针对不同场景，抉择适合的汇合，统计能力更不便。

聚合统计

聚合统计 指的是多个元素聚合的后果，比方统计多个汇合的 交加 、 并集 、 差集

在你须要对多个汇合做聚合统计的时候，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 的阻塞。

那么如何躲避阻塞呢？倡议如下：

1. 在 Redis 集群当选一个从库专门负责聚合统计，这样就不会阻塞主库和其余的从库了
2. 将数据交给客户端，由客户端进行聚合统计。

排序统计

在一些电商网站中能够看到商品的评论总是最新的在下面，这个是怎么做的呢？

最新评论列表蕴含了所有的评论，这就要 汇合对元素进行保序存储 了。也就是说汇合中的元素必须按序存储，称之为有序汇合。

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 汇合。