【大数据高并发核心场景实战】缓存层 - 日亿万级请求日志收集

上一章咱们给数据库装了个“写缓存”，相当于在市中心车库外建了个临时停车场。确实，车流（写操作）不堵门了。但问题是——这停车场是露天的，且只有三个车位。
一旦遇上“双十一”式的高频数据洪流（想象一群饿疯了的吃货同时涌向自助餐厅），这方案立刻露出短板：缓存写满的速度比手机掉电还快，数据要么排队等到天荒地老，要么面临丢失风险。
显然，临时方案扛不住持久战。接下来咱们关掉美颜，直面痛点，一步步拆解如何为持续的高频写入设计一个既扛得住、又稳得起的系统方案。
道路就在前方，咱们开始铺路。

1 业务背景：日亿万级请求日志收集如何不影响主业务

业务狂飙突进，某天，一家公司的日活用户冲上了 500万。
基于当时的模式，业务方一拍桌子要求：全面埋点，精准记录用户在特定页面的所有行为。
目的很明确：

• 数据分析 —— 理解用户，优化产品。
  
• 与第三方结算费用 —— 这事关商业模式，深层逻辑本章暂不展开。
  

与此同时，业务方还要求能在后台实时查询用户行为与统计报表。不过，此“实时”并非毫秒级的较真——略有延迟可以接受，更准确地说，是 “准实时”。
为了方便后续理解方案设计，这里对真实业务中复杂的数据结构进行了去枝减蔓，仅保留核心字段。如下表所示。
指标备注IMEI用户设备的IMEI定位点经纬度用户ID用户唯一ID目标ID每个页面、按钮、banner都有唯一ID目标类型页面、按钮、baner等事件动作点击、进人、跳出等FromURL来源URLCurrentURL当前URLTOURL去向URI动作时间触发这个动作的时间进人时间进人该页面的时间跳出时间跳出该页面的时间......在这样一套数据结构支撑下，业务团队在后台查询时，手里就像握着一把 “多维数据遥控器”：
第一，灵活查明细
他们可以任意组合筛选条件——按城市（由经纬度实时换算）、性别、年龄 按目标类型、具体事件动作
……实时透视每一位用户的行为轨迹，跟玩数据侦探游戏一样。
第二，秒出统计报表
系统还能从多个维度快速聚合出业务指标，例如：

• 按天/周/月/年 + 性别 + 年龄 等多维度交叉分析
  
• 查看每个目标ID的总点击量、人均点击次数、页面转化率等
  

（这还只是统计需求的冰山一角，业务方的报表愿望清单往往比你想象的长得多。）
而为了支撑费用结算这个关键任务，所需收集的数据结构（简化版）则如下表所示。
字段备注日期结算的日期目标ID原始数据中的目标 ID，比如页面 ID、按钮 ID、banner ID点击人数有多少人点击了目标 (同一人点多次算一次)点击人次有多少人次点击 (同一人点多次算多次)费用此目标 ID当天的收费总计这样一来，数据不仅要“流得进来”，还得能“被看得清、算得明”。下一步，就是设计一套能扛住高并发写入、同时支持灵活查询与实时统计的架构方案。
2. 技术选型思路

基于以上业务场景，项目组提炼出 六大核心需求 ，并给出了对应的技术选型思路：

• 原始数据海量 → 初步选用 HBase 持久化，专治数据“膨胀症”。
  
• 埋点响应要快 → 埋点服务先将日志丢进缓存层，保证用户无感。具体缓存方案有几副“牌”可打，稍后详解。
  
• 后台可查询原始数据 → 若直接用 HBase 查询，速度略慢。故额外引入 Elasticsearch，专门承载查询条件字段与活动ID，实现“秒查”。（用ES快速筛选出查询条件，再用条件去HBase拿完整数据，各司其职，既快又省。）
  
• 多样统计报表 → 虽可选用 Kibana、Grafana 等现成可视化工具，但为追求灵活度，决定自主设计统计功能。
  
• 依埋点生成结算数据 → 费用相关数据存 MySQL，保证事务清晰、计算稳妥。
  
• 需框架处理缓存数据并分流至 ES / HBase / MySQL → 因业务要求“准实时”，必须选用实时处理引擎。当前主流三兄弟：Storm、Spark Streaming、Apache Flink，选谁？下文分解。
  

根据以上思路，初步架构如下图所示。

眼尖的你一定发现了，这张架构图上还挂着醒目的问号❓没错，悬念就此埋下——它们正对应着接下来要拆解的四道核心难题。咱们往下看，问题马上揭晓。
2.1 使用什么技术保存埋点数据的第一现场

面对海量埋点数据，第一道关卡就是：用啥技术接住这“第一现场”？主流选项有三：Redis、Kafka、本地日志。项目组最终拍了板：本地日志。为啥不选 Redis 或 Kafka？来，我们掰开揉碎说一说。
2.1.1 先说 Redis：快，但有“记忆漏洞”
Redis 靠 AOF 机制持久化数据（写缓存章节提过），但其刷盘节奏是个关键选择：

• 若配置 appendfsync everysec：每秒刷一次盘。速度不错，但宕机可能丢一秒数据。
  
• 若配置 appendfsync always：每次操作都刷盘。数据稳了，但速度会有影响。
  

埋点要求响应飞快，等不及 always；又怕丢数据，不敢信 everysec。Redis：出局。
2.1.2 再说 Kafka：稳，却要“等确认”
Kafka 通过多副本保障可靠性，其 Producer 的 acks 配置直接决定速度与安全的取舍：
[table][tr]acks 值行为结果[/tr][tr][td]0[/td][td]Leader 不收妥就直接回复客户端[/td][td]⚡️ 速度起飞，
来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！