亿级系统中常见的四种统计
聚合统计
- 统计多个集合元素的聚合结果,就是前面讲解过的交差并等集合统计
- 交并差集和聚合函数的应用
排序统计
- 抖音视频最新评论留言的场景,请你设计一个展现列表。考察你的数据结构和设计思路
- 设计案例和回答思路
- 以抖音vcr最新的留言评价为案例,所有评论需要两个功能,按照时间排序+分页显示
list
- 每个商品评价对应一个List集合,这个List包含了对这个商品的所有评论,而且会按照评论时间保存这些评论
- 每来一个新评论就用LPUSH命令把它插入List的队头。但是,如果在演示第二页前,又产生了一个新评论,第2页的评论不一样了。
- 原因:List是通过元素在List中的位置来排序的,当有一个新元素插入时,原先的元素在List中的位置都后移了一位,原来在第1位的元素现在排在了第2位,当LRANGE读取时,就会读到旧元素。
Zset
在⾯对需要展示最新列表、排行榜等场景时,如果数据更新频繁或者需要分页显示,建议使⽤ZSet
二值统计
- 集合元素的取值就只有0和1两种。在钉钉上班签到打卡的场景中,我们只用记录有签到(1)或没签到(0)
- 见bitmap
基数统计
bitmap
是什么
- 说明:用String类型作为底层数据结构实现的一种统计二值状态的数据类型
- 位图本质是数组,它是基于String数据类型的按位的操作。该数组由多个二进制位组成,每个二进制位都对应一个偏移量(我们可以称之为一个索引或者位格)。Bitmap支持的最大位数是232位,它可以极大的节约存储空间,使用512M内存就可以存储多大42.9亿的字节信息(232 = 4294967296)
- 由0和1状态表现的二进制位的bit数组
能干嘛
- 用户是否登陆过Y、N,比如京东每日签到送京豆
- 电影、广告是否被点击播放过
- 钉钉打卡上下班,签到统计
大厂真实案例
- 日活统计
- 连续签到打卡
- 最近一周的活跃用户
- 统计指定用户一年之中的登陆天数
- 某用户按照一年365天,哪几天登陆过?哪几天没有登陆?全年中登录的天数共计多少?
京东签到领取京豆
- 签到日历仅展示当月签到数据
- 签到日历需展示最近连续签到天数
- 假设当前日期是20210618,且20210616未签到
- 若20210617已签到且0618未签到,则连续签到天数为1
- 若20210617已签到且0618已签到,则连续签到天数为2
- 连续签到天数越多,奖励越大
- 所有用户均可签到
- 截至2020年3月31日的12个月,京东年度活跃用户数3.87亿,同比增长24.8%,环比增长超2500万,此外,2020年3月移动端日均活跃用户数同比增长46%假设10%左右的用户参与签到,签到用户也高达3千万
小厂方法,传统mysql方式
CREATE TABLE user_sign
(
keyid BIGINT NOT NULL PRIMARY KEY AUTO_INCREMENT,
user_key VARCHAR(200),#京东用户ID
sign_date DATETIME,#签到日期(20210618)
sign_count INT #连续签到天数
)
INSERT INTO user_sign(user_key,sign_date,sign_count)
VALUES ('20210618-xxxx-xxxx-xxxx-xxxxxxxxxxxx','2020-06-18 15:11:12',1);
SELECT
sign_count
FROM
user_sign
WHERE
user_key = '20210618-xxxx-xxxx-xxxx-xxxxxxxxxxxx'
AND sign_date BETWEEN '2020-06-17 00:00:00' AND '2020-06-18 23:59:59'
ORDER BY
sign_date DESC
LIMIT 1;
- 困难和解决思路
- 方法正确但是难以落地实现
- 签到用户量较小时这么设计能行,但京东这个体量的用户(估算3000W签到用户,一天一条数据,一个月就是9亿数据)
- 对于京东这样的体量,如果一条签到记录对应着当日用记录,那会很恐怖…
- 如何解决这个痛点?
- 一条签到记录对应一条记录,会占据越来越大的空间。
- 一个月最多31天,刚好我们的int类型是32位,那这样一个int类型就可以搞定一个月,32位大于31天,当天来了位是1没来就是0。
- 一条数据直接存储一个月的签到记录,不再是存储一天的签到记录。
大厂方法,基于Redis的Bitmaps实现签到日历
- 建表-按位-redis bitmap
- 在签到统计时,每个用户一天的签到用1个bit位就能表示,一个月(假设是31天)的签到情况用31个bit位就可以,一年的签到也只需要用365个bit位,根本不用太复杂的集合类型
基本命令
-
setbit
- setbit key offset value
- setbit 键 偏移位 只能零或者1
- Bitmap的偏移量是从零开始算的
-
getbit
- getbit key offset
-
setbit和getbit案例说明
- 按照天
- 按照年
- 按年去存储一个用户的签到情况,365 天只需要 365 / 8 ≈ 46 Byte,1000W 用户量一年也只需要 44 MB 就足够了。
- 假如是亿级的系统,
每天使用1个1亿位的Bitmap约占12MB的内存(10^8/8/1024/1024),10天的Bitmap的内存开销约为120MB,内存压力不算太高。在实际使用时,最好对Bitmap设置过期时间,让Redis自动删除不再需要的签到记录以节省内存开销。
-
bitmap的底层编码说明,get命令操作如何
- 实质是二进制的ascii编码对应
- redis里用type命令看看bitmap实质是什么类型???
- man ascii
-
strlen
- 不是字符串长度而是占据几个字节,超过8位后自己按照8位一组一byte再扩容
-
bitcount
- 全部键里面含有1的有多少个?
- 一年365天,全年天天登陆占用多少字节
hyperloglog
名词
- UV(Unique Visitor):独立访客,一般理解为客户端IP,需要去重考虑
- PV(需要去重考虑):页面浏览量,不用去重
- DAU(Daily Active User)
- 日活跃用户量:登录或者使用了某个产品的用户数(去重复登录的用户)
- 常用于反映网站、互联网应用或者网络游戏的运营情况
- MAU(MonthIy Active User):月活跃用户量
看需求
- 统计某个网站的UV、统计某个文章的UV
- 用户搜索网站关键词的数量
- 统计用户每天搜索不同词条个数
是什么
- 去重复统计功能的基数估计算法-就是HyperLogLog
- 基数
- 是一种数据集,去重复后的真实个数
- 基数统计:用于统计一个集合中不重复的元素个数,就是对集合去重复后剩余元素的计算
去重复统计你先会想到哪些方式?
- HashSet
- bitmap
-
bitmap是通过用位bit数组来表示各元素是否出现,每个元素对应一位,所需的总内存为N个bit。
-
基数计数则将每一个元素对应到bit数组中的其中一位,比如bit数组010010101(按照从零开始下标,有的就是1、4、6、8)。
-
新进入的元素只需要将已经有的bit数组和新加入的元素进行按位或计算就行。这个方式能大大减少内存占用且位操作迅速。
-
But,假设一个样本案例就是一亿个基数位值数据,一个样本就是一亿
如果要统计1亿个数据的基数位值,大约需要内存100000000/8/1024/1024约等于12M,内存减少占用的效果显著。 -
这样得到统计一个对象样本的基数值需要12M。
-
如果统计10000个对象样本(1w个亿级),就需要117.1875G将近120G,可见使用bitmaps还是不适用大数据量下(亿级)的基数计数场景,
-
但是bitmaps方法是精确计算的。
-
- 结论:样本元素越多内存消耗急剧增大,难以管控+各种慢,对于亿级统计不太合适,大数据害死人,o(╥﹏╥)o
- 解决方案:概率算法
- 通过牺牲准确率来换取空间,对于不要求绝对准确率的场景下可以使用,因为概率算法不直接存储数据本身
- 通过一定的概率统计方法预估基数值,同时保证误差在一定范围内,由于又不储存数据故此可以大大节约内存。
- HyperLogLog就是一种概率算法的实现。
HyPerLogLog如何做的?如何演化出来的?
- 基数统计就是HyperLogLog
- 原理说明
- 只是进行不重复的基数统计,不是集合也不保存数据,只记录数量而不是具体内容。
- 有误差
- 非精确统计
- 牺牲准确率来换取空间,误差仅仅只是0.81%左右
- 这个误差如何来的?论文地址和出处
- http://antirez.com/news/75
- Redis之父安蒂雷斯回答
- 经典面试题
为什么redis集群的最大槽数是16384个?- Redis集群并没有使用一致性hash而是引入了哈希槽的概念。Redis 集群有16384个哈希槽,每个key通过CRC16校验后对16384取模来决定放置哪个槽,集群的每个节点负责一部分hash槽。但为什么哈希槽的数量是16384(2^14)个呢?
- CRC16算法产生的hash值有16bit,该算法可以产生2^16=65536个值。换句话说值是分布在0~65535之间。那作者在做mod运算的时候,为什么不mod65536,而选择mod16384?
- 说明:
- 正常的心跳数据包带有节点的完整配置,可以用幂等方式用旧的节点替换旧节点,以便更新旧的配置。这意味着它们包含原始节点的插槽配置,该节点使用2k的空间和16k的插槽,但是会使用8k的空间(使用65k的插槽)。同时,由于其他设计折衷,Redis集群不太可能扩展到1000个以上的主节点。因此16k处于正确的范围内,以确保每个主机具有足够的插槽,最多可容纳1000个矩阵,但数量足够少,可以轻松地将插槽配置作为原始位图传播。请注意,在小型群集中,位图将难以压缩,因为当N较小时,位图将设置的slot / N位占设置位的很大百分比。
- 如果槽位为65536,发送心跳信息的消息头达8k,发送的心跳包过于庞大。在消息头中最占空间的是myslots[CLUSTER_SLOTS/8]。 当槽位为65536时,这块的大小是: 65536÷8÷1024=8kb 因为每秒钟,redis节点需要发送一定数量的ping消息作为心跳包,如果槽位为65536,这个ping消息的消息头太大了,浪费带宽。
- redis的集群主节点数量基本不可能超过1000个。集群节点越多,心跳包的消息体内携带的数据越多。如果节点过1000个,也会导致网络拥堵。因此redis作者不建议redis cluster节点数量超过1000个。 那么,对于节点数在1000以内的redis cluster集群,16384个槽位够用了。没有必要拓展到65536个。
- 槽位越小,节点少的情况下,压缩比高,容易传输。Redis主节点的配置信息中它所负责的哈希槽是通过一张bitmap的形式来保存的,在传输过程中会对bitmap进行压缩,但是如果bitmap的填充率slots / N很高的话(N表示节点数),bitmap的压缩率就很低。 如果节点数很少,而哈希槽数量很多的话,bitmap的压缩率就很低。
基本命令
案例实战:天猫网站首页亿级UV的Redis统计方案
需求
- UV的统计需要去重,一个用户一天内的多次访问只能算作一次
- 淘宝、天猫首页的UV,平均每天是1~1.5个亿左右
- 每天存1.5个亿的IP,访问者来了后先去查是否存在,不存在加入
方案讨论
- 用redis的hash结构存储
- redis——hash = <keyDay,<ip,1>>
- 按照ipv4的结构来说明,每个ipv4的地址最多是15个字节(ip = “192.168.111.1”,最多xxx.xxx.xxx.xxx)
- 某一天的1.5亿 * 15个字节= 2G,一个月60G,redis死定了。o(╥﹏╥)o
- hyperloglog
代码实现
HyperLogLogController
package com.learn.controller;
import io.swagger.annotations.Api;
import io.swagger.annotations.ApiOperation;
import lombok.extern.slf4j.Slf4j;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;
import javax.annotation.Resource;
/**
* @author YSK
* @since 2023/5/30 18:01
*/
@RestController
@Slf4j
@Api(description = "案例实战总03:天猫网站首页亿级UV的Redis统计方案")
public class HyperLogLogController {
@Resource
private RedisTemplate redisTemplate;
@ApiOperation("获得ip去重复后的首页访问量,总数统计")
@GetMapping(value = "/uv")
public long uv()
{
//pfcount
return redisTemplate.opsForHyperLogLog().size("hll");
}
}
HyperLogLogService
package com.learn.service;
import lombok.extern.slf4j.Slf4j;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.stereotype.Service;
import javax.annotation.PostConstruct;
import javax.annotation.Resource;
import java.util.Random;
import java.util.concurrent.TimeUnit;
/**
* @author YSK
* @since 2023/5/30 18:02
*/
@Service
@Slf4j
public class HyperLogLogService {
@Resource
private RedisTemplate redisTemplate;
/**
* 模拟有用户来点击首页,每个用户就是不同的ip,不重复记录,重复不记录
*/
@PostConstruct
public void init()
{
log.info("------模拟后台有用户点击,每个用户ip不同");
//自己启动线程模拟,实际上产不是线程
new Thread(() -> {
String ip = null;
for (int i = 1; i <=200; i++) {
Random random = new Random();
ip = random.nextInt(255)+"."+random.nextInt(255)+"."+random.nextInt(255)+"."+random.nextInt(255);
Long hll = redisTemplate.opsForHyperLogLog().add("hll", ip);
log.info("ip={},该ip访问过的次数={}",ip,hll);
//暂停3秒钟线程
try { TimeUnit.SECONDS.sleep(3); } catch (InterruptedException e) { e.printStackTrace(); }
}
},"t1").start();
}
}