加入收藏 | 设为首页 | 会员中心 | 我要投稿 核心网 (https://www.hxwgxz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 建站 > 正文

OpenResty在腾讯游戏营销技术中的应用和实践

发布时间:2019-04-10 08:07:12 所属栏目:建站 来源:顾小平
导读:大家上午好,我是来自腾讯的Shawn顾小平。先做一个简单的自我介绍。我在加入到腾讯之前一直在通讯行业里面从事通信软件的研发工作,包括在华为,还有UT斯达康。 2012年10月份我加入到腾讯,现在在腾讯互动娱乐事业群负责部分的营销技术相关的工作。我接触

这里面会涉及到一些机器学习的算法去评估这个出价,最终确定了出价之后,他会把这个出价原路返回给 ADX 服务器。ADX 服务器收到这个出价之后,它会等待其他广告主的 DSP服务器的出价,放在一起比较来最终选择最高出价的广告主的广告,然后把这次广告曝光的机会给到这个广告主,展示这个广告主的广告素材,这个就是一个比较简化的实时竞价广告的流程。

里面需要做的一个事情就是,在这个 ADX 和 DSP 服务器之间的交互是通过 OpenRTB 协议来做的,这里面有两个问题需要解决:

  • 第一个是流量非常大,ADX所有的广告请求都会发给 DSP 服务器,有些大的媒体可能有好几万个QPS,如果好几家的话加起来很轻松会超过十万QPS。
  • 还有一个问题就是 ADX要求所有的DSP 必须在 100 毫秒返回出价响应,这个100ms包括网络上的时间,如果 100 毫秒之内我没有收到你响应的话,我就视为你放弃了这个出价。

当然实时竞价广告技术方面有很多挑战,主要有这么几块的挑战。

  • 第一个就是在数据方面,包括标签挖掘、人群扩散、画像分析,还有一些实时分析、透视分析来辅助刷选投放目标人群,这个是在数据方面的技术挑战。
  • 第二个就是算法,算法会包括两个比较核心的算法。第一个就是 pCTR,第二个就是pCVR,pCTR 就是点击率预估算法,pCVR是转化率预估算法,这个转化可能会包括多个,有下载、注册、付费、活跃等等都属于转化。这两个算法会用到现在比较热的一些机器学习的算法在里面。
  • 第三个方面的挑战就是在系统层面的挑战,刚才提到了 ADX 和 DSP 服务器,它之间会有比较高的QPS,另外就是时延有要求,100毫秒的要求。今天我分享的内容主要是偏重于在第三块,就是在系统层面怎么和 OpenResty 进行结合。

这个是实时竞价广告系统在系统侧的一个架构简图,最上面是流量层,各ADX的广告请求流量会发到下面的接入层。接入层又包括两部分,一个是静态的 CDN,一个是动态的 RTB 网关,CDN 存放广告的素材,RTB 网关会做一件事情,就是进行 OpenRTB 协议的编解码,此外还会做一些安全和流量控制等操作。

在逻辑层包括竞价引擎,最下面的就是数据层包括 DMP 数据管理平台。这两个部分做的事情就是我们刚刚说的,一起来确定这个广告请求是不是我们需要的用户,如果是我们需要的用户的话,我们怎么样给它估算一个价钱。

这里面标了橙黄色字体的,就是我们用 OpenResty 进行过重构或者说优化过的地方,包括接入层的 RTB 网关,还有逻辑层竞价引擎,以及 DMP 的数据管理平台的一部分。

我们就一个个来看一下我们怎么样做重构和优化的:

  • 首先在接入层,我们直接用 OpenResty 定制了 RTB 网关,为什么用 OpenResty 定制 RTB 网关呢?刚刚提到了,它的流量非常大,这个可以充分发挥 OpenResty 的nginx+lua协程高性能的特性。
  • 另外还有一个问题就是不同的媒体有不同的 OpenRTB协议,虽然有标准规定,但是它们还是会有一些差别的,对接起来还是非常地麻烦,所以对每家媒体都利用插件化方式做了差别化的处理,来提高开发联调时候的效率。
  • 接下来就是在安全方面的一个优化,这里的安全策略跟前面讲的安全策略可能不太一样。这里面主要是基于 OpenRTB协议本身的安全策略,包括Request id的各个阶段校验,还有参数的非对称加密做防盗链,泄露用户信息等,另外就是一些防作弊,我们把这些安全性方面的优化都放到这个 RTB 网关里面来做。
  • 另外,RTB 网关还做了一个比较大的优化,就是把目标流量筛选也直接放到了 RTB 网关里面来了。之前传统的做法都是怎么做的呢?都是让流量进入到 DMP 数据平台里面来,经过竞价引擎、广告检索、标签查询服务来到 DMP 数据管理平台里面去确定这个用户是不是我们需要的。因为DMP数据管理平台里面存放了所有用户的加密ID信息以及一些标签属性、偏好等等,之前都是这样来判断的。

其实我们可以简化一点,直接把这部分加密数据放到 RTB 网关里面来,当然也会遇到一个问题就是用户的加密标识信息非常大,大概会有十几亿条,另外一个设备标识加密后至少是32个字符串,如果全部存放到内存里面的话大概要十几个G,当然这还不包括查找索引额外的开销。

那我们就去寻找一个哈希算法,可以把一个固定长度的字符串直接转化为一个整型,然后我们把这个整型直接通过Bitmap直接映射到 512 兆的内存中的一个bit中去。这样就可以直接通过 512 兆的内存存放40亿的加密设备号,当然也会有不同的加密设备号映射到相同的比特位里面去了,但这个没有关系,我们还是继续走之前原来的路径,让它在最后面 DMP 里面再做一次判断。

经过这么一个简单的优化之后,我们在第一时间里面可以过滤掉大概80%以上的流量,所以对整个系统的性能也是有非常大的提升。

(编辑:核心网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读