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

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小时内修改过的数据在小时库中;

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

当有查询请求发生时，会同时查询各个级别的索引，将结果合并，得到最新的数据：

• 全量库是紧密存储的索引，无碎片，速度快;
• 天库是紧密存储，速度快;
• 小时库数据量小，速度也快;

分级索引能够保证实时性，那么，新的问题来了，小时库数据何时反映到天库中，天库中的数据何时反映到全量库中呢?

dump&merge，索引的导出与合并，由这两个异步的工具完成：

• dumper：将在线的数据导出。
• merger：将离线的数据合并到高一级别的索引中去。

小时库，一小时一次，合并到天库中去;

天库，一天一次，合并到全量库中去;

这样就保证了小时库和天库的数据量都不会特别大;

如果数据量和并发量更大，还能增加星期库，月库来缓冲。

简单小结一下：

超大数据量，超高并发量，实时搜索引擎的两个架构要点：

• 索引分级;
• dump&merge;

关于“搜索”与“检索”，GET到新技能了吗?

【本文为51CTO专栏作者“58沈剑”原创稿件，转载请联系原作者】

戳这里，看该作者更多好文

【编辑推荐】

1. 究竟啥才是互联网架构“高可用”
2. 下一代微服务！微博Service Mesh高可用架构实战
3. 有赞基于ES的搜索系统架构是如何演进的？
4. 新虚拟网络架构——Cable介绍
5. 马蜂窝搜索基于Golang并发代理的一次架构升级

（编辑：ASP站长网）