课程名称:海量数据高并发场景,构建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 和业务双写
两个集群,一个处理业务,一个重建索引,切换使用
课程收获: