理想论坛_专业20年的财经股票炒股论坛交流社区 - 股票论坛

 找回密码
 立即注册
搜索
热搜: 活动 交友 discuz
查看: 2351|回复: 0

OpenResty 在马蜂窝广告监测中的应用

[复制链接]

9650

主题

9650

帖子

2万

积分

管理员

Rank: 9Rank: 9Rank: 9

积分
28966
发表于 2019-12-27 13:33 | 显示全部楼层 |阅读模式
蚂蜂窝技术原创内容,更多干货请定阅公众号:mfwtech
广告是互联网变现的垂危本事之一。
以蚂蜂窝旅游 App 为例,当用户翻开我们的利用时,有大要会在首屏或是信息流、商品列表中看到推送的广告。假如恰好对广告内容感爱好,用户就大要会点击广告了解更多信息,进而完成这条广告渴望完成的后续操纵,以下载广告举荐的 App 等。
广告监测平台的使命就是持续、正确地收集用户在欣赏和点击广告这些变乱中照顾的信息,包含根源、时候、装备、位置信息等,并举行处置赏罚和分析,来为广告主供给付费结算以及评价广告投放成果的根据。
是以,一个牢靠、正确的监测办事很是垂危。为了更好地保障平台和广告主双方的权益,以及为提拔蚂蜂窝旅游网的广告办事成果供给支持,我们也在不停地摸索适当的打点计划,增强广告监测办事的本事。

Part.1 早期形状

早期我们的广告监测并没有构成完整的办事对外开放,是以实现方式及供给的本事也比力简单,垂危分为两部分:一是基于客户端打点,针对变乱举行上报;另一部分是针对曝光、点击链接做转码存档,当请求到来后分析跳转。
可是很快,这类方式的弊端就暴袒露来,垂危表现在以下几个方面:

  • 收数的正确性:数据转发必要拜候中心件才华完成,增加了多段丢包的机率。在和第三方监测办事举行对照考证时,Gap 差别较大;
  • 数据的处置赏罚本事:收集的数据来自于各个营业系统,缺少同一的数据标准,数据的多种属性致使分析起来很复杂,增加了综合数据二次操纵的难度;
  • 突发流量:当流量瞬时升高,就会碰到 Redis 内存消耗高、办事掉线频仍的题目;
  • 安排复杂:随着差别装备、差别广告位的变更,打点趋于复杂,以致大要会覆盖不到;
  • 开辟服从:早期的广告监测功用单一,例如对实时性条件的盘算查询等都必要额外开辟,很是影响服从。

Part.2 基于 OpenResty 的架构实现

在这样的背景下,我们打造了蚂蜂窝广告数据监测平台 ADMonitor,渴望渐渐将实在现成一个安定、牢靠、高可用的广告监测办事。
2.1 筹划思绪

为了处理老系统中的各类题目,我们引入了新的监测流程。主体流程筹划为:

  • 在新的监测办事 (ADMonitor) 上天生关于每种广告独占的监测链接,同时附在原本的客户链接上;
  • 全数从办事端下发的曝光链接和点击链接并行依靠 ADMonitor 供给的办事;
  • 客户端针对曝光行为举行并行请求,点击行为会优先跳转到 ADMonitor,由 ADMonitor 来做二段跳转。

经过以上方式,使监测办事完全依靠 ADMonitor,极大地增加了监测安排的灵活性及团体办事的性能;同时为了进一步考证数据的正确性,我们保存了打点的方式举行对照。
2.2 技术选型

为了使上述流程落地,广告监测的流量进口必必要具有高可用、高并发的本事,尽管淘汰非必要的收集请求。考虑到内部多个系统都必要流量,为了低落系统对接的人力本钱,以及禁止由于系统迭代对线上办事形成干扰,我们起首要做的就是把流量网关自力出来。
关于 C10K 编程关连的技术业内有很多打点计划,比如 OpenResty、JavaNetty、Golang、NodeJS 等。它们配合的特点是操纵一个过程或线程可以同时处置赏罚多个请求,基于线程池、基于多协程、基于变乱驱动+回调、实现 I/O 非阻塞。
我们终极挑选基于 OpenResty 构建广告监测平台,垂危是对以下方面的考虑:
第一,OpenResty 工作在收集的 7 层之上,依托于比 HAProxy 更增强大和灵活的正则法则,可以针对 HTTP 利用的域名、目录结构做一些分流、转发的计谋,既能做负载又能做反向代理;
第二,OpenResty 具有 Lua协程+Nginx 变乱驱动的「变乱循环回调机制」,也就是 Openresty 的焦点 Cosoket,对远程后端诸如 MySQL、Memcached、Redis 等都可以实现同步写代码的方式实现非阻塞 I/O;
第三,依托于 LuaJit,立即编译器会将频仍尝试的代码编译成呆板码缓存起来,当下次挪用时将间接尝试呆板码,相比原生逐条尝试捏造机指令服从更高,而对于那些只尝试一次的代码仍然可以逐条尝试。
2.3 架构实现

团体计划依托于 OpenResty 的处置赏罚机制,在办事器内部举行定制开辟,垂危别离为数据收集、数据处置赏罚与数据归档三大部分,实现异步拆分请求与 I/O 通讯。团体结构表示图以下:

我们将多 Woker 日志信息以双端行列的方式存入 Master 同享内存,开启 Worker 的 Timer 毫秒级按时器,离线分析流量。
2.3.1 数据收集

收集部分也是主体承受流量压力最大的部分。我们操纵 Lua 来做团体检参、过滤与推送。由于在我们的场景中,数据收集部分不必要考虑时序或对数据举行聚合处置赏罚,是以焦点的推送介质挑选 Lua 同享内存即可,以 I/O 请求来取代拜候其他中心件所必要的收集办事,从而淘汰收集请求,满足立即性的要求,以下所示:

下面结合 OpenResty 设备,先容一些我们对办事器节点举行的优化:

  • 设备 lua 缓存-lua_code_cache:
    (1)开启后会将 Lua 文件缓存到内存中,加速拜候,但点窜 Lua 代码必要 reload
    (2)尽管禁止全局变量的发生
    (3)封闭后会依靠 Woker 过程中天生自己新的 LVM
  • 设备 Resolver 对于收集请求、好的 DNS 节点大要自建的 DNS 节点在收集请求很高的情况下会很有帮助:
    (1)增加公司的 DNS 办事节点与补偿的公网节点
    (2)操纵 shared 来淘汰 Worker 查询次数
  • 设备 epoll (multi_accept/accept_mutex/worker_connections):
    (1)设备 I/O 模子、避免惊群
    (2)禁止办事节点浪费资本做无用处置赏罚而影响团体流转等
  • 设备 keepalive:
    (1)包含链接时长与请求上限等
设备优化一方面是要合适当前请求场景,另一方面要配合 Lua 发挥更好的性能。设备 Nginx 办事器参数根柢是按照差别操纵系统情况举行调优,比如 Linux 中统统皆文件、调解文件翻开数、设备 TCP Buckets、设备 TIME_WAIT  等。
2.3.2 数据处置赏罚

这部分流程是将收集到的数据先经过 ETL,以后建立内部的日志 location,结合 Lua 自界说 log_format,操纵 Nginx 子请求特征离线完成数据落盘,同时保证数据耽误时长在毫秒级。
对被分析的数据处置赏罚要举行两部合作作,一部分是 ETL,另一部分是 Count。
(1)ETL

垂危流程:     

  • 日志经过同一格式化以后,抽取包含现实意义参数部分举行数据分析
  • 将抽取后的数据举行过滤,针对团体字符集、IP、装备、UA、甘芷?签信息等举行处置赏罚
  • 将转化后的数据举行重加载与日志重定向
【例】Lua 操纵 FFI 经过 IP 库分析 "ip!"用 C 把 IP 库拷贝到内存中,Lua 举行毫秒级查询:

(2)Count
对于广告数据来说,绝大部分营业需求都来自于数据统计,这里间接操纵 Redis+FluxDB 存储数据,以有下几个关键的技术点:

  • RDS 结合 Lua 设备链接时候,设备链接池来增加链接复用
  • RDS 集群办究竟现去中心化,分离节点压力,增加 AOF与延时入库保证牢靠
  • FluxDB 保证数据日志时序性可查,聚合统计与实时报表表示较优
2.3.3 数据归档

数据归档必要对全量数据入表,这个进程中会触及到对一些无效数据举行过滤处置赏罚。这里团体接入了公司的大数据系统,流程上分为在线处置赏罚和离线处置赏罚两部分,可以大要对数据回溯。操纵的打点计划是在线 Flink、离线 Hive,其中必要关注:

  • ES 的索引与数据定期保护
  • Kafka 的消耗情况
  • 对于发生故障的呆板操纵自动剧本重启与报警等

实时数据源:数据采集办事→ Filebeat → Kafka → Flink → ES

离线数据源:HDFS → Spark → Hive → ES

数据分析后的再操纵:
分析后的数据已经具有了反复操纵的价格。我们的垂危利用处景有两大块。
一是 OLAP,针对营业场景与数据表示分析拜候广告的人群属性标签变化情况,包含地域,装备,人群散布占比与增加情况等;同时,针对未来人群库存占比举行猜测,末端影响到现实投放上。
另一部分是在 OLTP,垂危场景为:

  • 判定用户能否属于广告受众地域
  • 分析 UA 信息,获得终端信息,判定能否属于为低级爬虫流量
  • 装备号打标,从 Redis 获得实时用户画像,举行实时标志等
2.4 OpenResty 其他利用处景

OpenResty 在我们的广告数据监测办事全流程中均发挥侧垂危感化:

  • init_worker_by_lua阶段:负责办事设备营业
  • access_by_lua阶段:负责CC防护、权限准入、流量时序监控等营业
  • content_by_lua阶段:负责实现限速器、分流器、WebAPI、流量采集等营业
  • log_by_lua阶段:负责日志落盘等营业
重点解读以下两个利用的实现方式。
2.4.1  分流器营业

NodeJS 办事向 OpenResty 网关上报当前办事器 CPU 和内存操纵情况;Lua 剧本挪用 RedisCluster 获得时候窗口内 NodeJS 集群操纵情况后,盘算出负载较高的 NodeJS 呆板;OpenResty 对 NodeJS 集群流量举行熔断、升级、限流等逻辑处置赏罚;将监控数据同步 InfluxDB,举行时序监测。
2.4.2 小型 WEB 防火墙

操纵第三方开源 lua_resty_waf 类库实现,支持 IP 白名单和黑名单、URL 白名单、UA 过滤、CC 进犯防护功用。我们在此根柢上增加了 WAF 对 InfluxDB 的支持,举行时序监控和办事预警。
2.5 小结

总结来看,基于 OpenResty 实现的广告监测办事 ADMonitor 具有以下特点:

  • 高可用:依靠 OpenResty 做 Gateway, 多节点做 HA
  • 立即返回:分析数据后操纵 I/O 请求做数据异步处置赏罚,禁止非必要的收集通讯
  • 解耦功用模块:对请求、数据处置赏罚和转发实现解耦,缩减单请求串行处置赏罚耗时
  • 办事保障:  针对垂危的数据成果操纵第三方组件零丁存储
完整的技术计划表示以下:


Part.3 总结

现在,ADMonitor 已经接入公司的广告办事系统,整体运转情况比力理想:
1. 性能成果


  • 到达了高吞吐、低耽误的标准
  • 转发乐成率高,曝光计数乐成率>99.9%,点击乐成率>99.8%
2. 营业成果


  • 与支流第三方监测机构举行数据对照:曝光数据 GAP < 1%,点击数据GAP < 3%
  • 可供给实时检索与聚合办事
未来我们将结合营业成长和办事场景不停美满,等待和大家多多交换。
本文作者:江明辉,蚂蜂窝旅游网品牌广告数据办事端组研发工程师。


免责声明:假如加害了您的权益,请联系站长,我们会实时删除侵权内容,感谢合作!

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

Archiver|手机版|小黑屋|理想论坛_专业20年的财经股票炒股论坛交流社区 - 股票论坛

GMT+8, 2020-7-7 07:07 , Processed in 0.158692 second(s), 29 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表