高频数据采集请求如何不影响主业务(7)
上一篇文章讨论了写缓存的架构解决方案,它虽然可以减少数据库写操作的压力,但也存在不足。比如需要长期高频插入数据时,这个解决方案就无法满足,本篇文章我们就围绕这个问题逐步提出解决方案。在架构方案层层展开的过程中,你会发现不断会有新问题需要考虑。 一、业务背景 因业务快速发展,公司系统日活用户高达500万,基于现有业务模式,业务侧要求我们根据用户行为做埋点,旨在记录用户在指定页面的所有行为、开展数据分析与第三方进行费用结算。(至于为啥要做结算,我就不说了,嘿嘿) 当然,在埋点过程中,业务侧还要求能在后台实时查询用户行为和统计报表。(这里虽然说是实时,其实特定时间内的延迟业务方还是能接受的,为确保描述的准确性,我们把它称之为“准实时”吧) 为了能够清晰的理解后续方案的建设思路,我来简单列举点儿数据结构,免得后面出现理解偏差。首先,我们需要收集的原始数据结构如下表所示: 指标 备注 IMEI 用户设备的IMEI 定位点 经纬度 用户ID 目标ID 每个页面、按钮、banner都有唯一识别id 目标类型 页面、按钮、banner等 事件动作 点击、进入、跳出等 From Url 来源URL Cu...
























