2017-03-01?58沈劍?架構師之路

一、緣起

《深入淺出搜索架構（上篇）》詳細介紹了前三章：

（1）全網搜索引擎架構與流程

（2）站內搜索引擎架構與流程

（3）搜索原理與核心數據結構

?

《深入淺出搜索架構（中篇）》介紹了：

（4）流量數據量由小到大，常見搜索方案與架構變遷

（5）數據量、并發量、擴展性架構方案

?

本篇將討論：

（6）百度為何能實時檢索出15分鐘之前新出的新聞？58同城為何能實時檢索出1秒鐘之前發布的帖子？搜索引擎的實時性架構，是本文將要討論的問題。

?

二、實時搜索引擎架構

大數據量、高并發量情況下的搜索引擎為了保證實時性，架構設計上的兩個要點：

（1）索引分級

（2）dump&merge

?

索引分級

《深入淺出搜索架構（上篇）》介紹了搜索引擎的底層原理，在數據量非常大的情況下，為了保證倒排索引的高效檢索效率，任何對數據的更新，并不會實時修改索引，一旦產生碎片，會大大降低檢索效率。

?

既然索引數據不能實時修改，如何保證最新的網頁能夠被索引到呢？

索引分為全量庫、日增量庫、小時增量庫。

?

如下圖所述：

（1）300億數據在全量索引庫中

（2）1000萬1天內修改過的數據在天庫中

（3）50萬1小時內修改過的數據在小時庫中

?

當有修改請求發生時，只會操作最低級別的索引，例如小時庫。

?

當有查詢請求發生時，會同時查詢各個級別的索引，將結果合并，得到最新的數據：

（1）全量庫是緊密存儲的索引，無碎片，速度快

（2）天庫是緊密存儲，速度快

（3）小時庫數據量小，速度也快

?

數據的寫入和讀取都是實時的，所以58同城能夠檢索到1秒鐘之前發布的帖子，即使全量庫有300億的數據。

?

新的問題來了：小時庫數據何時反映到天庫中，天庫中的數據何時反映到全量庫中呢？

?

dump&merge

這是由兩個異步的工具完成的：

dumper：將在線的數據導出

merger：將離線的數據合并到高一級別的索引中去

?

小時庫，一小時一次，合并到天庫中去；

天庫，一天一次，合并到全量庫中去；

這樣就保證了小時庫和天庫的數據量都不會特別大；

如果數據量和并發量更大，還能增加星期庫，月庫來緩沖。

?

三、總結

超大數據量，超高并發量，實時搜索引擎的兩個架構要點：

（1）索引分級

（2）dump&merge

?

如《深入淺出搜索架構（上篇）》中所述，全網搜索引擎分為Spider,?Search&Index,?Rank三個部分。本文描述的是Search&Index如何實時修改和檢索，Spider子系統如何能實時找到全網新生成的網頁，又是另外一個問題，未來撰文講述。

轉載于:https://www.cnblogs.com/davidwang456/p/7550108.html

總結

以上是生活随笔為你收集整理的百度如何能实时检索到15分钟前新生成的网页？--转的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。