合肥網站SEO公司

[seo優化]搜索引擎的架構設計和性能優化都有哪些?

瀏覽:/ 2019-04-08

aaa.jpg電商搜索引擎的特點

眾所周知,標準的搜索引擎主要分成三個大的部分,第一步是爬蟲系統,第二步是數據分析,第三步才是檢索結果。

首先,電商的搜索引擎并沒有爬蟲系統,因為所有的數據都是結構化的,一般都是微軟的數據庫或者 Oracle 的數據庫,所以不用像百度一樣用「爬蟲」去不斷去別的網站找內容,當然,電商其實也有自己的「爬蟲」系統,一般都是抓取友商的價格,再對自己進行調整。

第二點,就是電商搜索引擎的過濾功能其實比搜索功能要常用。甚至大于搜索本身。什么是過濾功能?一般我們網站買東西的時候,搜了一個關健詞,比如尿不濕,然后所有相關品牌或者其他分類的選擇就會呈現在我們面前。對百度而言,搜什么詞就是什么詞,如果是新聞的話,可能在時間上會有一個過濾的選項。

第三點,電商搜索引擎支持各種維度的排序,包括支持好評、銷量、評論、價格等屬性的排序。而且對數據的實時性的要求非常高。對一般的搜索引擎,只有非常重要的網站,比如一些重量級的門戶網站,百度的收錄是非??斓?,但是對那些流量很小的網站,可能一個月才會爬一次。電商搜索對數據的實時性要求主要體現在價格和庫存兩個方面。

電商搜索引擎另一個特點就是不能丟品,比如我們在淘寶、天貓開了個店鋪,然后好不容易搞了一次活動,但是卻搜不到了,這是無法忍受的。除此之外,電商搜索引擎與推薦系統和廣告系統是相互融合的,因為搜素引擎對流量的貢獻是最大的,所以大家都希望把廣告系統能跟其融合。當然,還有一點非常重要,就是要保證絕對的高可用,而且不能宕機。

電商搜索引擎的架構

因為電商搜索引跟一般的搜索引擎區別很大,所以在架構的設計上也獨具特色。

首先,搜索引擎的實現方式有很多種,有谷歌、百度、搜狗這種非常大的公司,也有京東、淘寶、當當這樣的電商搜索引擎,很多中小型的電商可能更喜歡用一個開源的搜索引擎。所以總的來說,主要包括以下這幾種方式:

第一種是「Lucene+自己封裝」,只用來做檢索,然后封裝,后面所有的 ES,這兩個是完整的解決方案,而且包括索引所有的東西,只需要部署好業務邏輯,然后查找結果就可以了。

第二種就是 Solr,這是一個高性能,采用 Java5 開發,基于 Lucene 的全文搜索服務器。同時對其進行了擴展,提供了比 Lucene 更為豐富的查詢語言,同時實現了可配置、可擴展并對查詢性能進行了優化,并且提供了一個完善的功能管理界面,是一款非常優秀的全文搜索引擎。

第三種是 ElasticSearch,這是一個基于 Lucene 的搜索服務器。它提供了一個分布式多用戶能力的全文搜索引擎,基于 RESTful web 接口。Elasticsearch 是用 Java 開發的,并作為 Apache 許可條款下的開放源碼發布,目前使用的也非常多。

這里提一下,當當的搜索引擎是自己實現的,?,F在,新興的互聯網公司大部分都是使用第一種或者第二種,數據量比較大的一般采用第三種。

電商搜索引擎標配模塊

 

接下來我想講一下,如果我們自己做一個搜索引擎的話需要實現哪些功能(上圖是電商搜索引擎的標準模塊),其實不止是電商搜索引擎,除了通搜的搜索引擎,其他的搜索引擎也是使用這樣的標配。

 

對檢索模塊而言,首先是對用戶的意圖進行分析,根據用戶的搜索詞來進行純算法的實現。比如用戶的搜索詞是「黑包包」,其實用戶的本意就是買一個黑色的包,但是這個「包」可以跟別的詞組合在一起,甚至在搜索結果中會出現「包子」。所以,這就需要 query 分析系統來做,告訴檢索系統,你需要主要在服裝鞋帽中的分類去找,而不是生鮮食品類。

設計到技術層面,當當網使用的是 C++。如果構建一個性能好的系統,一些老一點的公司,大家都是在使用 C++ 或者是 C 語言。不止是當當網,其實很多公司都是使用的 C 或者 C++ 實現的搜索引擎。

數據更新模塊

 

第二個模塊就是數據更新模塊,該模塊負責生成索引。而數據中心模塊主要做的事情,就是將原始的結構化數據,變成一個可供檢索系統使用的搜索數據庫。當然,數據更新模塊和檢索模塊是分開還是合并呢?其實從本質上講,都是一堆代碼,完全可以寫在一個進程里。當然,也可以分開,通過網絡往外輸入,各自都有道理。第一種是簡單粗暴型的,如果是普通電商,像生鮮電商,數據量不大,實時性、季節性很強,就可以把兩個系統用一個進程來完成。但是如果到了百萬、千萬甚至上億級別的話,就不可能部在一臺機器上了。

上圖就是當兩個系統合并在一起的時候,紅色部分就是檢索系統,黃色部分是上游產生數據的系統,如果是淘寶的話,對接就是淘寶的商戶,當當網對接是市場部的人員,他們將數據錄入系統,推到數據庫,然后向下進行傳送,最終建立一個索引。

上圖中的藍色部分就是業務邏輯,因為電商的搜索引擎業務需求量非常高,尤其是現在大家都喜歡用手機進行購物,像手機專享價就是一個新的業務,這也意味著需要一個專用的模塊來處理這些商用的邏輯。

此外,就是用戶行為的分析,我們搜集到的日志還有其他相關的數據都會存到 Hadoop 集群上去,通過離線計算,然后傳給商業模塊或者排序模塊進行排序和打分,并提供給用戶更好的使用體驗。

出問題是不可避免的!如何解決?

雖然整理來看,設計的思路是非常合理的,但是還是會出現問題。一般而言,一個成熟的電商搜索系統,它的問題都很集中,要這幾種情況:首先就是 Bug,當然這是所有系統都會遇到的問題;第二個就是并發,但是搜索系統是沒辦法進行分庫分表,所以能做的就是索引切分;最后一點就是監控,包括問題追蹤、日志系統和監控系統,那么為了解決這些問題,我們應該怎么做?

首先,針對 Bug 問題,只能靠自動化運維去解決(這里也推薦使用 OneAPM 工具);第二個就是高并發的問題,目前主要是靠緩存和橫向擴展。而緩存和橫向擴展怎么應用到系統中去,這個很關鍵。很多人也說可以換一種語言,比如講 Python 換成 C++,但實際情況下,換語言并不能解決并發的問題,好的數據結構的設計比換一種語言更能提高性能,所以一般解決高并發問題的也就是緩存和橫向擴展。

第三個就是使用用 FLUME 日志系統(Flume 是 Cloudera 提供的一個高可用的,高可靠的,分布式的海量日志采集、聚合和傳輸的系統,Flume 支持在日志系統中定制各類數據發送方,用于收集數據;同時,Flume 提供對數據進行簡單處理,并寫到各種數據接受方(可定制)的能力)。其實,Flume 會把集群上每一個節點的日志全都收集起來,這樣做起來有兩個好處,第一是現場出問題,可以先回滾出 Bug,然后進行查詢。第二個就是對日志進行搜集,然后做用戶行為分析,查看用戶點擊了多少次,從何處導入的流量等等,從而便于更好的進行排序。

然后講一下緩存的問題。一般搜索的緩存可能分為兩級緩存,據我觀察,像搜狗可能是使用頁面級緩存,而百度可能用的是索引級的緩存。比如在搜狗搜索一個詞,開始時可能需要 40 毫秒,然后再搜的話,就可能一下子降到 1 毫秒。這就是頁面級緩存。而百度可能第一次搜索用了 40 毫秒,第二次就是 25 毫秒,它并不是把頁面給緩存下來,而是將索引的倒排鏈緩存,級別其實是不一樣的。

電商搜索很多使用的是兩級緩存,對于特別熱門的詞匯,我們可以做頁面級緩存,而頁面級緩存的時間只有 15 秒到 20 秒。但是像價格這樣的東西不能緩存,需要前臺頁面去反拉價格。第二級就是索引級別的緩存,實際上也是自建的一個緩存系統。另外,排序也有緩存,因為排序的結果不太會有太大的變化。

上圖是當當的搜索架構,這里有一個集群是做數據分析的,上面備滿了數據。

首先,集群之間采用什么樣的通訊方式?我們主要使用 ZMQ(這是一個簡單好用的傳輸層,像框架一樣的一個 socket library,使得 Socket 編程更加簡單、簡潔和性能更高。是一個消息處理隊列庫,可在多個線程、內核和主機盒之間彈性伸縮)。原因其實只有一個,就是快,非???,比較適合數據量比較大的業務。

如何避免冷啟動?

最后就是冷啟動的問題,這個問題是很多電商網站都很頭疼的問題。尤其是隨著電商網站的商品數量達到一定量級的時候,比如已經上億了,像淘寶、天貓的話應該更多。如果重建了一次索引需要啟動,或者新上線了一個業務模塊,需要重啟系統,是很麻煩的。

當然,當集群大了以后有很多方法,比如分開啟動之類的,至于技術嘛,一般索引的加載都是使用 Lunix 標準的 MMAP(MMAP 將一個文件或者其它對象映射進內存。文件被映射到多個頁上,如果文件的大小不是所有頁的大小之和,最后一個頁不被使用的空間將會清零。MMAP 在用戶空間映射調用系統中作用很大),這樣啟動速度會很快,但是系統會有預熱時間,前面一些時間的查詢會比較慢

如果數據量不是特別大的話,而且現在內存也那么便宜,完全可以將數據一次性讀入內存,因為 mmap 的操作畢竟性能沒有直接內存來得快。

第三種的話,就是盡量減少做全量數據的頻率,避免整個系統的重啟,這需要定期做一下索引的優化,把沒用的索引干掉。

如果是新上了一個業務模塊需要重啟集群,這樣的事情最好不要發生,這就是架構有問題了,將業務模塊變成外部的模塊或者插件進行上線才是正確的,不然每上線一個模塊需要重啟集群,這誰都受不了。

閱讀"[seo優化]搜索引擎的架構設計和性能優化都有哪些?"的人還閱讀

上一篇:[網絡優化技巧]如何通過網絡優化來吸引流量?怎么優化?

下一篇:[百度蜘蛛]首頁要怎樣布局才會讓蜘蛛喜歡?如何討好蜘蛛?

鑫恒盈配资