搜尋引擎(search engine)是指根據一定的策略、運用特定的計算機程式蒐集網際網路上的資訊，在對資訊進行組織和處理後，為使用者提供檢索服務的系統。資料其實就是一塊的磚頭，當用戶需要的時候我們搜尋過來搬我們的宗旨就是在最段的時間內，讓使用者找到他們最想要的東西。

電商系統為什麼需要搜尋引擎

電商系統的商品數量『龐大』，搜尋頁的pv高。某寶2013年有7億線上商品， List的pv 7億+相當與每秒有 8000個請求電商的搜尋引擎並沒有爬蟲系統，因為所有的資料都是結構化的，一般都是Mysql或者 Oracle 的資料庫，所以不用像百度一樣用「爬蟲」去不斷去別的網站找內容，當然，電商其實也有自己的『爬蟲』系統，一般都是抓取友商的價格，再對自己進行調整。電商搜尋引擎的過濾功能其實比搜尋功能要常用，甚至大於搜尋本身。什麼是過濾功能？一般我們網站買東西的時候，搜了一個關健詞，比如運動鞋，然後所有相關品牌或者其他分類的選擇就會呈現在我們面前。對百度而言，搜什麼詞就是什麼詞，如果是新聞的話，可能在時間上會有一個過濾的選項。電商搜尋引擎支援各種維度的排序，包括支援人氣、銷量、信用、價格、發貨地等屬性的排序，且對資料的實時性要求非常高。對一般的搜尋引擎，只有非常重要的網站，比如一些重量級的入口網站，百度的收錄是非常快的，但是對那些流量很小的網站，可能一個月才會爬一次。電商搜尋對資料的實時性要求主要體現在價格和庫存兩個方面。電商搜尋引擎的效果不僅要考慮買家（資訊消費方，結果多樣性），還得考慮賣家（資訊提供方，爆光率）。電商搜尋引擎另一個特點就是不能丟品，比如我們在淘寶、天貓開了個店鋪，然後好不容易搞了一次活動，但是卻搜不到了，這是無法忍受的。除此之外，電商搜尋引擎與推薦系統和廣告系統是相互融合的，因為搜素引擎對流量的貢獻是最大的，所以大家都希望把廣告系統能跟其融合。保證高可用，容災、異常保護、降級(降級：qps維度、在clustermap上來做，正常來說，我們有20列，如果系統負載高的話查詢只分部到10列，這樣就高了1倍的qps) 異常保護：latency 、在searcher上來做，如果系統負載較高的話，searcher上會直接丟棄一些耗時的query

綜上所述，電商系統中搜索引擎的必要性顯而易見。

02

架構設計

搜尋功能可通過簡單的關鍵字搜尋，後端給出一個非準確的搜尋結果集，使用者通過篩選條件再進一步過濾，從而得到使用者最終想要的結果集。

01

頁面佈局

頁面佈局解析

一般搜尋頁的組成由如上圖所示：

商品搜尋詞入口：使用者可以輸入關鍵字進行全文搜尋前臺類目樹（有些平臺是前臺後臺公用統一的類目）：類目分類搜尋引擎由三部分組成：商品屬性篩選、個性篩選、商品列表組成。廣告推薦：有商品、店鋪、文章推薦。

02

搜尋引擎系統架構圖

該系統真正接受使用者請求並響應的系統。為了使用者體驗的需要，首先增加Query Processor服務，負責查詢意圖分析提升搜尋的準確性。隨著訪問量的增長，接著增加快取模組，提升請求處理效能。接著隨著資料量（商品量）的增長，將CMS服務從檢索服務中獨立出去，成為Detail服務。資料量的進一步增長，對資料進行類似資料庫分庫分表的分片操作。這時候，線上檢索服務由多個分片的searcher列組成。自然而然，需要一個merger服務，將多個分片的結果進行合併。

系統架構

搜尋流程說明

客戶端請求通過Load Blance到Blender；Blender呼叫QP，QP呼叫運營平臺，其中運營平臺主要負責將日常運營資料服務化，QP負責分析query；Blender請求page Cache和data Cache同時請求Merger呼叫線上搜尋服務Merger呼叫UserInfoSystem獲取使用者標籤資訊；Merger將請求發給每列Searcher；每個searcher召回商品並返給Merger；Merger合併多列searcher的結果，確定需要輸出的商品，請求CMS封裝對應的商品資訊；CMS封裝商品資訊返給Merger；Merger將包裝好的商品返給blender；Blender將Merger返回的結果與其他垂直搜尋結果進行合併，最終返回給前端。

為了保證高召回率和低響應延時，搜尋服務流程的處理全部放在記憶體當中進行計算。多個searcher併發處理請求，同時單個searcher內部採用執行緒池技術，即所有執行緒之間共享倒排索引和商品屬性資訊，提高記憶體使用效率；每個查詢使用一個獨立執行緒序列執行，保證併發的多個查詢執行緒之間互不影響。此外通過合理的設定執行緒池的大小，保證系統的CPU資源得到充分利

多級快取策略

Page cache：由於搜尋符合網際網路的二八法則，20%熱門查詢頻度非常高，佔每天搜尋請求量80%。針對這一特點，搜尋第一級快取以查詢請求為key，將返回給使用者的頁面作為value。對於完全相同的請求，直接從快取返回結果。頁面快取策略上線伊始，快取命中率就接近了30%，基本解決了當時的效能問題。

Data Cache：隨著業務的發展，排序結果需要針對不同使用者實現個性化訂製，這就導致請求中會包含使用者的UserInfo。如果直接將userinfo放入快取作為key，會導致data Cache的key數量激增，不但需要超大的快取空間，同時快取的命中率也會極低，最終會導致線上個性化服務的體驗滿意度降低。為了解決這個問題，將userinfo加入key，但是value只儲存排序好的商品id，這樣需要的快取空間遠遠小於Data cache。當命中快取後，呼叫CMS直接進行結果包裝。為了進一步提高快取命中率，利用使用者搜尋的翻頁習慣，即離線統計出使用者的翻頁數最大值，然後在value中快取這些頁面涉及到所有的商品id，從實踐效果來看，使用者後續的翻頁請求大部分會命中cache。

03

索引系統

該系統是搜尋技術的核心，在進入這個系統之前，搜尋資訊仍然是以商品維度進行儲存的。索引系統負責生成一種以關鍵字維度進行儲存的資訊，一般稱之為倒排索引。系統對於全量和增量的處理是一致的，唯一的區別在於待處理資料量的差異。一般情況下，全量資料索引由於資料量龐大，採用hadoop進行；實時資料量小，採用單機進行索引生產。

01

倒排索引

倒排索引（英語：Inverted index），也常被稱為反向索引、置入檔案或反向檔案，是一種索引方法，被用來儲存在全文搜尋下某個單詞在一個文件或者一組文件中的儲存位置的對映，它是文件檢索系統中最常用的資料結構。

有兩種不同的反向索引形式：

一條記錄的水平反向索引（或者反向檔案索引）包含每個引用單詞的文件的列表。一個單詞的水平反向索引（或者完全反向索引）又包含每個單詞在一個文件中的位置。

後者的形式提供了更多的相容性（比如短語搜尋），但是需要更多的時間和空間來建立。

如何構建倒排索引

E.g. 被索引的文字：

T0 = "it is what it is"

T1 = "what is it"

T2 = "it is a banana"

得到的倒排索引：

"a": {2}

"banana": {2}

"is": {0, 1, 2}

"it": {0, 1, 2}

"what": {0, 1}

檢索的條件"what","is"和"it"將對應集合的交集。

正向索引開發出來用來儲存每個文件的單詞的列表。正向索引的查詢往往滿足每個文件有序頻繁的全文查詢和每個單詞在校驗文件中的驗證這樣的查詢。在正向索引中，文件佔據了中心的位置，每個文件指向了一個它所包含的索引項的序列。也就是說文件指向了它包含的那些單詞，而反向索引則是單詞指向了包含它的文件，很容易看到這個反向的關係。

簡單索引的檔案格式

Index file可以採用閉鏈hash的結構來儲存，這樣查詢效率會很高，但是空間利用率很低。也可以對Key做排序後順序儲存，查詢時使用二分查詢。查詢效率較低，但是不會浪費記憶體。Doclist file的儲存就很簡單了，整體來看就是一個int型的陣列，為了提高記憶體利用率，通常還會對Doclist進行壓縮。

問題1

假如有7億的寶貝，其中有1億寶貝標題中包含”正品”這個詞，那麼正品這個詞的倒排鏈長度就是1億

解決方案

索引壓縮：要求：在解壓速度快的基礎上，壓縮比儘量高索引截斷：要求：不影響使用者體驗的前提下，倒排鏈儘量短

02

正排索引

一種索引方法，被用來儲存在全文搜尋下某個文件id與其對應的部分欄位儲存位置的對映。正排表是以文件的ID為關鍵字，表中記錄文件中每個字的位置資訊，查詢時掃描表中每個文件中字的資訊直到找出所有包含查詢關鍵字的文件。

問題2

單臺機器記憶體資源有限，如何容納更多的文件？高併發下如何快速響應請求？

解決方案

分散式的行、列概念

多行用於做負載均衡、冗餘備份。如果我們一行能承擔1000的QPS，那麼10行就能承擔1000*10的QPS，多列用於提高索引量。如果我們一臺機器受限於記憶體只能放1000w的寶貝，那麼1億的寶貝就需要10臺機器，也就是10列

在分散式叢集裡，通常會有多行多列。當然如果資料量足夠小，可以只有一列，但是考慮到容災備份，就算流量非常低也會有至少2行

方案一：個性化搜尋

方案二：主搜尋

ksearch與isearch的區別：ksearch是按key來分佈資料，而isearch雖然也支援按key查詢，但是主要功能是分散式。

檢索過程

問題3

為什麼做OR查詢會比較影響效能？

OR操作分配的記憶體空間不可預估，而且會很大合併的時候要遍歷所有的倒排鏈倒排鏈越長意味著最後排序的資料就越多

03

過濾統計排序

問題4

在分散式的叢集中，假設我們要取銷量排序第三頁的寶貝，即s=80&n=40。要如何獲取？

需要考慮的問題：

我們的寶貝分佈在不同的機器上，排序效率要高，也許某臺機器上銷量最差的寶貝也比其它機器上銷量最好的寶貝要好

解決方案

每臺searcher機器返回top120條結果Merger再將所有機器返回的top120寶貝混到一起，再heapsort取出top 120

04

rank

常見問題：

在人氣，或者銷量排序的時候馬太效應怎麼解決？

馬太效應：寶貝銷量越高排名越靠前，越靠前銷量越好

首先：寶貝銷量越高，確實搜尋的排名會靠前，但是排名越靠前，只能說明搜尋引導的成交會高一些，但是不會在大程度上影響寶貝的銷量，因為搜尋本身帶來的成交才20-30%

常用排序規則

阿基米德排序：相關性(標題類目 億級) + 下架時間(ends 千萬級) + 寶貝人氣(百萬級) + 賣家品質分(十萬)

人氣排序：標題 （1）+ 類目（1）+寶貝人氣（1）+ 賣家（0.2）

肯定不是使用者想要的

單維度排序

按照：銷量，信用，價格，總價，單價排序

單維度排序下不會做打散，可以認為這是使用者的意願只想找價格低的

類目混排

類目混排會對寶貝按類目進行分檔，檔內才按價格排序

打散：賣家打散，款式打散

05

Anti-spam

降權與遮蔽

常見的作弊型別

1、虛假交易

為了提升使用者體驗，保證搜尋的公平性，作弊是賣家通過一些不正當的行為，提高自己的搜尋排名

虛假交易，包括炒作信用和炒作銷量。以增加“會員積累信用”為目的或通過炒作商品銷量提高商品人氣而釋出的商品，會被判定為虛假交易商品。

通過釋出完全相同的商品來爭取更多的展現機會，直接降低了搜尋的精準度，降低了消費者的購物體驗，也是搜尋控制的重點。

商品描述不詳、無實際商品、僅提供釋出者聯絡方式以及非商品資訊的商品，判定為釋出廣告商品。

換寶貝：指賣家為了累積銷量或人氣，修改原有的商品的標題、價格、圖片、詳情等變成另外一種商品繼續出售。

Sku作弊：濫用商品屬性（如：套餐），將常規商品和瑕疵品、單機、樣機、模型、二手等非常規商品放在一個寶貝里出售，且一口價為非常規商品的價格。

04

電商系統搜尋和門戶搜尋的不同

（註解：網站的PR值（全稱為PageRank），是google搜尋排名演算法中的一個組成部分，級別從1到10級，10級為滿分，PR值越高說明該網頁在搜尋排名中的地位越重要）

總結

商業電商搜尋演算法另外兩個重要技術，一個是類目體系建立和應用，另一個是個性化技術。類目體系目前主要使用機器學習的方法進行訓練，個性化主要通過使用者畫像進行Query改寫來實現。搜尋演算法是一個非常值得一個電商產品持續投入的技術，一方面如果技術人員要有良好的技術背景，可以借鑑很多成熟的技術，避免重複造輪子；另一方面，每個產品的搜尋都有自身的特點，需要深入研究產品的特性給出合理的解決方案。