需求背景：在廣告位商品詳情頁，當搜索推薦返回物料不足時，觸發我們自己補足策略。補足邏輯根據商品詳情頁（infoid反查類別）當滿足配置key就會返回對應values的物料進行補足。
1.補足邏輯：
目前線上補足策略：adsearch->zzvisitrecommend 搜索推薦會根據infoid來返回推薦的物料，如果該類別物料不足或者不滿足條件那麼就不會返回物料。
所以這個廣告位的物料展示都是根據推薦服務的控制。目前我們需求就是爲了補足當推薦不返回時，觸發我們自己補足策略
新補足策略：詳情頁根據infoid反查類別，根據infoid肯定可以查到三級類/二級類/一級類。如果反查cateid在配置上做了映射，那麼我們會根據cateid調用zzsearch獲取補足物料。
ps:商業側補足策略要低於推薦服務的補足，即當推薦服務返回物料不足配置個數是纔會增加商業側配置映射類別物料。
測試點：
1.觸發商業側補足前提。
2.優先級低於推薦補足。
3.映射類目驗證投放城市(特別本地品類要根據查看者的定位展示)
4.配置映射類目要涉及不同類別的兄弟類。
bug點：
問題出現在商業側補足策略應該在推薦返回之後。bug現象是出現了商業補足和推薦返回一起進行了排序。
詳情頁推薦→推薦 返回商品list，我們準備按會根據adcate屬性，進行區別哪些infoid是master列表（主召回），哪些infoid是slave列表（推薦補足）。
bug出現在slave列表，我們區別哪些是推薦返回slave，哪些是我們根據cateid調用zzsearch獲取補足物料。
解決：
1.在召回實例增加一個prioroty屬性
2.詳情頁推薦廣告位1008我們把所有推薦返回list都放到主召回master列表中，但是呢滿足adcate屬性物料把prioroty=1，把不滿足adcate屬性物料把prioroty=0。
商業側通過映射類別召回放到slave中。這樣如果master列表物料個數大於等於9個，那麼slave就不會返回給上游服務。
複雜沒有看懂，就這樣吧，需要多看看。。。。關鍵點在similarRebuilder
總結一下：
這類商業側補足的需求：
1.場景：我個人喜歡放到沙箱上。根據PM想補足的類別（線上一定是不足的）我們進行相關case測試，我覺得更快一些。
2.adsearch調用推薦服務獲取是怎麼拆分哪些infoid放入master，哪些放入slave。商業自己補足放到slave中怎麼區別優先級。我覺得基本沒有啥問題了。