吳英昊：電商搜索引擎的架構設計和性能優化發表于2015-10-2921:46|次閱讀|來源CSDN|0條評論|作者吳英昊架構性能優化故障恢復摘要：電商搜索引擎和普通的搜索引擎有很大差別 因為電商搜索引擎主要是解決用戶要“買什麼”SEO網站內容優化-奇寶網路 而不是用戶“搜什麼”。比如搜索“百年孤獨” 電商的搜索肯定是給你推薦這本書的商家 而不是《百年孤獨》是一本書。在OneAPM技術公開課第一期中 前當當網高級架構師吳英昊對電商搜索引擎的架構進行了深入分享。在演講中 他首先就電商搜索引擎的特點進行了解析 隨后更分享了電商搜索引擎的架構、數據更新、故障恢復等多個方面的內容。以下為演講整理首先 我想說的是電商搜索引擎和普通的搜索引擎有很大的差別 因為電商搜索引擎主要是解決用戶要“買什麼” 而通用搜索引擎主要是解決用戶“搜什麼”。比如同樣搜索一個詞“百年孤獨” 電商的搜索肯定是給你推薦這本書的商家 而百度主要是告訴你：《百年孤獨》是一本書。電商搜索引擎的特點眾所周知 標準的搜索引擎主要分成三個大的部分 第一步是爬蟲系統 第二步是數據分析 第三步才是檢索結果。首先 電商的搜索引擎并沒有爬蟲系統 因為所有的數據都是結構化的 一般都是微軟的數據庫或者Oracle的數據庫 所以不用像百度一樣用“爬蟲”去不斷去別的網站找內容 當然 電商其實也有自己的“爬蟲”系統 一般都是抓取友商的價格 再對自己進行調整。第二點 就是電商搜索引擎的過濾功能其實比搜索功能要常用。甚至大于搜索本身。什麼是過濾功能？一般我們網站買東西的時候 搜了一個關健詞 比如尿不濕 然后所有相關品牌或者其他分類的選擇就會呈現在我們面前。對百度而言 搜什麼詞就是什麼詞 如果是新聞的話 可能在時間上會有一個過濾的選項。第三點。 電商搜索引擎支持各種維度的排序 包括支持好評、銷量、評論、價格等屬性的排序。而且對數據的實時性的要求非常高。對一般的搜索引擎 只有非常重要的網站 比如一些重量級的門戶網站 百度的收錄是非常快的 但是對那些流量很小的網站 可能一個月才會爬一次。電商搜索對數據的實時性要求主要體現在價格和庫存兩個方面。電商搜索引擎另一個特點就是不能丟品 比如我們在淘寶、天貓開了個店鋪 然后好不容易搞了一次活動 但是卻搜不到了 這是無法忍受的。除此之外 電商搜索引擎與推薦系統和廣告系統是相互融合的 因為搜素引擎對流量的貢獻是最大的 所以大家都希望把廣告系統能跟其融合。當然 還有一點非常重要 就是要保證絕對的高可用 而且不能宕機。電商搜索引擎的架構因為電商搜索引跟一般的搜索引擎區別很大 所以在架構的設計上也獨具特色。首先 搜索引擎的實現方式有很多種 有谷歌、百度、搜狗這種非常大的公司 也有京東、淘寶、當當這樣的電商搜索引擎 很多中小型的電商可能更喜歡用一個開源的搜索引擎。所以總的來說 主要包括以下這幾種方式：第一種是“Lucene+自己封裝” 只用來做檢索 然后封裝。 后面所有的ES 這兩個是完整的解決方案 而且包括索引所有的東西 只需要部署好業務邏輯 然后查找結果就可以了。第二種就是Solr 這是一個高性能 采用Java5開發 基于Lucene的全文搜索服務器。同時對其進行了擴展 提供了比Lucene更為豐富的查詢語言 同時實現了可配置、可擴展并對查詢性能進行了優化 并且提供了一個完善的功能管理界面 是一款非常優秀的全文搜索引擎。第三種是ElasticSearch 這是一個基于Lucene的搜索服務器。它提供了一個分布式多用戶能力的全文搜索引擎 基于RESTfulweb接口。Elasticsearch是用Java開發的 并作為Apache許可條款下的開放源碼發布 目前使用的也非常多。這里提一下 當當的搜索引擎是自己實現的 。現在 新興的互聯網公司大部分都是使用第一種或者第二種 數據量比較大的一般采用第三種。電商搜索引擎標配模塊接下來我想講一下 如果我們自己做一個搜索引擎的話需要實現哪些功能（上圖是電商搜索引擎的標準模塊） 其實不止是電商搜索引擎 除了通搜的搜索引擎 其他的搜索引擎也是使用這樣的標配。對檢索模塊而言 首先是對用戶的意圖進行分析 根據用戶的搜索詞來進行純算法的實現。比如用戶的搜索詞是“黑包包” 其實用戶的本意就是買一個黑色的包 但是這個“包”可以跟別的詞組合在一起 甚至在搜索結果中會出現“包子”。所以 這就需要query分析系統來做。 告訴檢索系統 你需要主要在服裝鞋帽中的分類去找 而不是生鮮食品類。設計到技術層面 當當網使用的是C++。如果構建一個性能好的系統 一些老一點的公司 大家都是在使用C++或者是C語言。不止是當當網 其實很多公司都是使用的C或者C++實現的搜索引擎。數據更新模塊第二個模塊就是數據更新模塊 該模塊負責生成索引。而數據中心模塊主要做的事情 就是將原始的結構化數據 變成一個可供檢索系統使用的搜索數據庫。當然 數據更新模塊和檢索模塊是分開還是合并呢？其實從本質上講 都是一堆代碼 完全可以寫在一個進程里。當然 也可以分開 通過網絡往外輸入 各自都有道理。第一種是簡單粗暴型的 如果是普通電商 像生鮮電商 數據量不大 實時性、季節性很強 就可以把兩個系統用一個進程來完成。但是如果到了百萬、千萬甚至上億級別的話 就不可能部在一臺機器上了。上圖就是當兩個系統合并在一起的時候 紅色部分就是檢索系統 黃色部分是上游產生數據的系統 如果是淘寶的話 對接就是淘寶的商戶 當當網對接是市場部的人員 他們將數據錄入系統 推到數據庫 然后向下進行傳送 最終建立一個索引。上圖中的藍色部分就是業務邏輯 因為電商的搜索引擎業務需求量非常高 尤其是現在大家都喜歡用手機進行購物 像手機專享價就是一個新的業務 這也意味著需要一個專用的模塊來處理這些商用的邏輯。此外 就是用戶行為的分析 我們搜集到的日志還有其他相關的數據都會存到Hadoop集群上去 通過離線計算 然后傳給商業模塊或者排序模塊進行排序和打分 并提供給用戶更好的使用體驗。出問題是不可避免的！如何解決？雖然整理來看 設計的思路是非常合理的 但是還是會出現問題。一般而言 一個成熟的電商搜索系統 它的問題都很集中 要這幾種情況：首先就是Bug 當然這是所有系統都會遇到的問題；第二個就是并發 但是搜索系統是沒辦法進行分庫分表 所以能做的就是索引切分；最后一點就是監控 包括問題追蹤、日志系統和監控系統 那么為了解決這些問題 我們應該怎么做？首先 針對Bug問題 只能靠自動化運維去解決（這里也推薦使用OneAPM工具）；第二個就是高并發的問題 目前主要是靠緩存和橫向擴展。而緩存和橫向擴展怎么應用到系統中去 這個很關鍵。很多人也說可以換一種語言 比如講Python換成C++ 但實際情況下 換語言并不能解決并發的問題 好的數據結構的設計比換一種語言更能提高性能 所以一般解決高并發問題的也就是緩存和橫向擴展。第三個就是使用用FLUME日志系統（Flume是Cloudera提供的一個高可用的 高可靠的 分布式的海量日志采集、聚合和傳輸的系統電商SEO優化-奇寶網路 Flume支持在日志系統中定制各類數據發送方 用于收集數據；同時SEO網站內容優化-奇寶網路 Flume提供對數據進行簡單處理 并寫到各種數據接受方（可定制）的能力）。其實 Flume會把集群上每一個節點的日志全都收集起來 這樣做起來有兩個好處 第一是現場出問題 可以先回滾出Bug 然后進行查詢。第二個就是對日志進行搜集 然后做用戶行為分析 查看用戶點擊了多少次 從何處導入的流量等等 從而便于更好的進行排序。然后講一下緩存的問題。一般搜索的緩存可能分為兩級緩存 據我觀察 像搜狗可能是使用頁面級緩存 而百度可能用的是索引級的緩存。比如在搜狗搜索一個詞 開始時可能需要40毫秒 然后再搜的話 就可能一下子降到1毫秒。這就是頁面級緩存。而百度可能第一次搜索用了40毫秒 第二次就是25毫秒 它并不是把頁面給緩存下來 而是將索引的倒排鏈緩存 級別其實是不一樣的。電商搜索很多使用的是兩級緩存 對于特別熱門的詞匯 我們可以做頁面級緩存 而頁面級緩存的時間只有15秒到20秒。但是像價格這樣的東西不能緩存 需要前臺頁面去反拉價格。第二級就是索引級別的緩存 實際上也是自建的一個緩存系統。另外 排序也有緩存 因為排序的結果不太會有太大的變化。上圖是當當的搜索架構 這里有一個集群是做數據分析的 上面備滿了數據。首先 集群之間采用什麼樣的通訊方式？我們主要使用ZMQ（這是一個簡單好用的傳輸層 像框架一樣的一個socketlibrary 使得Socket編程更加簡單、簡潔和性能更高。是一個消息處理隊列庫 可在多個線程、內核和主機盒之間彈性伸縮）。原因其實只有一個 就是快 非常快 比較適合數據量比較大的業務。如何避免冷啟動？最后就是冷啟動的問題 這個問題是很多電商網站都很頭疼的問題。尤其是隨著電商網站的商品數量達到一定量級的時候 比如已經上億了 像淘寶、天貓的話應該更多。如果重建了一次索引需要啟動 或者新上線了一個業務模塊 需要重啟系統 是很麻煩的。當然 當集群大了以后有很多方法 比如分開啟動之類的 至于技術嘛 一般索引的加載都是使用Lunix標準的MMAP（MMAP將一個文件或者其它對象映射進內存。文件被映射到多個頁上 如果文件的大小不是所有頁的大小之和 最后一個頁不被使用的空間將會清零。MMAP在用戶空間映射調用系統中作用很大） 這樣啟動速度會很快 但是系統會有預熱時間 前面一些時間的查詢會比較慢如果數據量不是特別大的話 而且現在內存也那么便宜 完全可以將數據一次性讀入內存 因為mmap的操作畢竟性能沒有直接內存來得快。第三種的話 就是盡量減少做全量數據的頻率 避免整個系統的重啟 這需要定期做一下索引的優化 把沒用的索引干掉。如果是新上了一個業務模塊需要重啟集群 這樣的事情最好不要發生 這就是架構有問題了 將業務模塊變成外部的模塊或者插件進行上線才是正確的 不然每上線一個模塊需要重啟集群 這誰都受不了。（整理/OneAPM技術編輯王鵬責編/仲浩） |
最新消息
