30 | 数据评估(上):如何实现高可用的上报组件?
该思维导图由 AI 生成,仅供参考
统一高可用的上报组件
- 深入了解
- 翻译
- 解释
- 总结
本文深入探讨了如何打造高可用的数据上报组件,以确保数据的完整性、实时性和性能。作者提出了高可用上报组件的三个目标:数据不丢失、实时性高、高性能,并详细讨论了采样、存储、上报和容灾四个模块的设计和难点。在采样模块中,作者介绍了采样策略的选择和实现,强调了准确性、均匀性和切换的平滑性。在存储模块中,作者提出了采用“多进程写 + mmap”方案,并讨论了埋点数据的聚合和上报数据优先级。在上报模块中,作者介绍了单进程上报策略和班车制度模式,并强调了文件同步模型的实现。最后,在容灾模块中,作者强调了保证组件内部异常不会给用户存储空间和流量造成严重问题的重要性。整体而言,本文内容技术性强,适合对数据上报组件感兴趣的技术人员阅读。 文章通过介绍“多进程写 + mmap + 后台进程上报 + 班车模式”等方案,展示了一套完全无锁、高性能的数据上报组件。作者强调了监控的重要性,包括质量监控和容灾监控,以确保数据的可靠性和时效性。在总结中,作者提到了实践中的细节和挑战,鼓励技术人员在实现新组件时经过精雕细琢和长时间的迭代和优化。此外,作者提出了两个课后作业,涉及采样策略更新和埋点进程突然崩溃的应对方式。 总的来说,本文内容丰富,涵盖了数据上报组件的设计和实践经验,对于想要深入了解高可用数据上报组件的技术人员具有一定的参考价值。
《Android 开发高手课》,新⼈⾸单¥59
全部留言(9)
- 最新
- 精选
- 刘伟1. 不使用推送,可以在每次上报的时候,把最新的策略作为响应返回给客户端,告诉客户端在什么时候改更新策略。 2. 可以让上报进程来做,上报进程通过FileObserver 来监听每个进程日志文件的更改时间,如果指定时间内没有变化,则可以立马上报该进程的文件。
作者回复: 👍,八九不离十,具体答案后面有公布
2019-03-076 - CoderAndy采样模块的算法有问题吧 上报用户 =(id_index == id_index)? 应该是id_index==time_index吧
作者回复: 已经修正了,感谢提醒
2019-03-084 - 奚岩对于采样策略的更新,可以在最新一次上报后带回,放入另一 FileObserver 中 ,Process A 获取使用; 对于 Process A 的崩溃,要主进程来上报么?
作者回复: 1.策略更新,的确是最新上报带回。不过没有使用fileobserver,因为如果每个进程都加上他的代价有点大。用broadcast就可以 2. 这里是通过上报进程每隔一段时间监测+崩溃进程下次启动自检测,两个手段同时保证
2019-03-074 - CatTalk我相信大多数产品都有基本的埋点上报功能,但是估计自己研发一套高可用的上报组件的公司不是很多。工作两年多,我一直思考这种功能只有加入大公司的技术团队才有机会去做,还是发挥自己的积极主动性就能做出来。(客观说)感觉中小心公司一直是业务业务...基础架构投入不大,够用就行。我的疑惑哈,希望同行们解惑。
作者回复: 的确跟平台很有所关系,但是核心还是靠个人
2019-03-0722 - 神佑小鹿采样率倒数 是个啥??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