课程名称：海量数据高并发场景，构建Go+ES8企业级搜索微服务
课程章节：7-3，7-4
课程讲师：少林码僧
课程内容：
商品搜索业务场景
搜索基本上会带来一半以上的流量和转化
搜索是用户的主动行为，更容易产生交易
搜索在电商系统中占有相当重要的地位
商品搜索的功能分析
数据来源 ： 主要来源于企业内部的商品库，但也有可能是类似推广网站，不是自己的商品
数据规模：和商品类目有关，有的是品牌自有商城，普遍不过千。而平台类的都是在万级~千万级别
召回率：要求高，其实就是准确性要求高
个性化: 要求高
评估目标：点击率和转化率，转化率还要考虑退货，这都是电商运营相关，不属于技术问题
商品搜索服务难点
大型电商系统来源复杂，需要大量的表来存储数据
对用户画像要求高
上下架数据及时
数据膨胀带来的性能问题
ES重建mapping的时候消耗非常大
数据同步方案
go-mysql-elasticsearch 这个插件的问题在于，目前只能对ES6及以下版本生效，而ES版本更新很快
Canal+Zookeeper+kafka 该方案是伪装成mysql的slave，让mysql的binlog发送到Canal，然后Canal再向es，kafka等发送数据，这个方案在于部署有点麻烦，运维不一定有能力支持
数据入库成功后直接写入到kafka
商品搜索的特殊性
在某些情况下，用户并不能准确通过关键词来表达自己的意图，比如xxx神器，这样的词，搜索引擎要能知道用户实际想搜的商品
展示用户更感兴趣的商品，有助于成交
用户输入的关键字无法与倒排索引匹配，导致无结果
商品的排序结果一般根据用户画像会有一些差异化
召回率和个性化排序的问题
预处理，意图识别，召回，粗排，精排以及规则引擎干预
ES主要用于召回阶段
选择合适的分词器，配合使用不同的分析器，根据query做意图识别
如何避免下架商品被搜索到
ES是近实时的搜索引擎，会先写到缓存，一秒一次刷入
显示指定文档数据是否需要立马执行refresh
索引重建问题
定期进行索引重建是需要考虑的问题
reindex api 和业务双写
两个集群，一个处理业务，一个重建索引，切换使用
课程收获：