上篇详细讨论了写缓存的架构解决方案,它虽然可以减少数据库写操作的压力,但也存在一些不足。比如需要长期高频插入数据时,这个方案就无法满足,接下来将围绕这个问题逐步提出解决方案。
因业务快速发展,某天某公司的日活用户高达500万,基于当时的业务模式,业务侧要求根据用户的行为做埋点,旨在记录用户在特定页面的所有行为,以便开展数据分析,以及与第三方进行费用结算(费用结算涉及该业务线的商业模式,本篇里不展开)。
当然,在数据埋点的过程中,业务侧还要求在后台能实时查询用户行为数据及统计报表。这里的“实时”并不是严格意义上的实时,对于特定时间内的延迟业务方还是能接受的,为确保描述的准确性,可以称之为准实时。
为了方便理解后续方案的设计思路,此处把真实业务场景中的数据结构进行了简化(真实的业务场景数据结构更加复杂)。首先,需收集的原始数据结构见表6-1。
表6-1 需收集的原始数据结构
通过以上数据结构,在后台查询原始数据时,业务侧不仅可以将城市(根据经纬度换算)、性别(需要从业务表中抽取)、年龄(需要从业务表中抽取)、目标类型、目标ID、事件动作等作为查询条件来实时查看用户行为数据,还可以从时间(天/周/月/年)、性别、年龄等维度实时查看每个目标ID的总点击数、平均点击次数、每个页面的转化率等作为统计报表数据(当然,关于统计的需求还很多,这里只是列举了一小部分)。
为了实现费用结算这个需求,需要收集的数据结构见表6-2(再次强调,该数据结构只是示例,并非真实的业务场景数据)。
下篇探讨技术选型的相关思路及整体方案。
本文就是愿天堂没有BUG给大家分享的内容,大家有收获的话可以分享下,想学习更多的话可以到微信公众号里找我,我等你哦。