如何实现搜索引擎优化( 实现一个搜索接口，你会如何实现？(组图) )

　　如何实现搜索引擎优化(

实现一个搜索接口，你会如何实现？(组图)

)

　　点击上方“逆锋起笔”，公众号回复 编程资源领取大佬们推荐的学习资料作者：jasonGeng88编辑：陶家龙

出处：https://github.com/jasonGeng88/blog

　　

　　如果是做后端开发，肯定已经实现了列表查询接口。当然，有些查询条件很简单，一条SQL就可以搞定。

　　但是有些查询条件极其复杂，再加上库表中各种不合理的设计，使得查询界面特别难写，然后加班什么的就不用说了（不知道大家有没有这种感觉~）。

　　让我们从一个例子开始。这是购物网站的搜索条件。如果您要实现这样的搜索界面，您将如何实现它？

　　当然你说在搜索引擎的帮助下，比如Elasticsearch，你可以做到。但是这里我想说的是，如果你想自己实现呢？

　　

　　从上图可以看出，搜索分为6个类别，每个类别又分为子类别。

　　在中间，主要类别的条件是交叉点。每个子类都有单选、多选、自定义的情况，最终输出满足条件的结果集。

　　好了，既然需求明确了，我们就开始实施它们。

　　实现1

　　最先上台的是小A同学，他是写SQL的“高手”。小A自信地说：“不就是一个查询接口吗？条件很多，不过以我丰富的SQL经验，这对我来说还是不难的。”

　　于是我写了如下一段代码（这里以MySQL为例）：

　　select ... from table_1

left join table_2

left join table_3

left join (select ... from table_x where ...) tmp_1

...

where ...

order by ...

limit m,n

　　代码在测试环境中运行，结果似乎匹配，所以我准备预发布。通过这次预发布，问题开始暴露出来。

　　预发布是为了让在线环境尽可能的逼真，所以数据量自然要比测试大很多。那么对于如此复杂的SQL，其执行效率可想而知。考试的同学果断的把小A的密码打了回去。

　　实现2

　　总结小A失败的教训，小B开始优化SQL，先通过explain关键字进行SQL性能分析，在添加索引的地方添加索引。

　　同时将一个复杂的SQL拆分成多个SQL，计算结果在程序内存中进行计算。

　　伪代码如下：

　　$result_1 = query('select ... from table_1 where ...');

$result_2 = query('select ... from table_2 where ...');

$result_3 = query('select ... from table_3 where ...');

...

$result = array_intersect($result_1, $result_2, $result_3, ...);

　　这种方案在性能上明显比第一种方案好很多，但是在功能验收的时候，产品经理还是觉得查询速度不够快。

　　小B自己也知道，每次查询都会多次查询数据库，有一定的历史原因，有些条件不能单表查询，查询等待时间在所难免。

　　实施3

　　小C从上述方案中看到了优化的空间。他发现小B在思考上没有问题，将复杂的条件拆分，计算每个子维度的结果集，最后合并所有子结果集，得到最终想要的结果。

　　于是他忽然想，能不能把每个子维度的结果集提前缓存起来，这样在查询的时候，可以直接取到想要的子集，而不用每次都去数据库计算。

　　这里，小C使用Redis来存储缓存数据。使用它的主要原因是它提供了多种数据结构，并且很容易在Redis中进行集合交集操作。

　　具体方案如图：

　　

　　这里，对于每个条件，计算出的结果集ID预先存储在对应的Key中，选择的数据结构为Set。

　　查询操作包括：

　　这其实就是所谓的反向索引。在这里您会发现缺少价格条件。从需求可以看出，价格条件是一个区间，并且是无限的。

　　因此，上述条件穷举的Key-Value方法是无法实现的。这里我们使用Redis的另一种数据结构来实现，有序集（Sorted Set）：

　　

　　将所有产品加入到以Key为价格的有序集合中，值为产品ID，每个值对应的score就是产品价格的值。

　　这样，在Redis的有序集合中，就可以使用ZRANGEBYSCORE命令，根据score（价格）范围获取对应的结果集。

　　至此，方案3的优化已经全部结束，数据查询和计算通过缓存的方式分离。

　　在每次搜索中，您只需要搜索 Redis 几次即可获得结果。查询速度满足验收要求。微信搜索公众号开始写作，关注后回复编程资源，收到各种经典学习资料。

　　扩张

　　①寻呼

　　在这里你可能发现了一个严重的功能缺陷，列表查询怎么没有分页。是的，我们马上来看看Redis是如何实现分页的。

　　分页主要涉及排序。为简单起见，以创建时间为例。如图所示：

　　

　　图中蓝色部分是以创建时间为分数的有序商品集合。蓝色下方的结果集是条件计算的结果。通过ZINTERSTORE命令，结果集的权重为0，商品的时间结果为1，取交集得到的结果集被赋予一个新的有序的创建时间点集。

　　对新结果集的操作可以得到分页所需的所有数据：

　　②数据更新

　　有两种方法可以更新索引数据。一种是通过修改商品数据立即触发更新操作，另一种是通过定时脚本进行批量更新。

　　这里需要注意的是，关于索引内容的更新，如果Key被暴力删除，则需要重新重置Key。

　　因为Redis中的这两个操作不会以原子方式执行，所以它们之间可能存在差距。建议仅从集合中删除无效元素并添加新元素。

　　③性能优化

　　Redis 是内存级操作，所以单次查询会很快。但是如果我们的实现中有多个Redis操作，Redis的多次连接时间可能是不必要的时间消耗。

　　通过使用 MULTI 命令，打开一个事务，将 Redis 的多个操作放在一个事务中，最后通过 EXEC 原子地执行。

　　注意：这里所谓的事务只是在一个连接中执行多个操作。如果在执行过程中发生故障，则不会回滚。

　　总结

　　这里只是一个简单的使用Redis优化查询和搜索的demo。与现有的开源搜索引擎相比，重量更轻，学习成本相应更低。

　　其次，它的一些想法类似于开源搜索引擎。如果添加词分析，也可以实现类似的全文搜索功能。

　　一些搜索，有点黄~~~

　　这可能是未来第三大搜索引擎

　　2018公众号文章整理整理，查找资料更方便

　　教你如何在Gihub上精准搜索开源项目？

　　Redis创始人宣布退居二线，不再进行项目日常代码维护

　　<p style="text-align: center;" >

</p>

　　

支持下