一、 背景

搜索涉及权重的部分

1. multi-match的各个字段权重
2. 品牌降权的品牌列表和降分权重
3. 全球购商品降分权重
   
4. 个性化搜索各个特征加分权重
5. 给特定品牌下的特定分类降分权重（后续需要支持，并开发给运营配置）

搜索列表涉及的页面

1. 模糊搜索
2. 品牌页面
3. 品类页面
4. 新品到着
5. 店铺页面

目前现状

1. multi-match的字段是在service发布的时候写死的
2. 品牌降权的商品列表在zk里动态配置，其权重设置为-200000，使其在最后；
3. 全球购商品设置权重为-20000，使其在正常的商品后面，全球购的商品前面；

新的需求

1. 对于全球购商品，不想让他们在列表的很后面，只要稍微降点分，在四五页的打分；
2. 当搜索全球购的品牌时，希望能让对应的全球购商品显示在前面；
3. 能给特定品牌下的特定分类降分权重；

二、初步设计

表结构设计

dynamic_field

dynamic_rule

dynamic_rule_details

dynamic_rule_page_rel

方案描述

field

• 对于dynamic_field的字段由搜索组维护，不对外开放；
• 后续value_type可以支持扩展，如range类型的；
• 考虑兼容性，一般不会删除原有的field；

rule

• 一个Rule默认应用到所有搜索页面，也可以勾选应用到特定的页面；
• 对于SearchField字段的Rule，每个页面有且只有一个发布的Rule；
• 对于复合类型的Rule，其具体的组合规则需要配置在dynamic_rule_details表；
• Rule创建的状态是草稿状态，经过测试OK后点击发布按钮才会变成发布状态；
• boost的取值可以为整数或负数，不能为0；

producer的处理

• 增加监听dynamic_rule、dynamic_rule_details和dynamic_rule_page_rel表；
• 增加三个队列，将增量消息发布到MQ队列；

comsumer的处理

• 监听MQ队列，并处理表数据变更，更新到SearchDB；

service的处理

service如何获取动态权重配置? （待讨论）

• 方案1：service增加连接MySql的处理，自己读取表数据；
• 方案2：service调用consumer获取配置信息；
• 方案3：consumer发布权重信息到redis或zk，service监听获取；

动态权重配置如何生效？

增加一个动态权重配置的管理类，定期获取（如每5分钟获取一次）或监听到zk配置变化时，首先测试下配置是否ok（搞一个最简单的测试报文，如根据“vans 卫衣”进行count，如count大于100认为配置OK），如OK就更新缓存中的规则，否则的话还是之前上一次正确的规则（第一次时使用系统配置的默认值）并上报告警信息。

动态权重配置影响打分放在search请求里还是建索引的时候？

• 对于SearchField的权重，只能放在search请求里；
• 对于常规类型或组合类型的，建议还是放在search请求里的should里，这样权重和search的权重具有可比性，如果在建索引的时候或者function_score的时候，field的权重和SearchField的权重相关性不大；