UserActivitySummary 数据延迟问题分析
1. 问题概述
UserActivitySummary 数据存在延迟，即 /v2/summary 接口返回的数据不是最新的。这个问题会影响业务决策和数据分析的准确性。
2. 可能的原因分析
2.1 定时任务执行延迟
系统中有多个定时任务按顺序执行：
- 处理原始用户活动数据（分配会话ID）
- 生成统计数据
- 生成汇总数据
任何一个环节的延迟都会影响最终的汇总数据。
2.2 数据处理瓶颈
大量数据处理
当系统积累大量未处理的 UserActivity 数据时，处理过程会变慢，导致数据延迟。
复杂的广告来源判断逻辑
系统需要检查28天内的访问历史来判断流量是否来源于广告，这个过程可能比较耗时。
数据库性能问题
MongoDB 在处理大量数据聚合时可能出现性能瓶颈。
2.3 分布式锁竞争
在多实例部署环境中，只有获得分布式锁的实例才能执行数据处理任务。如果锁竞争激烈或锁释放不及时，会导致部分实例无法执行任务。
2.4 异常处理不当
如果在处理过程中出现异常但没有正确处理，可能导致任务中断或部分数据未处理。
3. 具体延迟环节分析
3.1 UserActivity → ProcessedUserActivity 延迟
这个阶段的延迟可能由以下原因引起：
- 原始数据量过大，处理速度跟不上数据产生速度
- 会话ID分配逻辑复杂，特别是需要查询用户最近记录时
- 数据库写入性能瓶颈
3.2 ProcessedUserActivity → UserActivityStatistic 延迟
这个阶段的延迟可能由以下原因引起：
- 按日期逐日处理的策略导致滞后
- 广告来源判断逻辑复杂，特别是需要查询历史数据时
- 数据去重和统计计算耗时
3.3 UserActivityStatistic → UserActivitySummary 延迟
这个阶段的延迟可能由以下原因引起：
- 按日期分组统计的策略导致滞后
- 用户去重计算复杂度高
- 设备、平台等分布统计计算耗时
4. 诊断方法
4.1 检查定时任务执行日志
查看各阶段任务的执行时间和完成情况：
# 查看处理原始数据任务日志
grep "UA processing" application.log
# 查看统计数据生成任务日志
grep "UA statistics" application.log
# 查看汇总数据生成任务日志
grep "UA statistics and summary" application.log
4.2 检查数据积压情况
检查各集合中未处理数据的数量：
// 检查 UserActivity 集合中未处理的数据
db.UserActivity.count({
"receivedAt": {"$exists": true},
"_id": {"$nin": db.ProcessedUserActivity.distinct("_id")}
})
// 检查 ProcessedUserActivity 集合中未统计的数据
db.ProcessedUserActivity.count({
"_id": {"$nin": db.UserActivityStatistic.distinct("sourceId")}
})
4.3 检查分布式锁状态
查看锁的获取和释放情况：
// 检查锁集合
db.locks.find({"LockKey": "prodProcessingUa"})
5. 优化建议
5.1 提高处理效率
并行处理优化：
- 增加并行处理线程数
- 优化数据分片策略
数据库优化：
- 为常用查询字段建立索引
- 优化聚合管道性能
算法优化：
- 缓存常用的查询结果
- 简化不必要的计算逻辑
5.2 调整处理策略
增量处理：
- 改为增量处理而非全量处理
- 只处理新增数据
优先级处理：
- 对重要数据优先处理
- 分离实时和离线处理任务
5.3 监控和告警
建立监控体系：
- 监控各阶段处理延迟
- 设置延迟阈值告警
自动恢复机制：
- 实现任务失败自动重试
- 数据积压自动扩容处理
6. 总结
UserActivitySummary 数据延迟是由多个因素共同作用的结果，包括定时任务执行延迟、数据处理瓶颈、分布式锁竞争等。要解决这个问题，需要从多个方面入手，包括优化处理效率、调整处理策略、建立监控体系等。通过综合运用这些方法，可以显著降低数据延迟，提高数据的实时性。