CN110599229A - 亿级流量广告实时处理方法、存储介质、电子设备和系统 - Google Patents

Abstract

本发明公开了一种亿级流量广告实时处理方法、存储介质、电子设备和系统，涉及互联网直播领域领域，该方法包括：S1：获取广告信息，所述广告信息至少包括广告ID、广告位ID。S2：获取客户端的类型，将同一类型客户端的广告信息存放于一个或一组Redis队列。S3：将Redis队列中的广告信息存储于Kafka信息队列。S4：读取Kafka信息队列中的广告信息，并使用于分布式实时流处理框架计算广告信息之间的映射关系数据，并将映射关系数据存储于MySQL数据库中。

Description

亿级流量广告实时处理方法、存储介质、电子设备和系统

技术领域

本发明涉及互联网直播领域领域，具体涉及一种亿级流量广告实时处理方法及系统。

背景技术

播放广告是一些大型互联网公司的主要经济来源之一，对其进行有效的、合理的管理是一个互联网公司能够长远发展和立足的必备技能。然而当下正处的大数据时代，网络情况复杂，安全环境恶劣，直播网站作为一个开放性的平台，每时每刻都面对着高并发用户的大流量访问。因此如何在复杂的网络和恶劣安全环境中，对海量的广告曝光和点击数据进行有效信息实时获取，是每一个直播类互联网公司在进行广告投放时，所必须面临的挑战。

传统互联网公司对于广告投放的信息管理通常是对离线广告信息进行分析，首先，对每天产生的亿级的广告信息进行离线存储，将会浪费大量的存储空间，如果每天的广告曝光、点击信息条数有4亿条，按每条信息数据大小为0.3kb进行计算，则一天内，需要进行离线存储的广告信息的空间大小约为120GB，即提高了广告的成本；其次，离线广告信息不能并不能及时的反映广告的投放效果，其投放的广告也无法及时管控其所达到的投放效果。此外，大量的离线广告信息需要消耗员工大量的时间进行离线的数据处理，因此，采用传统的离线数据分析将会消耗大量的时间以及成本。

然而对于直播行业来讲，将广告定点投放到某一赛事或娱乐直播，存在则严苛的实时要求，其需要十分方便及时调整的投放策略，以满足客户要求。

发明内容

针对现有技术中存在的缺陷，本发明的目的在于提供一种亿级流量广告实时处理方法及系统，能够处理海量的广告信息流量减少崩溃和数据丢失，同时十分方便且实时的调整广告投放策略。

为达到以上目的，本发明采取的技术方案是：

一种亿级流量广告实时处理方法其包括：

S1：获取广告信息，所述广告信息至少包括广告ID、广告位ID；

S2：获取客户端的类型，将同一类型客户端的广告信息存放于一个或一组Redis队列；

S3：将Redis队列中的广告信息存储于Kafka信息队列；

S4：读取Kafka信息队列中的广告信息，并使用于分布式实时流处理框架计算广告信息之间的映射关系数据，并将映射关系数据存储于MySQL数据库中。

在上述技术方案的基础上，所述广告信息还包括：

用户ID、设备ID、操作类型、操作时间、素材ID、素材url、广告组ID、合同ID。

在上述技术方案的基础上，步骤S3中Redis队列中的广告信息还存储于本地磁盘，存储于本地磁盘的广告信息用于数据离线分析以及数据备份。

在上述技术方案的基础上，步骤S2具体包括以下步骤：

将客户端分类为安卓端、IOS端和网页端；

将同一类型客户端的广告信息存放于一个或一组Redis队列。

在上述技术方案的基础上，步骤S2具体包括以下步骤：

预设地域分类，根据客户端所在地域将客户端分类至不同地域；

将各个地域客户端分类为安卓端、IOS端和网页端；

将同一地域的同一类型客户端的广告信息存放于一个或一组Redis队列。

在上述技术方案的基础上，步骤S4后还包括步骤S5，所述步骤S5为：

检验广告信息之间的映射关系数据是否被篡改，若未被篡改，则根据广告信息之间的映射关系数据展示广告。

在上述技术方案的基础上，检验广告信息之间的映射关系数据是否被篡改的方法为：

获取映射关系数据中的广告信息是否存在于步骤S1中获取的广告信息中，若不存在，则判断映射关系数据被篡改。

本发明还提供一种存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现以下步骤：

S1：获取广告信息，所述广告信息至少包括广告ID、广告位ID；

S2：获取客户端的类型，将同一类型客户端的广告信息存放于一个或一组Redis队列；

S3：将Redis队列中的广告信息存储于Kafka信息队列；

S4：读取Kafka信息队列中的广告信息，并使用于分布式实时流处理框架计算广告信息之间的映射关系数据，并将映射关系数据存储于MySQL数据库中。

本发明还提供一种电子设备，包括存储器和处理器，存储器上储存有在处理器上运行的计算机程序：所述处理器执行所述计算机程序时实现在上述技术方案的方法。

本发明还提供一种亿级流量广告实时处理系统，其包括：

暂存模块，用于获取广告信息，所述广告信息包括广告ID、广告位ID，获取客户端的类型，将同一类型客户端的广告信息存放于一个或一组Redis队列；

存储模块，用于将Redis队列中的广告信息存储于Kafka信息队列；

处理模块，用于读取Kafka信息队列中的广告信息，并使用于分布式实时流处理框架计算广告信息之间的映射关系数据，并将映射关系数据存储于MySQL数据库中。

与现有技术相比，本发明的优点在于：

(1)本发明通过Redis队列能够高速存储广告信息，直播平台能够支持激增读写流量，通过不同的Redis队列支撑不同类型的客户端使得直播平台能够进一步分流，缓解读写流量的压力；使用Kafka队列将Redis队列的广告信息存储，能够以低延时的存储广告信息，保证广告的及时存储；基于storm架构针对Kafka队列中的广告信息进行计算，能够较效率同时精确的得出广告的展示结果。

(2)本发明所收集的广告信息包含了用户ID、设备ID、操作类型、操作时间、素材ID、素材url、广告组ID、合同ID多个信息，使得广告除了考虑展示时间、效果外，还综合了广告的展示源url、广告展示合同等等，计算得到的结果更加全面。

(3)本发明使用本地磁盘存储Redis队列中的广告信息，保证数据处理崩溃后，能够进行数据恢复找回损失的数据，同时，工作人员能够对离线数据进行个性化分析，使得数据获得的结果、结论多元化。

附图说明

图1为一种亿级流量广告实时处理方法实施例的流程图；

图2为一种亿级流量广告实时处理方法实施例步骤S2的结构示意图；

图3为一种亿级流量广告实时处理方法及系统实施例S3的结构示意图；

图4为一种亿级流量广告实时处理方法及系统实施例。

具体实施方式

以下结合附图对本发明的实施例作进一步详细说明。

参见图1所示，本发明实施例提供一种亿级流量广告实时处理的方法，其通过设置Redis队列优先缓存大批量的广告信息，然后设置Kafka信息队列跟进存储，能够减少崩溃和数据丢失，同时十分方便且实时的调整广告投放策略。该方法包括：

S1:获取广告信息，所述广告信息包括广告ID、广告位ID。

具体的，广告信息中带有广告ID、和广告位ID，这样通过后续步骤中的计算，将不同的广告ID和广告位ID对应起来，即，该广告ID下的广告在对应的广告位ID对应，方便后续展示。需要说明的是，本文中的广告位指特定链接界面中的特定广告栏位，如直播画面右侧

举例来说，广告信息中广告ID为广告名A，广告名B，广告名C等等，广告位ID为直播页面的各个位置对应的名称，如：001对应直播页面中右侧一特定位置的广告位，002对应直播页面下侧一特定位置的广告位。

优选的，广告信息中还包括用户ID、设备ID、操作类型、操作时间、素材ID、素材url、广告组ID、合同ID，所述映射关系还包括广告ID和展示时长、展示周期的关系，广告ID和所需展示的效果的关系、广告ID和设备ID的关系。

具体来说，亿级的广告流量，由于在后期需要对广告的各个方面都进行统筹、计算和对应，除了广告位ID和广告ID的对应关系，对于不同展示的设备，如苹果手机、安卓手机、页面等等设备ID和不同展示对象即根据用户ID，来需要进行统计和计算，此外，广告的展示方式以及展示时间也需要进行计算、对应，更具体的，不同的广告使用的素材不一样，其使用的素材url也不一样，同时可能分属于不同的合同中，在合同中，不同的广告ID可能属于同一广告组中。

举例来说，某公司和直播平台签有合同：在一个时间段内需要向多个用户展示几个广告，且这些广告作为一个或者几个广告组。同时，在进行计算之前，需要统计目前平台上有的广告位置，现有广告的呈现方式如动态、静态等等，现有的广告播放时间以及周期。统计完这些数据后，系统才能够通过后续的计算，将每一个广告展示为广告位、展示的方式、时间、周期以及所述的广告组、合同和对应的用户、设备等等进行对应，完成对亿级流量的广告实时监控、处理和统计。

S2获取客户端的类型，将同一类型客户端的广告信息存放于一个或者一组Redis队列。Redis是一个key-value存储系统，和Memcached类似，能够支持各种不同方式的排序。同时，为了保证效率，数据都是缓存在内存中。区别的是Redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从)同步。因此Redis是一个高性能的key-value数据库。Redis的出现，很大程度补偿了memcached这类key/value存储的不足，可以对关系数据库起到很好的补充作用。

具体来说，Redis队列作为高可用缓存，能够针对亿级流量的广告信息快速保存，同时在直播平台处于用户高峰期期间，能够满足因为读写速度急剧上升导致的海量流量需求，不会发生崩溃以及数据丢失。而且，将广告信息区分客户端类型保存至Redis队列进一步的缓解了亿级流量广告在高峰期时候的读写压力，本步骤保证了亿级广告的安全、无丢失的实时读写保存，保证了数据的稳定和安全。

举例来说，如图2所示，将客户端分为IOS手机系统客户端、安卓手机系统客户端和网页客户端三个类别，为每一类客户端对应Redis队列。其中流量较大的客户端对应一组Redis队列，而对应于流量较小的客户端的广告信息则可以对应一个Redis队列。其中的网页客户端用户行为大多采用javascript获取，而原生APP使用API接口方式传输，不同的客户端的传输数据方式不同，传输速度也是差别的，将其分为多个Redis队列分别传输，能够进一步保证海量信息传输的稳定和安全的。此外，网页客户端的javascript以及原生APP使用的API接口容易被调用以及篡改，因此优选进行一次信息校验，验证数据的是否正确和安全。通过针对客户端进行分类，将本来需要一起存储的广告信息分作了几份缓存到多个或者多组Redis队列，能够进一步缓解亿级流量的广告信息所造成的压力。

进一步的，因为广告的投放是有地域性的，如不同的省或者不同的国家投放的广告可能是不同的，因此，还可以先预设地域的分类，根据客户端所在地域将客户端分类至不同地域，然后再将各个地域客户端分类为安卓端、IOS端和网页端，将同一地域的同一类型客户端的广告信息存放于一个或一组Redis队列。除了针对客户端进行分类，对地域进行分类也能够对亿级流量的广告信息进行分流，缓解读写压力，保证平台的稳定和广告信息的安全。

S3将Redis队列中的广告信息存储于Kafka信息队列中。由于Redis队列实际为高可用缓存，在断电后，数据将会消失，因此，还需要进一步的放入存储装置中去。Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者规模的网站中的所有动作流数据。这种动作(网页浏览，搜索和其他用户的行动)是在现代网络上的许多社会功能的一个关键因素。这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。因此，利用Kafka信息队列的高吞吐量，将Redis队列中的广告信息存储于Kafka信息队列则保证了亿级流量的广告能够存储在磁盘中，在经历系统崩溃、掉电等等，也能够较好的保证数据的存储。

如图3所示，作为一个可选的实施方式，Redis队列的广告信息除了存储于Kafka信息队列中外，还可以存储于本地磁盘中，本地磁盘中的广告信息能够为平台管理人员进行离线分析提供数据基础，也能够为平台提供数据备份。当平台管理人员需要分析广告状态、获取广告相关信息时候，不再需要从Kafka队列中进行截取，而是可以直接从本地磁盘进行调阅。当Kafka队列出现崩溃时，其从Redis队列实时获取的数据将很有可能出现缺省以及丢失，这时平台还可以通过本地磁盘上存储的数据进行恢复，进一步保护的数据和平台的安全性和稳定性。

优选的，每隔一段时间存储于本地磁盘的广告信息将定时导入数据仓库工具hive中，

需要说明的是，Kafka信息队列读取速度不及Redis队列高，如果在步骤S2中使用Kafka信息队列直接存储亿级流量的广告信息，在平台访问量剧增，读写流量暴增时，容易出现崩溃以及数据丢失，因此，首先需要使用Redis队列对亿级流量的广告信息首先进行一次缓存，保证数据能够稳定，不崩溃、丢失的保存下来，但是Redis队列虽然能够高速的缓存亿级流量广告信息，但是在掉电后，其所存储的数据将会丢失，因此还需要使用Kafka信息队列二次存储，虽然数据流量仍然庞大的，但是Kafka信息队列可以承受二次存储的队列，同时在断电和系统自行崩溃时，数据不会丢失。

S4读取Kafka信息队列中的广告信息，并使用分布式实时流处理框架计算广告的展示方式，并将展示结果存储于MySQL数据库中，上述的展示方式为广告ID和广告位ID的对应关系。在kafa信息队列存储了广告信息后，既可以进行对海量的广告信息进行统计、分析计算、并得出广告需要展示的各方面的信息，如广告ID对应广告位ID，即哪一广告在那个广告位进行展示。

优选的，在广告信息中包含有用户ID、设备ID、操作类型、操作时间、素材ID、素材url、广告组ID、合同ID，所述展示方式还包括广告ID和展示时长、展示周期的关系，广告ID和所需展示的效果的关系、广告ID和设备ID的关系。针对海量的广告信息，能够计算出特定的广告ID需要在什么时间，什么广告位展示多久，以及属于哪一广告组，哪一个合同，其使用的图片等等素材来自哪个url。

进一步的，由于广告信息为亿级的其数据量十分庞大，一般的数据流出系统、框架无法处理此数量级的信息，因此使用分布式实时流处理框架进行计算。分布式实时流处理框架能够有效利用计算资源针对大量的流数据进行计算。同时计算不会丢失数据、准确度高。优选使用storm分布式实时流处理框架针对广告信息进行计算。Storm框架中有益个试试计算的图状结构，即拓扑，storm中的集群使用主控节点分发代码分配工作节点，对广告信息进行计算和处理，storm分布式实时流处理框架具有低延迟，高可扩展和高容错性等诸多优点，对于复杂的且海量的广告信息处理能够十分准确和迅速。

作为一个可选的实施方式，步骤S4每间隔一段时间进行执行一次，对于亿级流量广告实时处理将会大量占用计算资源，同时会频繁的读写数据库，更新MySQL数据库。定时执行步骤S4能够节省计算资源，缓解数据库读写和MySQL数据量更新的压力。

举例来说，平台需要统计广告组A下的广告位B的素材C的点击量，使用的代码如下

设置变量：

Key＝A#B#C

SET(V,0)

检测时间戳是否达到预设的时间间隔t

if(now_timestamp-begin_timestamp<t){

如果没有达到，读取Kafka信息队列信息，并写入变量中

READ KAFKA AND SET(KEY,V++)

如果达到，将变量更新至MySQL数据库中：

进一步的，间隔的时间段以预设的某一参数数值的阈值为准，即当参数的数值在达到预设的阈值后，进行一次步骤S4，然后清零。具体的，

在对亿级流量的广告信息处理完成后，其展示结果，即广告ID及其对应的广告位ID、设备ID、操作类型、操作时间、素材ID、素材url、广告组ID、合同ID，所述展示方式还包括广告ID和展示时长、展示周期的关系，广告ID和所需展示的效果的关系、广告ID和设备ID，将被存储于MySQL数据库中，通过MySQL数据库使用结构化查询语言进行管理，同时速度快、稳定高、适应性强，能够快速存储处理后的展示结果，同时也方便平台、管理员对展示结果进行查询。

S5检验广告信息之间的映射关系数据是否被篡改，若未被篡改，则根据广告信息之间的映射关系数据展示广告。

优选的，为了防止广告信息黑客行为篡改，在广告展示之前对展示结果进行验证。

具体来说，获取映射关系数据中的广告信息是否存在于步骤S1中获取的广告信息中，若不存在，则判断映射关系数据被篡改。具体的验证的方式可以是比对广告url是否正确，展示广告位是否应对等等。验证方式为比对展示结果和广告信息，过滤掉无效数据。因为是篡改后展示的广告在广告信息中是不存在的，只需要将这些异常数据进行比对，过滤掉无效数据即可。

举例来说：展示结果中包含了合同ID为DYHT201503061266，但是在广告信息中并没有该合同ID，那么判断该信息为异常数据并消除。

综上所述，本亿级流量广告实时处理方法及系统通过Redis高可用缓存存储平台上生成的海量读写流量，经过Kafka信息队列完成实地存储，再使用storm数据流处理，对亿级流量的广告信息能够有效并及时的处理，辅助了平台广告展示数据化、广告展示智能化、广告合同决策自动化。

此外，本发明还提供一种存储介质，存储介质上存储有计算机程序，计算机程序被处理器执行时实现以下步骤：

S1：获取广告信息，所述广告信息至少包括广告ID、广告位ID。

S2：获取客户端的类型，将同一类型客户端的广告信息存放于一个或一组Redis队列。将广告信息区分客户端类型保存至Redis队列进一步的缓解了亿级流量广告在高峰期时候的读写压力，本步骤保证了亿级广告的安全、无丢失的实时读写保存，保证了数据的稳定和安全。

S3：将Redis队列中的广告信息存储于Kafka信息队列。通过Kafka信息队列的高吞吐量，使得Redis队列中的广告信息存储于Kafka信息队列的同时，能够保证了亿级流量的广告能存储在磁盘中不会经历系统崩溃、掉电等等，也能够较好的保证数据的存储。

S4：读取Kafka信息队列中的广告信息，并使用于分布式实时流处理框架计算广告信息之间的映射关系数据，并将映射关系数据存储于MySQL数据库中。分布式实时流处理框架能够有效利用计算资源针对大量的流数据进行计算。同时计算不会丢失数据、准确度高。

进一步的，所述广告信息还包括：

用户ID、设备ID、操作类型、操作时间、素材ID、素材url、广告组ID、合同ID。

进一步的，步骤S3中Redis队列中的广告信息还存储于本地磁盘，存储于本地磁盘的广告信息用于数据离线分析以及数据备份。

进一步的，步骤S2具体包括以下步骤：

将客户端分类为安卓端、IOS端和网页端；

将同一类型客户端的广告信息存放于一个或一组Redis队列。

进一步的，步骤S2具体包括以下步骤：

预设地域分类，根据客户端所在地域将客户端分类至不同地域；

将各个地域客户端分类为安卓端、IOS端和网页端；

将同一地域的同一类型客户端的广告信息存放于一个或一组Redis队列。

进一步的，步骤S4后还包括步骤S5，所述步骤S5为：

检验广告信息之间的映射关系数据是否被篡改，若未被篡改，则根据广告信息之间的映射关系数据展示广告。

进一步的，检验广告信息之间的映射关系数据是否被篡改的方法为：

获取映射关系数据中的广告信息是否存在于步骤S1中获取的广告信息中，若不存在，则判断映射关系数据被篡改。

本存储介质的好处在亿级流量广告实时处理方法的实施例中已经描述，为了节省篇幅，在此不再赘述。

需要说明的是，所述存储介质包括U盘、移动硬盘、ROM(Read-Only Memory，只读存储器)、RAM(Random Access Memory，随机存取存储器)、磁碟或者光盘等各种可以存储程序代码的介质。

另外，对应亿级流量广告实时处理的方法，本发明还提供一种电子设备，该电子设备存储有计算机程序，计算机程序被处理器执行时实现上述各实施例所述的方法的步骤。需要说明的是，所述电子设备包括存储器和处理器，存储器上储存有在处理器上运行的计算机程序，处理器执行计算机程序时实现上述实施例的稳步移动端显示方法。

本发明实施例提供亿级流量广告实时处理的系统，其包括暂存模块、存储模块和处理模块。

暂存模块，用于获取广告信息，所述广告信息包括广告ID、广告位ID，获取客户端的类型，将同一类型客户端的广告信息存放于一个或一组Redis队列，所述客户端包括安卓手机端、IOS手机端和网页端。

存储模块，用于将Redis队列中的广告信息存储于Kafka信息队列。

处理模块，用于读取Kafka信息队列中的广告信息，并使用于分布式实时流处理框架计算广告信息之间的映射关系数据，并将映射关系数据存储于MySQL数据库中。

优选的，系统中的广告信息中还包括用户ID、设备ID、操作类型、操作时间、素材ID、素材url、广告组ID、合同ID，所述映射关系还包括广告ID和展示时长、展示周期的关系，广告ID和所需展示的效果的关系、广告ID和设备ID的关系。

进一步的，因为广告的投放是有地域性的，如不同的省或者不同的国家投放的广告可能是不同的，因此，还可以先预设地域的分类，根据暂存模块中客户端所在地域将客户端分类至不同地域，然后再将各个地域暂存模块中客户端分类为安卓端、IOS端和网页端，将同一地域的同一类型客户端的广告信息存放于一个或一组Redis队列。除了针对客户端进行分类，对地域进行分类也能够对亿级流量的广告信息进行分流，缓解读写压力，保证平台的稳定和广告信息的安全。

优选的，存储模块除了将Redis队列的广告信息存储于Kafka信息队列中外，还将Redis队列中的广告信息存储于本地磁盘中，本地磁盘中的广告信息能够为平台管理人员进行离线分析提供数据基础，也能够为平台提供数据备份。

作为一个优选的实施方式，处理模块每间隔一段时间运行一次，对于亿级流量广告实时处理将会大量占用计算资源，同时会频繁的读写数据库，更新MySQL数据库。定时运行处理模块能够节省计算资源，缓解数据库读写和MySQL数据量更新的压力。

进一步的，为了防止广告信息黑客行为篡改，亿级流量广告实时处理的系统还包括校验展示模块，该校验展示模块用于在广告展示之前对展示结果进行验证。具体来说，获取映射关系数据中的广告信息是否存在于暂存模块中的广告信息中，若不存在，则判断映射关系数据被篡改，如果存在根据映射关系数据则进行展示。

前述方法实施例中的各种变化方式和具体实例同样适用于本实施例的系统，通过前述方法的详细描述，本领域技术人员可以清楚的知道本实施例中系统的实施方法，所以为了说明书的简洁，在此不再详述。

总体来说，本发明实施例提供的亿级流量广告实时处理方法、存储介质、电子设备及系统，通过，相较于传统的技术等等，能够通过Redis高可用缓存，Kafka信息队列、分布式实时流处理框架能够更好的针对亿级流量的广告信息进行分析和处理，使得广告的展示能够更加的合理。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (10)

1.一种亿级流量广告实时处理方法，其特征在于，其包括：

S1：获取广告信息，所述广告信息至少包括广告ID、广告位ID；

S2：获取客户端的类型，将同一类型客户端的广告信息存放于一个或一组Redis队列；

S3：将Redis队列中的广告信息存储于Kafka信息队列；

S4：读取Kafka信息队列中的广告信息，并使用于分布式实时流处理框架计算广告信息之间的映射关系数据，并将映射关系数据存储于MySQL数据库中。

2.如权利要求1所述的一种亿级流量广告实时处理方法，其特征在于，所述广告信息还包括：

用户ID、设备ID、操作类型、操作时间、素材ID、素材url、广告组ID、合同ID。

3.如权利要求1所述的一种亿级流量广告实时处理方法，其特征在于：步骤S3中Redis队列中的广告信息还存储于本地磁盘，存储于本地磁盘的广告信息用于数据离线分析以及数据备份。

4.如权利要求1所述的一种亿级流量广告实时处理方法，其特征在于，步骤S2具体包括以下步骤：

将客户端分类为安卓端、IOS端和网页端；

将同一类型客户端的广告信息存放于一个或一组Redis队列。

5.如权利要求1所述的一种亿级流量广告实时处理方法，其特征在于，步骤S2具体包括以下步骤：

预设地域分类，根据客户端所在地域将客户端分类至不同地域；

将各个地域客户端分类为安卓端、IOS端和网页端；

将同一地域的同一类型客户端的广告信息存放于一个或一组Redis队列。

6.如权利要求1所述的一种亿级流量广告实时处理方法，其特征在于，步骤S4后还包括步骤S5，所述步骤S5为：

检验广告信息之间的映射关系数据是否被篡改，若未被篡改，则根据广告信息之间的映射关系数据展示广告。

7.如权利要求6所述的一种亿级流量广告实时处理方法，其特征在于，检验广告信息之间的映射关系数据是否被篡改的方法为：

获取映射关系数据中的广告信息是否存在于步骤S1中获取的广告信息中，若不存在，则判断映射关系数据被篡改。

8.一种存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现以下步骤：

S1：获取广告信息，所述广告信息至少包括广告ID、广告位ID；

S2：获取客户端的类型，将同一类型客户端的广告信息存放于一个或一组Redis队列；

S3：将Redis队列中的广告信息存储于Kafka信息队列；

S4：读取Kafka信息队列中的广告信息，并使用于分布式实时流处理框架计算广告信息之间的映射关系数据，并将映射关系数据存储于MySQL数据库中。

9.一种电子设备，包括存储器和处理器，存储器上储存有在处理器上运行的计算机程序，其特征在于：所述处理器执行所述计算机程序时实现权利要求1至7任一项所述的方法。

10.一种亿级流量广告实时处理系统，其特征在于，其包括：

暂存模块，用于获取广告信息，所述广告信息包括广告ID、广告位ID，获取客户端的类型，将同一类型客户端的广告信息存放于一个或一组Redis队列；

存储模块，用于将Redis队列中的广告信息存储于Kafka信息队列；

处理模块，用于读取Kafka信息队列中的广告信息，并使用于分布式实时流处理框架计算广告信息之间的映射关系数据，并将映射关系数据存储于MySQL数据库中。