广告增量实时索引构建实践

本期作者

1.前言

在广告检索系统中,增量索引(实时索引)是一类常见的技术,用于使广告信息的变更及时生效。其中一种主要的思路即由检索系统消费广告更新数据流,实时更新内存索引,对此行业中已有很多优秀方案实现。然而,对与如何构建出“广告更新数据”,却鲜有提及。

本文将针对如何构建出完整、可靠、可维护的“广告更新数据流”进行展开叙述。

2.业务背景

在线广告是实现流量变现重要业务模式。广告检索系统是其中的核心系统之一,其一种常见的架构是由“索引构建服务”构建出广告物料索引数据,再由“检索引擎”加载数据,用于在线广告检索。

相比于搜索或推荐业务,广告的物料数据量不算最大,但构建逻辑极其复杂。以下图为例,构建广告物料索引以单元(unit)表为核心,查询相关的账号(account)、计划(plan)、创意(creative),进而再通过创意id查找图片(image),视频(video),up主(up)等。

图片

相关数据查询完后,提取各表数据并组装,形成一个个“广告文档(doc)"。单个doc的文本的形式如下:

图片

由于单元数据量较大,相关数据库表多(超过100张表),这些单元还分属不同的业务线、不同类型、不同样式,所关联的构建逻辑也不尽相同,形成了复杂的查找链路。

并且,随着业务量越来越大,整体的延迟越来越长,广告的物料数据更新不及时,影响了广告的时效性,最终降低了广告的投放体验和效率。

3.方案演进

广告索引的构建和下发经历了漫长的优化迭代,包括本文主要介绍的增量索引在内,主要分为如下三个阶段:

阶段一:全量串行——所有数据串行查询,串行构建

阶段二:分批间并行,批次内并行——将全量的单元id分为多个批次,多批次间并行执行,批次内按照数据依赖的拓扑关系并行查询组装

阶段三:增量构建+全量构建——定时构建的广告索引,有数据发生变更则构建发生数据变化的这部分广告物料索引

阶段一:全量串行

阶段二:分批并行

阶段三:增量+全量

流程

图片

图片

图片

特点

数据库负载:一般

构建耗时:长

数据传输负载:很高

数据库负载:很高

构建耗时:较短

数据传输负载:很高

数据库负载:很低

构建耗时:全量耗时长,增量耗时很短

数据传输负载:很低

从阶段一到阶段二,在时效性上有一定提升,但是给数据库带来了很大的压力,且网络传输负载很高。

在查询全量数据的前提下,无论做何种并行化优化,该查的数据还是得查,数据库负载会随着业务扩张不断增加,数据量也会一直膨胀,更新时效性也越来越差,优化的边际递减效应明显。

因此阶段三中引入了增量索引技术,采用全量索引+增量索引的构建模式。

4.增量索引

增量索引的广告物料分为两类:

  • 全量广告索引——定时(1小时或者更长)全量构建所有广告单元数据,产出一份包含全量单元的索引数据

  • 增量广告索引——只构建数据发生了变化的广告单元,单独产出一份增量单元索引数据

两者的触发机制不同,产出的数据结构类似,但是包含的内容范围不同。

图片

如上图,紫色模块是全量索引构建的流程,蓝色部分是增量索引构建的流程,绿色部分是公共的部分。全量增量的主要差异在于:全量索引任务的unit_id是所有单元的unit_id,增量索引任务的unit_id是广告数据发生变化的单元的unit_id。

下游检索引擎加载这两类索引,将其合并成一个整体,作为广告物料库使用。

相比起之前的全量方案,增量索引的方案里的全量索引构建频率降低到小时级别,增量只构建和下发发生变化的广告单元,大大降低了数据库负载和数据传输的带宽,提高了更新时效性。

变化的unit_id —— 反查库表?

上图中,接收到DB的原始变更消息后,还需要将其转译为相关变化的unit_id。那么,当单元关联的上百个实体(表)中,部分的数据发生了变化时,如何确认其对应的哪个unit_id发生了变化?

一种简单的想法是根据实体之间的逻辑联系,根据发生变化的实体id反查出其关联的unit_id。

例如下图中,若检测到up.up_icon发生了变化,可通过video表查找出与up_mid关联的video_id, 再通过creative表以video_id为条件查找出关联的unit_id。

图片

上述逻辑看起来是通顺的,然而理清“实体之间的逻辑联系”实际执行时却相当困难。

举几个例子说明:

例1:缺少索引,不适合反查

上图中的例子已经隐约可看出反查unit_id的困难之处,一条记录变更需要通过多次反查才能找到目标。而且在实际应用中,并非每张表都适合反查,例如图中的creative.video_id字段其实并没有索引,若以video_id为条件进行查询,则会发生全表扫描,效率极低。

例2:字段类型复杂,无法反查

除此以外,还可能存在反查条件字段难以直接用于查询的情况。例如下图中,若source表中id位101的数据发生了变化,则需要以"source_group.slot_ids包含101"为条件才能查找出对应的source_group.id,难以执行。

图片

例3:逻辑复杂很难理清

即便没有上述数据库查找问题,分析实体间关联关系本身也是有一定难度的。如下图,unit和video以多种路径相关联,编写反查逻辑时需要覆盖多种情况,容易遗漏。况且,对广告相关的上百张表都要做此分析,极大地增加迭代和维护成本。

图片

利用历史索引?

反查库表难以执行,那么尝试换一种思路。在全量构建索引时,单元相关的实体数据通常已经记录在doc中,那么能否考虑从历史已构建出的doc中直接根据变化的条件查找出对应的广告?

例如,历史全量索引存储了每个有效广告关联的up_mid列表。那么当up表的数据变化时,如果遍历此前已构建出的有效历史索引中的每一个doc,即可查找出哪些广告unit_id关联了这个变化的up_mid,从而触发这些广告的增量更新。

但如此一来,又引发了以下三个问题:

问题1

广告doc的数据结构非常复杂,层级众多,从其中找出up_mid的逻辑是定制的;对每一个unit表的关联实体都需要定制,产生大量与构建过程耦合的代码,仍然容易出错。且对层级很深的数据,查找的代码编写起来也有难度。

图片

问题2

每次触发同类事件时,都需要遍历历史索引中的每一个doc,遍历过程系统开销大、耗时长,难以满足业务需求。

问题3

这种方式查找出的广告unit_id是比预期更少的,因为在索引构建过程中可能发生过滤,而当这个过滤条件被满足时理应触发被过滤的广告更新,但由于被过滤的广告ID不会被保存下来,因而无法触发。

比如,plan某条记录的状态为“关闭”,导致索引里没有与其相关联的unit,某个时刻,这条plan记录的状态从“关闭”变更为“开启”,此时应该触发相关单元的构建,但是由于历史索引里缺少数据而无法触发。

在构建过程中记录关联关系

上面的问题1,本质就是要从广告的索引数据结构中查找出其关联的其他各类ID,相关代码定制性强,耦合度高,可维护性差。

因此需要寻找一种方法,可以用标准化、低耦合、自动化程度高的方式记录下每一个广告单元ID与其他各类ID之间的关联,与索引数据一同存储下来, 从而当捕获到某种触发事件时,无论其与广告之间的关系有多么曲折,直接从这份关联数据中查找到。

为了建立一一对应的关联关系,且方便从其他实体的ID反查出广告单元ID,在此对构建的流程做出以下假设:

  • 假设1:构建逻辑针对每一个待构建的广告单元,是逐个处理的(而不是批量处理),不同单元的构建过程之间不存在逻辑上的关联。

  • 假设2:构建指定的单个广告单元,从数据源获取相关数据时,都是通过类似"KV"形式的模块(称之为“取数器”)进行获取。

举个例子,假如有如下的关系表依赖:

图片

一般而言,每个表对应一个“取数器”,根据上述的关系依赖,每个取数器的入参和返回可定义如下:

interface UnitBaseService {  // 获取广告单元的基本信息,这些信息不足以直接使用,需要拼装其他数据  UnitBase getUnitById(long unitId);}interface CreativeService {  // 获取创意  List<Creative> getCreativeByUnitId(int unitId);}interface VideoService {  // 获取视频 Map<Long, Video> getVideoByVideoIds(Iterable<Long> videoIds);}interface UpService {  // 获取Up主 Map<Long, Up> getUpByUpMids(Iterable<Long> upMids);}

在此基础上,查询数据的流程示意如下:

class Assembler {  UnitBaseService unitBaseService;  CreativeService creativeService;  VideoService videoService;  UpService upService;  // 组装单个广告  Unit assembleUnit(long unitId) {    UnitBase unitBase = unitBaseService.queryByUnitId(unitId);    List<Creative> creativeList = creativeService.queryByUnitId( unitId );    从 creativeList 中提取出 videoIds    Map<Long, Video> videoMap = videoService.queryByVideoIds( videoIds );    从 videoMap 中提取出 upMids    Map<Long, Up> upMap = upService.queryByUpMids( upMids );         // ...    // 将所有相关数据组装起来,成为可用的广告单元数据;    Unit unit = doAssemble(unitBase, creativeList, videoMap, upMap);    return unit;  }}

上述的查询流程方法(assembleUnit)中,输入参数只有一个unitId,满足了假设一。在assembleUnit方法里调用服务查询时,各种输入参数(videoIds,upMids)便和唯一的unitId关联起来。

图片

如上图所示,unit_id和其他表字段的联系可以构建如下:

关系

1unitId → accountId
2unitId → planId
3unitId → videoIds → upMids

前两条关系是直接关系,当account表和plan表的数据发生变化时,都可直接追溯至unitId。

但第三条关系 unitId → videoIds → upMids,关联了超过2类id,从unitId到upMids是间接关系,在实际检索中很难使用。

使用直接关系替代间接关系

间接关系是很难使用和维护的,将间接关系转为直接关系。如下图所示:

关联关系直接关系
unitId → videoIds → upMids

unitId → videoIds

unitId → upMids

举例说明直接关系如何运作,存在如下的数据:

图片

建立的直接关系如下:

(unitId → videoIds)

(unitId → upMids)

111111 → 444444,555555111111 → 666666, 777777

如果up表里的up_icon发生了变化,从 pic1.jpg 变为 pic2.jpg,对应的这个up_mid是777777.

图片

在unitId → upMids的关系里,存在111111 → 666666, 777777的关系,因此这个变化可以被捕获并反查出变化的unit_id 111111,由此触发了111111这个单元的构建。

因此从间接关系拆为直接关系后,up表的变更无需通过video表,即可查出来哪些unit_id发生了变化。

框架自动捕获依赖关系

具体到框架层面,使用装饰模式(可用AOP技术、静态代理、动态代理等技术实现),自动地记录下构建过程中unit关联的其他ID(account_id, plan_id)的关系。

// 代表一个广告单元一次构建过程的上下文; 其中的各类Service是被装饰过的,含有记录所访问ID的功能
class BuildingContext {UnitService unitService;CreativeService creativeService;VideoService videoService;UpService upService; 
}// 上下文工厂,在其中可以对各类Service进行装饰,自动记录unitId与其他ID的关联关系
class BuildingContextFactory {UnitBaseService unitBaseService;CreativeService creativeService;VideoService videoService;UpService upService;BuildingContext getContext(long unitId) {// decoratedUpService是经过装饰的UpServiceUpService decoratedUpService = new UpService() {Map<Integer, Up> queryByUpMids(Iterable<Long> upMids) {// 记录下unitId与被查找的upMids存在关联record(unitId, upMids);// 调用基本功能return upService.queryByUpMids(upMids);}};// decoratedVideoService同理VideoService decoratedVideoService = new VideoService(){ ... };return new BuildingContext(unitBaseService, creativeService, decoratedVideoService, decoratedUpService);}
}
// 记录一个单元与其他ID存在联系;这里仅用于示意,实际开发中的定义会更加抽象,自动适用于各类ID
class UnitRelation {long unitId;List<Long> creativeIds;List<Long> videoIds;
}
// 组装器可得知待更新广告单元ID列表
List<Long> unitIds;
for(long unitId : unitIds) {// 调用AssemblerBuildingContext context = buildingContextFactory.getContext(unitId);Unit unit = assembler.assembleUnit(unitId, context);// 导出构建过程中发现的unitId与其他各类ID的关联,并与索引数据一同记录下来UnitRelation unitRelation = exportRelation(context);record(unitRelation);
}

特别注意的是,在上述的record(unitId, videoIds)方法里,直接记录了unitId和upMids的关系。

从而,问题1得到解决;同时由于提前记录了关系而不受过滤的影响,也解决了问题3

生成关系倒排表

接下来则要解决问题2,即提高查找关联的效率

由于在上述的构建流程中记录了广告单元ID其他各类ID之间的关联后,如此一来,可以形成其他表和unit_id的关系如下:

unitId

account_id

plan_id

video_id

up_mid

u1[a1][p1][v1,v2][m1, m2]
u2[a1][p2][][]
u3[a2][p3][v3][m2]
u4[a2]

[p3]

[v1]

[m1]

在以上关系中,每行是unit_id构建一次时建立的直接关系。实际使用场景是关联表数据发生了变化需要回溯到单元id。

为此将其转化为如下的倒排关系

relationrelation_idunit_id

account_id
a1

[u1, u2]

a2[u3, u4]
plan_idp1[u1]
p2[u2]
p3[u3, u4]
video_idv1[u1, u4]
v2[u1]
v3[u3]
up_midm1[u1, u4]
m2[u1, u3]

如此一来,如果up表里up_mid为m1的记录的up_icon发生了变化,可快速从上述的表中通过m1→[u1,u2]的关系记录,反查到单元id为u1和u2的单元需要重新构建,问题2也得到解决。

检测数据变更

上述方案解决了核心问题:当数据发生变更时,检测出影响到的unit_id。

而对于如何检测数据变更,本方案采用了如下两种:

1.binlog触发

即监听binlog消息,提取出直接关系的id。

图片

以video表的binlog为例,由于binlog里有修改前和修改后的记录的完整信息,因此不论是修改了关联字段还是删除,都可以找到对应的video_id,进而反查出unit_id。

Binlog触发时效性高,且信息完整,可以体现硬删除和变更前旧值的信息,是主要的检测手段。但其对于生产、投递、消费各环节可靠性要求较高,不能丢失消息。

2.近期扫描触发

按我司数据库规范要求,所有表必须携带mtime(最后修改时间),因而可用mtime检测近期的数据变更情况。

但这种方式有所缺陷:1. 时效性较低;2. 不可用于检测硬删除的情况;3. 不能直接获取变更前的旧值。

并且,还有一类update的情况需要注意,例如有如下表the_table

material_id

unit_id

material_content

mtime

m1u1content1yesterday

通过类似这样的sql可以发现最近变更的unit_id:

-- SQL1select unit_id from the_table where mtime >= 'today'

如果发生了下面SQL2这样的update,则该条记录的mtime会发生变化,因此上面的SQL1检测到unit_id(u1)的变化​​​​​​​

-- SQL2update the_table set material_content = "something else" where unit_id = 'u1'

但如果是下面SQL3这样的更新操作,则无法检测到u1单元的变化:​​​​​​​

-- SQL3update the_table set unit_id = `u2` where unit_id = 'u1'

虽然该条记录的mtime仍然会发生变化,但同时unit_id也发生了变化,通过SQL1查询出的结果只有u2, 而不包含u1

因而,unit_id为u1的记录发生了变化,却不会被监测到,这是不符合预期的。

针对这样的问题,有以下解决方式:

1.与业务端约定,凡在组装器(假设2)中作为ID检索条件的字段,不能够被update

  • 作为检索条件的字段,通常也是实体ID;记录实体间关系的记录,通过update改变关系的情况较少

2.方式1无法满足时,可以稍微改造组装器逻辑:

  • 原本组装器中sql select * from the_table where unit_id = 'u1',即查出该表与u1相关的记录,而不需要查找关联关系

  • 现改为:select material_id from the_table where unit_id = 'u1',可查出关联的m1 ,再执行select * from the_table where material_id in ('m1'),可查出相关记录

  • 这样一来,关联关系中会记录m1与u1存在关联关系

  • 既然material实体与unit相关,那么就需要检测其变化select material_id from the_table where mtime >= 'today'

  • 再代入执行上面的SQL3,虽然库中记录的unit_id被改为了u2,通过SQL1已不能直接查出u1的变化,但我们能够查出material m1的变化

  • 再配合历史记录的m1与u1的关联关系,即可得知u1也发生了变化,从而触发u1的重新构建

降频

在上述两种触发器中,对任何相关实体的所有信息变化都触发相关广告变更,可能是没有必要的。因为有很多变化实质上并不会影响索引的构建结果。这种情况下触发变更会增加构建器及其依赖数据源的压力,还会使得检索系统中累计更多的增量,是对资源的浪费。

因而可对无用的触发进行降频。采用技术如下:

无关字段降频

  • 索引构建中,对某个实体表很可能并没有使用到全部字段,而是只使用其中一部分,那么当其中只有不关注的字段发生变化时,可以不触发构建

  • binlog触发器中,可以对比新旧值,判断是否有受关注字段发生了变化

  • 近期扫描触发器中,由于无法直接获取旧值,可以配合取数器,在每次取数时缓存旧值,触发时使用缓存旧值与当前值对比

分级降频

  • 对数值类、或可聚合的实体信息,并非任何一点变化都需要触发,可以分级处理

  • 例如稿件的收藏数从1000变为1001时,这一变化很可能并不会影响广告的策略或样式,则可以不触发构建

  • 对此,可将数值类信息进行分级,通过对比新旧值的级别是否发生变化,决定是否触发构建

  • 同样binlog触发器中可获取到新旧值直接计算分级和对比,近期扫描触发器中可以配合取数器缓存判断

状态降频

  • 若将实体分为有效和无效状态:有效状态即为索引构建需要纳入该实体的状态;反之,无效状态即索引构建无需纳入该实体的状态

  • 若实体处于有效状态时,其他的受关注字段变化时应当触发构建

  • 若发现实体在有效、无效状态间切换,也应当触发构建

  • 若实体处于无效状态,则即使其受关注字段变化,也无需触发构建

低优降频

  • 并非所有的实体信息变化都是需要立即反馈在索引中的,对于时效性要求较低的变更,可以暂不触发,而是等待全量触发,或主动全量触发

整合流程

倒排关系和框架整合进构建流程如下:

图片

全量索引构建流程(图中紫色的模块,绿色部分是公共流程)

1.全量索引定时构建开始,查询单元表(unit),产出所有的unit_id,

2.以每个unit_id为入参,控制每一个unit_id的调用组装流程

3.使用装饰的取数器查询数据库,获取全量的数据

4.组装广告物料

5.产出全量广告索引和倒排关系,其中全量广告索引供在线广告检索引擎使用

增量索引构建流程(图中蓝色部分)

1.接受db的变更消息——扫描mtime 和 接受binlog

2.从接受的消息中提取出实体id,并加载倒排关系索引

3.根据倒排关系索引和变更的实体id,回溯出需要更新的unit_id

4.以每个unit_id为入参,控制每一个unit_id的调用组装流程

5.使用装饰的取数器查询数据库,获取全量的数据

6.组装广告物料

7.产出增量广告物料索引供在线广告检索引擎使用,同时更新倒排关系数据

通过增量索引技术,实现了广告变更秒级对在线检索引擎生效,同时构建过程对数据库压力大幅降低,相关的数据存储、传输开销也得到了大幅优化。

5.思考展望

增量构建从根本上解决了全量构建带来的数据库负载高,数据传输量大的问题。下游接入增量构建物料后,广告的延时降低到秒级别,且CPU、内存、网络IO等资源的使用效率得到了明显改善,在此过程中,研发团队也积累了丰富的经验和知识,将为未来的项目研发提供了重要支持。

根据目前线上迭代情况,存在以下问题需要持续优化:

增量物料易用性优化

增量物料是由全量和增量两个部分组成的,业务方在使用的时候需要对其进行合并,这会带来一定的接入困难,如何更好的让系统适配全量加增量的模式,是该方案能得到推广的一大保障。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/762997.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

OpenHarmony开发之图形UI组件解析

简介 图形UI组件实现了一套系统级的图形引擎。 该组件为应用开发提供UIKit接口&#xff0c;包括了动画、布局、图形转换、事件处理&#xff0c;以及丰富的UI组件。 组件内部直接调用HAL接口&#xff0c;或者使用WMS(Window Manager Service)提供的客户端与硬件交互&#xff…

数据结构之排序一

目录 1.排序 一.概念及其分类 二.排序的稳定性 2.插入排序 一.基本思想 二.插入排序的实现 复杂度 稳定性的分析 3.希尔排序 一.预排序代码的实现 二.希尔排序代码实现 复杂度分析 4.clock函数 1.排序 一.概念及其分类 说到排序&#xff0c;我们都不陌生&#x…

设计数据库之概念模式:E-R模型

Chapter3&#xff1a;设计数据库之概念模式&#xff1a;E-R模型 笔记来源&#xff1a;《漫画数据库》—科学出版社 设计数据库的步骤&#xff1a; 概念模式 概念模式(conceptual schema)是指将现实世界模型化的阶段进而&#xff0c;是确定数据库理论结构的阶段。 概念模式的设…

Ubuntu 安装 Carla仿真环境

1、系统要求 Ubuntu 16.04/18.04/20.04 CARLA 为 16.04 之前的 Ubuntu 版本提供支持。然而&#xff0c;Unreal Engine需要合适的编译器才能正常工作。 CARLA 服务器至少需要 6 GB GPU&#xff0c;但建议使用 8 GB。 2、安装NIVDIA驱动 BISO设置 开机F12&#xff0c;进入BIOS…

29-中断管理

中断管理 什么是中断管理&#xff1f; 用户可以自定义配置系统可管理的最高中断优先级的宏定义configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY&#xff08;高四位有效&#xff09;&#xff0c;它是用于配置内核中的basepri 寄存器的&#xff0c;当 basepri 设置为某个值的时候…

org.springframework.boot:type=Admin,name=SpringApplication异常

javax.management.InstanceNotFoundException: org.springframework.boot:typeAdmin,nameSpringApplication 问题描述&#xff1a; IDEA 新建 SpringBoot 项目&#xff0c;启动时后台报错&#xff1a; javax.management.InstanceNotFoundException: org.springframework.boot…

基于springboot的牙科就诊管理系统

技术&#xff1a;springbootmysqlvue 一、系统背景 当前社会各行业领域竞争压力非常大&#xff0c;随着当前时代的信息化&#xff0c;科学化发展&#xff0c;让社会各行业领域都争相使用新的信息技术&#xff0c;对行业内的各种相关数据进行科学化&#xff0c;规范化管理。这样…

粤嵌6818开发板如何理解Linux文件IO?

一、文件IO的概述 1、什么是文件&#xff1f; Linux下一切皆文件。普通文件、目录文件、管道文件、套接字文件、链接文件、字符设备文件、块设备文件。 2、什么是IO&#xff1f; input output&#xff1a;输入输出 3、什么是文件IO&#xff1f; 对文件的输入输出&#xff0c;把…

轻松找回丢失数据EasyRecovery数据恢复软件让你无后顾之忧

轻松找回丢失数据&#xff0c;EasyRecovery数据恢复软件让你无后顾之忧&#xff0c;电脑数码行业必备工具&#xff0c;让你的数据安全有保障 &#xff01; 一、EasyRecovery数据恢复软件简介 在我们的日常生活中&#xff0c;无论是工作还是学习&#xff0c;都离不开电脑和数据…

Linux/Perfection

Enumeration nmap 用 nmap 扫描了常见的端口&#xff0c;发现对外开放了 22,80&#xff0c;扫描一下详细信息&#xff0c;如下所示 ┌──(kali㉿kali)-[~/vegetable/HTB/Perfection] └─$ nmap -sC -sV -p 22,80 10.10.11.253 -oA nmap Starting Nmap 7.93 ( https://nmap…

目标检测——DOTA航拍数据集

DOTA数据集是一个用于航空图像中目标检测的大规模数据集&#xff0c;旨在帮助研究人员开发和评估航空图像中的目标检测算法。该数据集具有广泛的应用价值&#xff0c;尤其在计算机视觉和遥感技术领域。 DOTA数据集的特点主要体现在以下几个方面&#xff1a;首先&#xff0c;其…

408学习笔记-14-C-数据在内存中的存储

1、整数型存储 整数型存储就是所有整型家族里的数据类型的存储方式&#xff0c;也就是说包含了字符类型的存储&#xff08;因为字符的操作符的返回值是ASCII码值&#xff0c;故实际上存储的是整数&#xff09;。 1.1、有符号整数 有符号整数包含char&#xff0c;short&#x…

如何做接口测试?

今天来聊聊接口测试&#xff0c;现在是2024年了&#xff0c;打开招聘网站随便点开一个招聘帖子&#xff0c;几乎都可以看到岗位JD要求写着有接口测试经验优先。其重要性可见一斑&#xff01; 目前&#xff0c;凡是好一点稍具规模的公司哪怕是大厂外包也几乎都要求会接口测试&a…

QT(6.5) cmake构建C++编程,调用python

一、注意事项 explicit c中&#xff0c;一个参数的构造函数(或者除了第一个参数外其余参数都有默认值的多参构造函数)&#xff0c;承担了两个角色&#xff0c;构造器、类型转换操作符&#xff0c; c提供关键字explicit&#xff0c;阻止转换构造函数进行的隐式转换的发生&#…

使用Docker搭建YesPlayMusic网易云音乐播放器并发布至公网访问

目录 ⛳️推荐 1. 安装Docker 2. 本地安装部署YesPlayMusic 3. 部署公有云YesPlayMusic播放器 3.1 安装cpolar内网穿透 3.2 固定YesPlayMusic公网地址 ⛳️推荐 前些天发现了一个巨牛的人工智能学习网站&#xff0c;通俗易懂&#xff0c;风趣幽默&#xff0c;忍不住分享一…

【区间、栈】算法例题

目录 六、区间 48. 汇总区间 ① 49. 合并区间 ② 50. 插入区间 ② 51. 用最少数量的箭引爆气球 ② 七、栈 52. 有效的括号 ① 53. 简化路径 ② 54. 最小栈 ② 55. 逆波兰表达式求值 ② √- 56. 基本计算器 ③ 六、区间 48. 汇总区间 ① 给定一个 无重复元素 的 …

LeetCode # 199. 二叉树的右视图

199. 二叉树的右视图 题目 给定一个二叉树的 根节点 root&#xff0c;想象自己站在它的右侧&#xff0c;按照从顶部到底部的顺序&#xff0c;返回从右侧所能看到的节点值。 示例 1: 输入: [1,2,3,null,5,null,4] 输出: [1,3,4] 示例 2: 输入: [1,null,3] 输出: [1,3] 示例 3…

大规模电商平台数据采集难点分析♫

▁▃▅▇主要包括以下几方面&#xff1a; API工具 ◆◆数据量巨大 任何系统&#xff0c;在不同的数据量面前&#xff0c;需要的技术难度都是完全不同的。 如果单纯是将数据采到&#xff0c;可能还比较好完成&#xff0c;但采集之后还需要处理&#xff0c;因为必须考虑数据的规…

如何根据业务需求选择合适的电子合同平台?

在数字化转型的浪潮中&#xff0c;电子合同已经成为企业运营中不可或缺的一部分。然而&#xff0c;面对市场上众多的电子合同平台&#xff0c;企业如何根据自身的业务需求做出合适的选择呢&#xff1f;本文将为您一一解答。 在电子合同的签署过程中&#xff0c;数字证书颁发机…

鸿蒙Harmony应用开发—ArkTS-全局UI方法(日历选择器弹窗)

点击日期弹出日历选择器弹窗&#xff0c;可选择弹窗内任意日期。 说明&#xff1a; 该组件从API Version 10开始支持。后续版本如有新增内容&#xff0c;则采用上角标单独标记该内容的起始版本。 本模块功能依赖UI的执行上下文&#xff0c;不可在UI上下文不明确的地方使用&…