ssp增加广告位开关和召回源

背景：这个需求主要就是开关的展示和召回源展示功能。费时间切换功能用到场景基本不会用到，原因是因为搜索策略需要参数有一些不同的，依赖参数不同，比如说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如图内容：