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

什么是实时竞价广告?以及实时竞价广告的流程是怎么样的?这里面有一个图。我们从最右边往左看，最右边就是我们的用户打开手机看内容，比如看头条里面的内容或者刷新闻。过程中会看到有广告位的，当刷到有广告的那个页面的时候，这个时候 APP 就会向 ADX (广告交易平台)服务器发一个广告请求。广告交易平台服务器收到这个广告请求之后，它会去把这个广告请求分发给下面的广告主的 DSP 服务器，当然DSP 服务器可能会有很多家，一般来说只有大型的广告主才会有自己的 DSP 服务器。

腾讯游戏作为一个比较大型的广告主，它也有自己的 DSP 服务器。它收到的广告请求之后会怎么做呢?它会把这个广告请求里面的流量到它的DMP(数据管理平台)数据库里面去做一个判断，怎么判断?就是这个用户是不是我需要的，如果是我需要的话，我应该给他评估一个怎样的价钱，就是说我愿意出多少钱给来获得这个用户的这个广告曝光机会。

这里面会涉及到一些机器学习的算法去评估这个出价，最终确定了出价之后，他会把这个出价原路返回给 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%以上的流量，所以对整个系统的性能也是有非常大的提升。

（编辑：ASP站长网）