电商商品搜索：需求方案和实现原理（“搜索产品经理”的传送门）-轻识

阅读本文10分钟，约3.8K字。

本文借助案例，分析了电商搜索商品的实现原理。

产品就能理解搜索做到什么程度、要准备哪些工作，以及输出合格的PRD，并“指导”开发人员实现。

1、从一个bug说起

2、C端商城高并发搜索

3、商城搜索的一般机制

4、ES的引入，解决了什么痛点

5、总结和意义

从一次bug说起

操作过程：用导入方式，在后台修改了商品的展示分类（即：再C端商城显示的分类）。

预期：在商城中，选择分类，可以查看到对应绑定的商品。

bug：结果在C端商城中，该分类下无该商品。而检擦数据库发现，该商品是绑有这个分类的。

调查原因：用导入的方式修改前端分类的时候，系统没有把新分类同步到ES库中。（ES库可理解未提供商城查询服务的中间库，下文有详解。）

处理办法：将代码调整为，导入方式修改的前端分类，也要触发同步给ES。

结论：

（1）搜索引擎服务技术（ES）是神一般的存在，却也是新手开发容易出问题的所在。

（2）该bug背后，值得产品经理透视搜索实现方案：比如搜索的机制……

C端商城的高并发搜索

我们普通做个列表的模糊查询项，很简单。输入张三，就把张三丰和张三一起搜出来了。

产品经理写这种方案似乎不用想。

但是为什么商城搜索的时候，就如此谨慎呢？

1、商品资料同步到商城C端

上述bug，发生在商品资料同步到商城C端这条路上。

商品后台，是电商后台体系中，较为简单的板块。但除了一点，那就是商品资料对C端的同步（支撑C端商城查询）。

这种同步的场景来源，大致如下：

（1）上新品、开新门店，需要全量上架到商城；

（2）后台修改商品资料，同步更新到商城；

（3）C端商城大量用户查询商品数据；

（4）C端商城初始打开页面加载大量的商品资料；

（5）库存价格同步（也有放在WMS对接商城端的，本质无差别）

事实上，C端商品的展示，主要有两种情况：List（商品列表页）和Detail（商品详情页）。

List包含商品标题、首图、价格等，如上图；

Detail包含商品的厂家、品牌、保质期、说明书等也就是点开每一个商品后的详情页面。

生活服务类电商（O2O）更特殊一点，不同开站城市或店铺下的用户，看到的团购/旅游/酒店/抽奖/电影订座/外卖…等商品集合以及排序也不一样。

2、基本实现机制

而在实现上，通常将商品资料的同步分为两类实现机制：

一类是通过中间服务ES这种搜索引擎中间件，进行缓存和查询支持。
另一类是接口，拉取数据库的商品资料；

很明显，ES是解决商品list，实现快速响应高并发数据的。

对应的同步路线就是：操作触发——>数据库——>ES——>商城。

商品详情页面，可以采用数据库接口（因为一次请求一个商品扛得住，可以不需要ES）。

其数据路线就是：操作——数据库——商城。

上述的bug产生的原因，就是开发做了导入数据的功能，忘记这个数据是需要同步ES的。

商城搜索的一般机制

搜索的基本模型就是，以请参，命中商品资料的指定的字段（比如“商品名称”、“功能”、“品牌”、“厂家”），各字段可以加权重，最后以得分的形式，排序输出商品。

1、搜索引擎的运算

这里最麻烦的是，命中的逻辑机制，也就是搜索的运算。所以很多架构中独立出来一个搜索服务，专门为C端提供快速的运算。

比较成熟的方法很多我这里举两个例子：一个是分词匹配，一个是逐字匹配。

搜索的时候，输入关键词。一般采用的是分词搜索技术。ES自带这种技术插件。

原理就是：

先初始化：

第一步，配置（或使用自带的）分词表2。比如该表配置有分词“矿泉”、“水”、“矿泉水”。

第二步，以表1的商品（“矿泉水”为例），读取分词表2（该表有分词为“矿泉”、“水”、“矿泉水”），生成商品与词的关联关系：

矿泉水对应三个分词“矿泉”、“水”、“矿泉水”，放入表3中。

应用场景：

用户输入关键词“矿泉醋”，读取表2，提取用户信息的分词“矿泉”。

第二步，以用户的分词“矿泉”，查找表3，得到商品“矿泉水”。

总结：

我们发现这里最主要的是表2要维护好。供使用。

不同领域会有很大区别。比如医药，会有自己的分词习惯，比如“阿莫西林” 是一个完整的词。

注意：

需注意的是，分词库（表2）每次更新，都要重新进行初始化。重新生成表3（新的覆盖旧的）。

过滤词库：

包括做一些“剔除词库”，去除语气词助词等。比如xx药，则把“药”字去除，不参与。

还有不少关键字比较敏感，比如涉黄、涉赌等等，这些关键字我们通常都会屏蔽，不进行数据搜索。

要屏蔽对应的关键字，后台就需要维护一套非法词库，当用户输入的关键字在非法词库中就不再做搜索，以减轻服务器压力。

网上一般有现成的词库可以直接导入系统，不满足的后台再进行维护扩充。

其他辅助词库

比如错误词纠正、还可以做近义词库：比如“维生素”=V，以及大小写字母通用等。推荐词库等。

逐字匹配：

而逐字匹配比较机械，用户输入ABCD，我们的指定字段中含有“ABCD”的，都筛选出来。或者含有“AB”的也筛选出来。这里就可以做权重，按顺序输出。

这个方法最原始，往往与用户的真实意愿不符合。

2、搜索结果输出

当后台将内容搂出来之后，会按默认顺序分页输出。比如我查出来1000个，会按权重顺序输出每页50个，展示在前端。

需考虑的是：

（1）按SPU还是按SKU输出（商户自己可以选择）；

（2）若是O2O，是所有门店都展示还是取最近一个有商品的门店。

（3）排序是以门店优先，还是商品优先。

（4）用户指定排序规则的情况下，则将搂出来的数据重新按用户的顺序输出。

若你和作者一样非技术出身，那么了解一些技术原理，工作就容易很多了。推荐一本适合的产品书<后端产品经理宝典>！

ES的引入，解决了什么痛点？

那么使用ES，究竟能为商品同步到商城发挥哪些不可替代的作用呢？

1、大规模数据检索的困扰

我们知道，随着网站业务的不断发展，网站商品搜索筛选的粒度越来越细，维度也就越来越多。

(注意这里的"筛选"不仅是用户主动查询，还包括默认打开页面时候的前端请求）

常规的方式，在多维度的 count 和 select 查询、各种排序、不同筛选维度的组合筛选下，回造成数据库的索引命中率不高。

一旦没有命中索引，就造成整个数据库的压力增大响应变慢（MongoDB 的索引策略基本和 MySQL 的差不多）。

当系统数据量上了10亿、100亿条的时候，系统架构通常会从以下角度去考虑问题：

（1）用什么数据库好？(mysql、sybase、oracle、达梦、神通、mongodb、hbase…) ；

（2）如何解决单点故障；(lvs、F5、A10、Zookeep、MQ) ；

（3）如何保证数据安全性；(热备、冷备、异地多活) ；

（4）如何解决检索难题；(数据库代理中间件：mysql-proxy、Cobar、MaxScale等;) ；

（5）如何解决统计分析问题；(离线、近实时)

其结果，往往各有瓶颈。

那么假设，全部放在内存中呢？——速度问题是解决了，但成本问题上来了。

当我们的数据达到PB级别时，按照每个节点96G内存计算，在内存完全装满的数据情况下，我们需要的机器是：1PB=1024T=1048576G，节点数=1048576/96=10922个。

实际上，考虑到数据备份，节点数往往在2.5万台左右。成本巨大决定了其不现实！

为解决以上问题，就引出了ES（elaticsearch的简写）。

2、ES是专治大规模数据检索难题的

ES是一个开源的高扩展的分布式全文检索引擎，它可以近乎实时的存储、检索数据。

本身扩展性很好，可以扩展到上百台服务器，处理PB级别的数据。从而让全文搜索变得简单。这个过程如下图所示：

它的处理能力上，支持横向扩展，理论上无限制。

比如在双十一这样的高峰期，我们可以采用调配临时节点的方式，来分解压力，在不需要的时候我们可以停掉多余的节点来节省资源。

还有ES的高可用性，在集群节点出现一个节点或者多个节点出现故障时，主要数据完整，依然可以正常提供服务。

因此采用这种技术，用户一打开商城就看的到商品list，快速展示给用户。

轻松解决前端请求的压力。当双十一等爆单期，任由用户狂刷商城，高枕无忧。

05 总结和意义

1、总结

（1）从开篇的bug，我们引发出了商品从后台到前端的机制探索。

商品列表的展示和搜索，通常通过ES实现；商品详情字段，可以通过普通的接口请求数据库。

（2）ES简单理解为以类似缓存的方式，实现高速大量搜索请求的引擎。

数据传递方面，它相当于一个介于数据提供方和使用方之间的容器，需要先将数据提交给它。

因此牵扯同步ES、请求ES、清除ES等。这就容易导致开发遗漏。

（3）当遇到搜索压力大的时候，比如商城快速加载大量商品列表数据的时候，可以考虑类似ES的机制。在技术选型上还有与之相似的solr等。

2、意义

后端产品体系对技术方案的依赖，需要产品经理理解这种机制。

产品经理需协助沟通ES收录的字段范围，需要在PRD中说明。
在需求方案和刷数据等环节，避免与开发产生过大的脱节。

写在最后：

若你和作者一样非技术出身，那么了解一些技术之后，工作就容易很多了。

推荐产品书<后端产品经理宝典>。

👇扫ES技术培训资料👇

公众号jjyypm回复“ES”领取

ES技术培训ppt，回复“ES”领取

——往期推荐——

B端产品经理对接第三方API，可能有多坑！

4千字，总结产超时”品需求文档的形式、规范、自查

电商商品搜索：需求方案和实现原理（“搜索产品经理”的传送门）

其他辅助词库

比如错误词纠正、还可以做近义词库：比如“维生素”=V，以及大小写字母通用等。推荐词库等。