背景:这个需求主要就是开关的展示和召回源展示功能。费时间切换功能用到场景基本不会用到,原因是因为搜索策略需要参数有一些不同的,依赖参数不同,比如说sloId=1006附近推荐和slotid=1007首页品类推荐召回源如果切换就会参数缺失报错,无法找回广告。
测试点我觉得还是分成2部分。第一部分ssp增改写入数据库。另一部分就是zzadsearch读取数据库(其实缓存,2种机制更新:第一种5分钟自动更新;第二种通过spp修改后自立即更新缓存)。
1.ssp修改数据库:
其实这部分很简单其实展示和更新数据库,数据库:dbzz_adsearch.ad_slot。重点关注一下前端请求就可以了,这里面有一个小的优化点就是假如我在第二页编辑内容点击返回后,前端请求会带上页码数pageNum=1,这样就会跳转到第一页。其实ssp用的人很少,这样也不算什么bug,但是这个场景很特别因为广告位修改会直接影响收入,随意这种遇到还是建议优化一下。
2.adsearch读取
以前adsearch读取方式:adsearch→读取缓存,如果缓存找不到就会读取apollo配置作为兜底。
读取机制这样的话有两个小坑:
第一坑:你会发现其实通过ssp直接修改数据库不一定生效的,原因多个机器修改缓存(测试环境商业集群应该概率不大),还是建议把其他机器adsearch干掉,这样通过ssp保存后即修改了数据库也修改了缓存,这样测试adsearch广告召回就会使用最新的召回源。
第二坑:上线。因为数据库新增字段,所以考虑一下线上数据库新增的影响(这次没有)。另外还需要考虑从apollo修改成读取数据库,我这次做法上线分2步:第一步集群线和数据库先上。第二步在撤掉apollo配置。
3.adsearch策略的切换
召回源本质就是广告召回和搜索策略的切换。
目前线上广告位对应策略映射关系这种:
{
"10000": "commonSearch",
"10001": "commonSearch",
"10005": "homeSearch",
"10006": "nearbySearch",
"10007": "commonSearch",
"10008": "similarSearch"
}
后端支持策略一共7种,如图:
null表示只有布点还是没有广告返回。mock表示返回都是假数据。
测试点:策略切换
还是上面说的你要考虑广告位能不能切换对应策略,因为切换策略后需要zzadsearch需要上游服务传入对应参数,如果缺失广告是不能召回的,举例:附近人明显需要传入地理参数如果修改成类别搜索策略,肯定不能召回。
另外上图7个策略,分类列表和搜索列表其实对应都是搜索模型,其实2个相互切换都是一个东西。
日志查看:
具体测试根据关键字“getAdsV2”,查看如图位置,该广告位修改成那个策略,没有问题就会打印出命中那个策略。
这里面processor.search.CommonSearch对应zzadsearch如图内容: