业务背景

• QPS，日间峰值360, 夜间低谷80, 均值250

• PV 500W，带合作商信息的数据，预计在100W左右

• 数据实时性要求 5 分钟，准确性要求相对准确

数据收集链路

PV 统计实现方案

1. 消费数据时，保存到 mongo 后，计算得到对应的 key 集合中，value 使用 redis 的 INCR 自增，并将 key 保存到一个 特殊的 app:pv:keys 中(zset 结构)，score 为 yyyyMMddHHmm

2. 通过定时调度，每5分钟扫描 app:pv:keys 中分数 < 5分钟之前score 的 keys，遍历每个key，将对应的增量数据，刷入到数据库中，并从 app:pv:keys 删除（同时删除对应的 key）

3. 增加兜底调度，每天凌晨时刻，基于 MongoDB 中的数据重新统计前一天每个 partner 的 PV，更新到数据库中

1. 避免频繁的更新 mysql（每次pv + 1 都更新完全没必要）；

2. 通过时间分桶方式，等到每个分桶中的增量完全固定之后，再将桶内的数据加回到数据库，降低代码实现的复杂度（否则需要考虑对桶操作的加锁）

3. 每日兜底的重新统计任务，可以保证统计的数据准确性

1. mongo写入改为批量，INCR 前在内存中先小批次聚合一下，减少 io 次数

2. 如果 parnter 层级过多，子 partner 比较多时，考虑同时聚合后更新 父级partner 的 PV

UV 统计实现方案

1. 消费数据时，保存到 mongo 后，计算对应事件的 key，格式为 appns:uv:导流商id:日期(yyyyMMdd)，使用 PFADD KEY VALUE 命令，将对应的 openid 添加到指定的 HyperLogLog 中, 同时将 key 保存到 app:uv:keys:yyyyMMdd 集合中（只用redis的list）

2. 定时调度，每5分钟扫描当日的 app:uv:keys:yyyyMMdd，遍历其中的key，再次将数据刷回 mysql

3. 增加兜底调度，每天凌晨时刻，基于 MongoDB 中的数据重新统计前一天每个 partner 的 UV，更新到数据库中，同时清理昨日的 app:uv:keys:yyyyMMdd

1. 较与 set 或者 bitmap 实现形式，HyperLogLog 更加节省内存，标准的 0.81% 误差业务上能接受

1. 考虑在 应用内存中，积攒一小批后，通过 PFADD key element1 element2 element3 ... elementN 去操作 HyperLogLog

📎 参考文章

• https://www.bilibili.com/video/BV1Ux4y1H77m/?spm_id_from=333.337.search-card.all.click&vd_source=509f64c3fc3ec85e474fa08a78fb6ed6

• https://panzhongxian.cn/cn/2024/04/hll-simple-introduce/

• 一文理解 HyperLogLog(HLL) 算法 | 社区征文 - 文章 - 开发者社区 - 火山引擎

  一文理解 HyperLogLog(HLL) 算法 | 社区征文 - 文章 - 开发者社区 - 火山引擎

  HyperLogLog(HLL) 算法是一种估算海量数据基数的方法，被广泛用于各个数据库产品中。与精确的基数统计算法相比，HLL 具备可合并性 (mergeability) ，因而可以方便地对海量数据进行并行计算，被广泛地用于大数据多维分析场景中。例如分别统计一款 APP 每个小时的 UV 以及全天的 UV，这类问题就非常适合使用 HLL 算法。本文将会由浅入深，从基本概念讲起，引导读者从直观上理

  

• https://juejin.cn/post/6844903785744056333