來源?| 碼海

封圖 | CSDN 付費下載于視覺中國

前言

我們每天都在用 Google, 百度這些搜索引擎，那大家有沒想過搜索引擎是如何實現的呢，看似簡單的搜索其實技術細節非常復雜，說搜索引擎是 IT 皇冠上的明珠也不為過，今天我們來就來簡單過一下搜索引擎的原理，看看它是如何工作的，當然搜索引擎博大精深，一篇文章不可能完全介紹完，我們只會介紹它最重要的幾個步驟，不過萬變不離其宗，搜索引擎都離不開這些重要步驟，剩下的無非是在其上添磚加瓦，所以掌握這些「關鍵路徑」，能很好地達到觀一斑而窺全貎的目的。

本文將會從以下幾個部分來介紹搜索引擎，會深度剖析搜索引擎的工作原理及其中用到的一些經典數據結構和算法，相信大家看了肯定有收獲。

搜索引擎系統架構圖

搜索引擎工作原理詳細剖析

搜索引擎系統架構圖

搜索引擎整體架構圖如下圖所示，大致可以分為搜集，預處理，索引，查詢這四步，每一步的技術細節都很多，我們將在下文中詳細分析每一步的工作原理。

搜索引擎工作原理詳細剖析

一、搜集

爬蟲一開始是不知道該從哪里開始爬起的，所以我們可以給它一組優質種子網頁的鏈接，比如新浪主頁，騰訊主頁等，這些主頁比較知名，在 Alexa 排名上也非常靠前，拿到這些優質種子網頁后，就對這些網頁通過廣度優先遍歷不斷遍歷這些網頁，爬取網頁內容，提取出其中的鏈接，不斷將其將入到待爬取隊列，然后爬蟲不斷地從 url 的待爬取隊列里提取出 url 進行爬取，重復以上過程...

當然了，只用一個爬蟲是不夠的，可以啟動多個爬蟲并行爬取，這樣速度會快很多。

1、待爬取的 url 實現

待爬取 url 我們可以把它放到 Redis 里，保證了高性能，需要注意的是，Redis 要開啟持久化功能，這樣支持斷點續爬，如果 Redis 掛掉了，重啟之后由于有持續久功能，可以從上一個待爬的 url 開始重新爬。

2、如何判重

如何避免網頁的重復爬取呢，我們需要對 url 進行去重操作，去重怎么實現？可能有人說用散列表，將每個待抓取 url 存在散列表里，每次要加入待爬取 url 時都通過這個散列表來判斷一下是否爬取過了，這樣做確實沒有問題，但我們需要注意到的是這樣需要會出巨大的空間代價，有多大，我們簡單算一下，假設有 10 億 url （不要覺得 10 億很大，像 Google, 百度這樣的搜索引擎，它們要爬取的網頁量級比 10 億大得多），放在散列表里，需要多大存儲空間呢？

我們假設每個網頁 url 平均長度 64 字節，則 10 億個 url 大約需要 60 G 內存，如果用散列表實現的話，由于散列表為了避免過多的沖突，需要較小的裝載因子（假設哈希表要裝載 10 個元素，實際可能要分配 20 個元素的空間，以避免哈希沖突），同時不管是用鏈式存儲還是用紅黑樹來處理沖突，都要存儲指針，各種這些加起來所需內存可能會超過 100 G，再加上沖突時需要在鏈表中比較字符串，性能上也是一個損耗，當然 100 G 對大型搜索引擎來說不是什么大問題，但其實還有一種方案可以實現遠小于 100 G 的內存：布隆過濾器。

針對 10 億個 url，我們分配 100 億個 bit，大約 1.2 G, 相比 100 G 內存，提升了近百倍！可見技術方案的合理選擇能很好地達到降本增效的效果。

當然有人可能會提出疑問，布隆過濾器可能會存在誤判的情況，即某個值經過布隆過濾器判斷不存在，那這個值肯定不存在，但如果經布隆過濾器判斷存在，那這個值不一定存在,針對這種情況我們可以通過調整布隆過濾器的哈希函數或其底層的位圖大小來盡可能地降低誤判的概率，但如果誤判還是發生了呢，此時針對這種 url 就不爬好了，畢竟互聯網上這么多網頁，少爬幾個也無妨。

3、網頁的存儲文件: doc_raw.bin

爬完網頁，網頁該如何存儲呢，有人說一個網頁存一個文件不就行了，如果是這樣，10 億個網頁就要存 10 億個文件，一般的文件系統是不支持的，所以一般是把網頁內容存儲在一個文件（假設為 doc_raw.bin）中，如下

當然一般的文件系統對單個文件的大小也是有限制的，比如 1 G，那在文件超過 1 G 后再新建一個好了。

圖中網頁 id 是怎么生成的，顯然一個 url 對應一個網頁 id，所以我們可以增加一個發號器，每爬取完一個網頁，發號器給它分配一個 id，將網頁 id 與 url 存儲在一個文件里，假設命名為 doc_id.bin,如下

二、預處理

爬取完一個網頁后我們需要對其進行預處理，我們拿到的是網頁的 html 代碼，需要把 <script>,<style>,<option> 這些無用的標簽及標簽包含的內容給去掉，怎么查找是個學問，可能有人會說用 BF ，KMP 等算法，這些算法確實可以，不過這些算法屬于單模式串匹配算法，查詢單個字段串效率確實不錯，但我們想要一次性查出<script>,<style>,<option>這些字段串，有啥好的方法不，答案是用AC 自動機多模式串匹配算法，可以高效一次性找出幾個待查找的字段串，有多高效，時間復雜度接近 0(n)！關于 AC 自動機多模式匹配算法的原理不展開介紹，大家可以去網上搜搜看， 這里只是給大家介紹一下思路。

找到這些標簽的起始位置后，剩下的就簡單了，接下來對每個這些標簽都查找其截止標簽 </script>,</style>,</option>，找到之后，把起始終止標簽及其中的內容全部去掉即可。

做完以上步驟后，我們也要把其它的 html 標簽去掉（標簽里的內容保留），因為我們最終要處理的是純內容（內容里面包含用戶要搜索的關鍵詞）

三、分詞并創建倒排索引

拿到上述步驟處理過的內容后，我們需要將這些內容進行分詞，啥叫分詞呢，就是將一段文本切分成一個個的詞。比如 「I am a chinese」分詞后，就有 「I」,「am」,「a」,「chinese」這四個詞,從中也可以看到，英文分詞相對比較簡單，每個單詞基本是用空格隔開的，只要以空格為分隔符切割字符串基本可達到分詞效果，但是中文不一樣，詞與詞之類沒有空格等字符串分割，比較難以分割。以「我來到北京清華大學」為例，不同的模式產生的分詞結果不一樣，以 github 上有名的 jieba 分詞開源庫為例，它有如下幾種分詞模式

【全模式】:?我/?來到/?北京/?清華/?清華大學/?華大/?大學 【精確模式】:?我/?來到/?北京/?清華大學 【新詞識別】：他, 來到, 了, 網易, 杭研, 大廈 【搜索引擎模式】：?小明, 碩士, 畢業, 于, 中國, 科學, 學院, 科學院, 中國科學院, 計算, 計算所, 后, 在, 日本, 京都, 大學, 日本京都大學, 深造

分詞一般是根據現成的詞庫來進行匹配，比如詞庫中有「中國」這個詞，用處理過的網頁文本進行匹配即可。當然在分詞之前我們要把一些無意義的停止詞如「的」,「地」,「得」先給去掉。

經過分詞之后我們得到了每個分詞與其文本的關系，如下

細心的你一定發現了，不同的網頁內容有可能出現同樣的分詞，所以我們把具有相同分詞的網頁歸在一起，如下所示

這樣我們在搜「大學」的時候找到「大學」對應的行，就能找到所有包含有「大學」的文檔 id 了。

看到以上「分詞」+「倒排索引」的處理流程，大家想到了什么？沒錯，這不就是 ElasticSearch 搜索引擎干的事嗎，也是 ES 能達到毫秒級響應的關鍵！

這里還有一個問題，根據某個詞語獲取得了一組網頁的 id 之后，在結果展示上，哪些網頁應該排在最前面呢，為啥我們在 Google 上搜索一般在第一頁的前幾條就能找到我們想要的答案。這就涉及到搜索引擎涉及到的另一個重要的算法: PageRank，它是 Google 對網頁排名進行排名的一種算法，它以網頁之間的超鏈接個數和質量作為主要因素粗略地分析網頁重要性以便對其進行打分。我們一般在搜問題的時候，前面一兩個基本上都是 stackoverflow 網頁，說明 Google 認為這個網頁的權重很高，因為這個網頁被全世界幾乎所有的程序員使用著，也就是說有無數個網頁指向此網站的鏈接，根據 PageRank 算法，自然此網站權重就啦，恩，可以簡單地這么認為，實際上 PageRank 的計算需要用到大量的數學知識，畢竟此算法是 Google 的立身之本，大家如果有興趣，可以去網上多多了解一下。

完成以上步驟，搜索引擎對網頁的處理就完了，那么用戶輸入關鍵詞搜索引擎又是怎么給我們展示出結果的呢。

四、查詢

用戶輸入關鍵詞后，首先肯定是要經過分詞器的處理。比如我輸入「中國人民」，假設分詞器分將其分為「中國」,「人民」兩個詞，接下來就用這個兩詞去倒排索引里查相應的文檔。

得到網頁 id 后，我們分別去 doc_id.bin，doc_raw.bin 里提取出網頁的鏈接和內容，按權重從大到小排列即可。

這里的權重除了和上文說的 PageRank 算法有關外，還與另外一個「 TF-IDF 」（https://zh.wikipedia.org/wiki/Tf-idf）算法有關，大家可以去了解一下。

另外相信大家在搜索框輸入搜索詞的時候，都會注意到底下會出現一串搜索提示詞，

如圖示：輸入 chin 這四個字母后，底下會出現一列提示詞。

如何實現的，這就不得不提到一種樹形結構：Trie 樹。Trie 樹又叫字典樹、前綴樹（Prefix Tree）、單詞查找樹，是一種多叉樹結構，如下圖所示：

這顆多叉樹表示了關鍵字集合 ["to"，"tea"，"ted"，"ten"，"a"，"i"，"in", "inn"]。從中可以看出 Trie 樹具有以下性質：

根節點不包含字符，除根節點外的每一個子節點都包含一個字符

從根節點到某一個節點，路徑上經過的字符連接起來，為該節點對應的字符串

每個節點的所有子節點包含的字符互不相同

通常在實現的時候，會在節點結構中設置一個標志，用來標記該結點處是否構成一個單詞（關鍵字）。

另外我們不難發現一個規律，具有公共前綴的關鍵字（單詞），它們前綴部分在 Trie 樹中是相同的，這也是 Trie 樹被稱為前綴樹的原因，有了這個思路，我們不難設計出上文所述搜索時展示一串搜索提示詞的思路：

一般搜索引擎會維護一個詞庫，假設這個詞庫由所有搜索次數大于某個閾值（如 1000）的字符串組成，我們就可以用這個詞庫構建一顆 Trie 樹，這樣當用戶輸入字母的時候，就可以以這個字母作為前綴去 Trie 樹中查找，以上文中提到的 Trie 樹為例，則我們輸入「te」時，由于以「te」為前綴的單詞有 ["tea"，"ted"，"ted"，"ten"]，則在搜索引擎的搜索提示框中就可以展示這幾個字符串以供用戶選擇。

五、尋找熱門搜索字符串

Trie 樹除了作為前綴樹來實現搜索提示詞的功能外，還可以用來輔助尋找熱門搜索字符串，只要對 Trie 樹稍加改造即可。假設我們要尋找最熱門的 10 個搜索字符串，則具體實現思路如下:

一般搜索引擎都會有專門的日志來記錄用戶的搜索詞，我們用用戶的這些搜索詞來構建一顆 ?Trie 樹，但要稍微對 Trie 樹進行一下改造，上文提到，Trie 樹實現的時候，可以在節點中設置一個標志，用來標記該結點處是否構成一個單詞，也可以把這個標志改成以節點為終止字符的搜索字符串個數，每個搜索字符串在 Trie 樹遍歷，在遍歷的最后一個結點上把字符串個數加 1，即可統計出每個字符串被搜索了多少次（根節點到結點經過的路徑即為搜索字符串），然后我們再維護一個有 10 個節點的小頂堆（堆頂元素比所有其他元素值都小，如下圖示）

如圖示：小頂堆中堆頂元素比其他任何元素都小

依次遍歷 Trie 樹的節點，將節點（字符串+次數）傳給小頂堆，根據搜索次數不斷調整小頂堆，這樣遍歷完 Trie 樹的節點后，小頂堆里的 10 個節點即是最熱門的搜索字符串。

總結

本文簡述了搜索引擎的工作原理，相信大家看完后對其工作原理應該有了比較清醒的認識，我們可以看到，搜索引擎中用到了很多經典的數據結構和算法，所以現在大家應該能明白為啥 Google, 百度這些公司對候選人的算法要求這么高了。

本文只是介紹了搜索引擎的基本工作原理，要深入了解還需多查資料了解哦。

?

推薦閱讀

• 一文帶你認識keepalived，再帶你通關LVS+Keepalived！

• 那個分分鐘處理 10 億節點圖計算的 Plato，現在怎么樣了？
  

• “谷歌殺手”發明者，科學天才 Wolfram

• 數據庫激蕩 40 年，深入解析 PostgreSQL、NewSQL 演進歷程

• 超詳細！一文告訴你 SparkStreaming 如何整合 Kafka ！附代碼可實踐

• 5分鐘！就能學會以太坊 JSON API 基礎知識！

  真香，朕在看了！

總結

以上是生活随笔為你收集整理的看似简单的搜索引擎，原来背后的数据结构和算法这么复杂？的全部內容，希望文章能夠幫你解決所遇到的問題。

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