博客首页|TW首页| 同事录|业界社区

之前大白话聊了SDKAPI,今天我们来聊聊同步和异步。

看到这两个词可能很多同学会有如下反应:

什么鬼?

跟我数字营销业务实践中有关系吗?

好像也听过什么同步监测代码异步监测代码的?

那我们就一起来快速了解了解吧。

01

什么是同步异步?

同步、异步的概念最常出现的应该是在软件编程领域,软件工程师大都知道这两个词的含义和区别。

而在数字营销领域由于跨系统实时协作、数据采集/交互等技术层面的互动越来越多,使得业务相关的同学也不得不需要了解相关的概念和区别了。

同步:即所有事情排着队一件件的往后进行,上件事情没有完成,就继续做上件事情,等上件事情完成后才会去做下一件事情。

有点像一根串着的糖葫芦。

一般情况下,软件编程代码默认都是顺序执行的,也即同步的,只有在需充分考虑处理的高性能和效率的时候才会改用到异步模式,而在软件编程代码及系统架构上也会有所针对性的调整,而且这种调整可能会是体系性的改动,改动量非常大。所以这也是我们常说的系统设计是不是足够的具有前瞻性和可扩展性。

相关英文:synchronization; synchronism; synchro; sync-

异步:即很多事情可以一起并排着去做,不同于同步那样,非要等上一件事情做完了才能去做下一件事情。

相关英文:asynchronous; nonsynchronous; asynchronization; async-

听上去好像异步更高效一些对吧?那同步会主要用在什么场景下呢?

在互联网络大量高并发的数据处理环境下,很多时候有些事务的处理,存在一定的最小粒度单元。例如:我在登记一个客户的订单,是分客户资料表和订单表分开记录的,那么就要起一个同步锁,确保先记录该客户的资料后,才能去建立该客户的订单。假设采用异步并排处理的话,若客户资料登记失败,而订单登记成功,就会形成无效的脏数据,而且也会造成业务无法开展,如从订单无法追溯客户相关信息进行快速或售后等服务。

由于是太技术化的术语,我就不做过多描述了,我们还是来看看在具体的那些,我们常见的业务实操场景中,我们需要多多注意的坑吧。

02

监测场景

第三方监测或需监测采集网络媒体广告的曝光点击数据,是非常典型的场景之一。

早期大都以同步的方式传递监测数据:http302跳转(即浏览器访问某URL时,服务端回应302重定向信号给浏览器,指引浏览器跳转到新的URl地址);

以串行方式触发监测各方的代码,浏览器始终在同一session中,很多上下文数据可延续传递,但由于这样会存在网络损耗,每一次跳转可能会有3-10%的损耗;

传统点击监测也常为同步模式:媒体点击收数 -> Adserving方点击收数 -> 第三方监测收数 -> 落地页;

可以简单理解为点击监测链接和落地页链接是串联的链接,媒体浏览器或App打开了点击监测链接,最终即会跳转打开广告主的落地页链接;

早期的一些曝光监测也是类似的同步机制跳转给各方发送的。

可见同步机制在数据上下文数据可延续传递上是有一定优势的,但存在由于多次跳转带来的网络损耗,所以现在越来越多的媒体会转向异步机制。

异步:由媒体端统一并行触发所有方监测代码:可以简单理解为点击监测链接和落地页链接不同,每次当广告触发点击后,媒体会单独触发点击监测记数,单独起窗口打开落地页;

媒体浏览器或App会单独打开广告主落地页链接,同时通过网络接口调用点击监测链接上报点击数据;所以若媒体打开广告主落地页链接的App浏览器窗口不支持302跳转的话,此时落地页链接一定不能想当然的那个样使用之前同步的点击监测代码,想当然的以为最终能通过302跳转能打开广告主落地页,这是血的教训,这个点上需要多加小心,需要多多线上环境测试,很多媒体环境媒体软件工程师手抖一下加少个参数,巨大灾难的坑就会出现。

而且由于落地页会丢失一些session上文数据相关信息,想通过落地页中的动作再关联点击、曝光等数据会受阻,例如通过落地页中的cookieID去回溯曝光点击的设备ID等都会很麻烦。

当然如前所述,媒体为减少数据损耗,会更多地推广异步机制。

所以异步点击监测代码,大家要千万小心哟。

03

实时问询场景

在大数据程序化广告领域,多系统间实时问询的场景非常多。例如:DMP问询、ADXRTB多买家竞价问询、pre-bid竞价前的实时品牌安全及反作弊问询等。

这些都是非常典型的异步场景,若采用同步模式的话,根本玩不转的,只要任何一方被问询的系统或网络掉链子,同步模式下发起问询的系统也会被拖垮崩溃的。

所以发起问询的系统往往会采用异步模式,并对响应方进行响应时长的限制。

例如RTB非常典型的,包含来回网络处理的行业标准,要在100ms以内完成,若超出这个时长,本次问询的响应视为自动放弃。更有甚之的,有些媒体的这个处理时长会压缩的很短,有40ms的。

当然细心的同学可能会有体会了,发起问询的时机点越早,给后续问询响应方留出足够的时长空间就越大了,这样也就会迫使发起问询系统内部也要完全的异步化改造,例如pre-bid竞价前问询,DSP刚拿到这个广告曝光机会竞价请求的时候,通过简单筛选后,自己还有很多处理未完成的可改为并行处理(例如出价、匹配素材等),这个时候就可以直接发出问询反作弊请求,这样做至少可以将自己处理的10ms时长,都让出来给到实时问询响应方。

所以细节是魔鬼,一个系统是否高效优秀高可用可扩展,全都在细节。

04

实时数据采集场景

实时数据采集场景在大数据时代也是非常常见的一种典型场景。

很多时候大数据系统由于数据存储IO操作的速度会大大慢于数据流入的速度,所以会大量采用队列的异步处理模式,以及原始数据先存下来,再后续清理、分析、业务化抽取等等异步化的数据处理流程。

而且若存在多方协作进行数据采集/使用,类似监测场景也是有多方共同参与的,为了提高异步处理的效率,尤其随着现在IOT物联网的设备越来越多,很多物联网的网络情况并不稳定。所以大家会采用分布式存储的模式,而且会采用时间戳对数据包进行不可逆加密不可篡改,待网络条件允许的时候,再对全网络节点同步分享数据包的模式,来完成大规模数据异步的处理,这也基本就是大家常说的区块链技术了。

如以广告曝光点击转化监测数据回收为例,若多方同时记录了广告曝光、点击、转化的数据,并以不可篡改的方式存储了数据包,那么若某一方为了KPI的完成,想单方面篡改数据的成本势必增加。只有在他发起所以一系列连续动作的数据请求之前就已经谋划好了成套数据才有可能的。而这种事前谋划制造成套数据的成本,可能往往比多制造些真实有效流量的代价更高。

所以我之前也常说自动化、程序化、透明化无法彻底杜绝作弊,但是会大大增加作弊成本。这也是整个行业不断朝着这个方向高歌猛进非常大的原因之一。

关于同步和异步,还有很多值得注意的坑点和优化点,需要我们在日常工作中时刻关注。

感兴趣的同学也可关注视频课程深度学习。

- 广告分割线 -

若大家看文章还不过瘾,更多精彩干货尽在如下视频课,还有更多内容在路上:

24小时精通程序化广告课程录播_高清PPT_不限时》

16小时入门Martech数字化转型,玩转广告商业化》

《大数据人工智能贯穿广告营销作业前中后期的创新应用》

《统计学基础入门(0基础统计学上手实务系列大数据人工智能的重要基石)》

0基础迅速掌握演讲技能》

《运营优化A/B测试统计学实务(0基础统计学上手,大数据人工智能的重要基石)》

《线性智能预测统计学实务(0基础统计学上手实务系列大数据人工智能的重要基石)》

视频课程直播间链接如下:

https://m.qlchat.com/wechat/page/live/2000006286471842

(转载请注明出处:微信订阅号:ad_automation


上一篇: 移动广告流量中那些ID的坑
下一篇:广告商业化要知道钱从哪里拿?

评论

Good.Be the first to comment on this entry.

发表评论