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