“搜索”的原理，架构，实现，实践，面试不用再怕了（值得收藏）！！！

58同城的自研搜索引擎E-search初步架构图如下：

(1) 上层proxy(粉色)是接入集群，为对外门户，接受搜索请求，其无状态性能够保证增加机器就能扩充proxy集群性能;

(2) 中层merger(浅蓝色)是逻辑集群，主要用于实现搜索合并，以及打分排序，业务相关的rank就在这一层实现，其无状态性也能够保证增加机器就能扩充merger集群性能;

(3) 底层searcher(暗红色大框)是检索集群，服务和索引数据部署在同一台机器上，服务启动时可以加载索引数据到内存，请求访问时从内存中load数据，访问速度很快：

• 为了满足数据容量的扩展性，索引数据进行了水平切分，增加切分份数，就能够无限扩展性能，如上图searcher分为了4组
• 为了满足一份数据的性能扩展性，同一份数据进行了冗余，理论上做到增加机器就无限扩展性能，如上图每组searcher又冗余了2份

如此设计，真正做到做到增加机器就能承载更多的数据量，响应更高的并发量。

简单小结一下：

为了满足搜索业务的需求，随着数据量和并发量的增长，搜索架构一般会经历这么几个阶段：

• 原始阶段-LIKE;
• 初级阶段-全文索引;
• 中级阶段-开源外置索引;
• 高级阶段-自研搜索引擎;

最后一个高级话题，关于搜索的实时性：百度为何能实时检索出15分钟之前新出的新闻?58同城为何能实时检索出1秒钟之前发布的帖子?

实时搜索引擎系统架构的要点是什么?

大数据量、高并发量情况下的搜索引擎为了保证实时性，架构设计上的两个要点：

• 索引分级;
• dump&merge;

首先，在数据量非常大的情况下，为了保证倒排索引的高效检索效率，任何对数据的更新，并不会实时修改索引。

画外音：因为，一旦产生碎片，会大大降低检索效率。

既然索引数据不能实时修改，如何保证最新的网页能够被索引到呢?

索引分级，分为全量库、日增量库、小时增量库。

如上图所述：

• 300亿数据在全量索引库中;
• 1000万1天内修改过的数据在天库中;
• 50万1小时内修改过的数据在小时库中;

当有修改请求发生时，只会操作最低级别的索引，例如小时库。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!