Android 开发高手课
张绍文
前微信高级工程师,Tinker 负责人
52722 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 62 讲
导读 (1讲)
模块一 高质量开发 (25讲)
Android 开发高手课
15
15
1.0x
00:00/00:00
登录|注册

30 | 数据评估(上):如何实现高可用的上报组件?

容灾监控
质量监控
容灾策略
多进程写 + 单进程上报
班车制度模式
上报实时性
上报数据优先级
埋点数据的聚合
多进程写 + mmap
进程和存储模式选择
采样率控制参数
UV采样
PV次数采样
高性能
实时性高
数据不会丢失
埋点进程突然崩溃
采样策略的更新
实践体会
细节和暗坑
先进的方案
数据自监控
容灾模块
上报模块
存储模块
采样模块
目标
准确性
时效性
课后作业
总结
统一高可用的上报组件
数据的重要性
手把手教你打造数据上报组件

该思维导图由 AI 生成,仅供参考

无论是“高效测试”中的实时监控,还是“版本发布”中的数据校验平台,我都多次提到了数据的重要性。
对于数据评估,我们的期望是“又快又准”。“快”,表示数据的时效性。我们希望在 1 小时内,甚至 1 分钟内就可以对数据进行评估,而不需要等上 1 天或者几天。“准”,表示数据的准确性,保证数据可以反映业务的真实情况,不会因为数据不准确导致做出错误的产品决策。
但是“巧妇难为无米之炊”,数据平台的准确性和时效性依赖客户端数据采集和上报的能力。那应该如何保证客户端上报组件的实时性和准确性?如何实现一个“高可用”的上报组件呢?

统一高可用的上报组件

可能有同学会疑惑,究竟什么是“高可用”的上报组件?我认为至少需要达到三个目标:
数据不会丢失。数据不会由于应用崩溃、被系统杀死这些异常情况而导致丢失。
实时性高。无论是前台进程还是后台进程,所有的数据都可以在短时间内及时上报。
高性能。这里主要有卡顿和流量两个维度,应用不能因为上报组件的 CPU 和 I/O 过度占用导致卡顿,也不能因为设计不合理导致用户的流量消耗过多。
但是数据的完整性、实时性和性能就像天平的两端,我们无法同时把这三者都做到最好。因此我们只能在兼顾性能的同时,尽可能地保证数据不会丢失,让上报延迟更小。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文深入探讨了如何打造高可用的数据上报组件,以确保数据的完整性、实时性和性能。作者提出了高可用上报组件的三个目标:数据不丢失、实时性高、高性能,并详细讨论了采样、存储、上报和容灾四个模块的设计和难点。在采样模块中,作者介绍了采样策略的选择和实现,强调了准确性、均匀性和切换的平滑性。在存储模块中,作者提出了采用“多进程写 + mmap”方案,并讨论了埋点数据的聚合和上报数据优先级。在上报模块中,作者介绍了单进程上报策略和班车制度模式,并强调了文件同步模型的实现。最后,在容灾模块中,作者强调了保证组件内部异常不会给用户存储空间和流量造成严重问题的重要性。整体而言,本文内容技术性强,适合对数据上报组件感兴趣的技术人员阅读。 文章通过介绍“多进程写 + mmap + 后台进程上报 + 班车模式”等方案,展示了一套完全无锁、高性能的数据上报组件。作者强调了监控的重要性,包括质量监控和容灾监控,以确保数据的可靠性和时效性。在总结中,作者提到了实践中的细节和挑战,鼓励技术人员在实现新组件时经过精雕细琢和长时间的迭代和优化。此外,作者提出了两个课后作业,涉及采样策略更新和埋点进程突然崩溃的应对方式。 总的来说,本文内容丰富,涵盖了数据上报组件的设计和实践经验,对于想要深入了解高可用数据上报组件的技术人员具有一定的参考价值。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《Android 开发高手课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(9)

  • 最新
  • 精选
  • 刘伟
    1. 不使用推送,可以在每次上报的时候,把最新的策略作为响应返回给客户端,告诉客户端在什么时候改更新策略。 2. 可以让上报进程来做,上报进程通过FileObserver 来监听每个进程日志文件的更改时间,如果指定时间内没有变化,则可以立马上报该进程的文件。

    作者回复: 👍,八九不离十,具体答案后面有公布

    2019-03-07
    6
  • CoderAndy
    采样模块的算法有问题吧 上报用户 =(id_index == id_index)? 应该是id_index==time_index吧

    作者回复: 已经修正了,感谢提醒

    2019-03-08
    4
  • 奚岩
    对于采样策略的更新,可以在最新一次上报后带回,放入另一 FileObserver 中 ,Process A 获取使用; 对于 Process A 的崩溃,要主进程来上报么?

    作者回复: 1.策略更新,的确是最新上报带回。不过没有使用fileobserver,因为如果每个进程都加上他的代价有点大。用broadcast就可以 2. 这里是通过上报进程每隔一段时间监测+崩溃进程下次启动自检测,两个手段同时保证

    2019-03-07
    4
  • CatTalk
    我相信大多数产品都有基本的埋点上报功能,但是估计自己研发一套高可用的上报组件的公司不是很多。工作两年多,我一直思考这种功能只有加入大公司的技术团队才有机会去做,还是发挥自己的积极主动性就能做出来。(客观说)感觉中小心公司一直是业务业务...基础架构投入不大,够用就行。我的疑惑哈,希望同行们解惑。

    作者回复: 的确跟平台很有所关系,但是核心还是靠个人

    2019-03-07
    2
    2
  • 神佑小鹿
    采样率倒数 是个啥??
    2022-05-29
  • DK[rock].dE
    “在应用主动 KillProcess 之前,需要调用单独的函数...” 这个在 Android 上怎么实现呢,是监听信号吗
    2022-01-12
  • CoderAndy
    多进程+mmap,我想应该不是不同进程映射同一个文件吧?否则如果作同步处理,会造成数据被覆盖
    2021-05-17
  • haizhiyun
    // id:用户标识,例如微信号、QQ号 id_index = Hash(id) % 采样率倒数 time_index = (unix_timestamp / (24*60*60)) % 采样率倒数 上报用户 =(id_index == time_index) ---- 请问下这个有什么数学推导吗(还是有什么注意事项),尝试了下,随机选择一个用户,采样率10%,并不能在10天之内找到一次命中,计算出来的多半是浮点数,要相等很难,当采样率》50%的时候,应该最多经过两次计算就能命中,但是计算结果不是
    2021-02-08
  • Bradley_Cai
    海外产品,埋点一直用的是 Firebase Analytics,一直用着挺好,最近一段数据的回传时间延迟很大,愈发感叹这种核心模块还是把握在自己手里最好,不然出了问题都不知道找谁
    2020-08-20
收起评论
显示
设置
留言
9
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部