電商搜索系統存在以下特點：
數據量龐大。（上億級別）
高並發。（日均pv過億、數十億）
一條商品數據由商品基本信息、價格、庫存、促銷、評價等組成，這些數據存儲在各自業務系統當中。（多數據源導致構建索引比較麻煩）
召回率要求高。（哪個商家發現搜不到自家的商品肯定要抓狂，哪怕有一個搜不到。）
時效性要求高，價格變動、庫存變動、上下架等要求近實時。（更新時間過長雖然不會造成資損，但是會嚴重影響用戶體驗）
索引更新量龐大。（上千萬級別）
排序！排序！排序！如何把用戶最想要的排在前面，提升轉化率，是搜索的核心價值。
個性化排序。對用戶進行畫像，然后抽取特征項參與排序。你對風格、材質、價格、品牌等因素的偏好都會影響排序結果。（千人千面）
京東搜索系統架構圖如下：
關鍵點解讀：
1）搜索分片、副本集
副本集：隨着並發量越來越大，單機已不能勝任，可以考慮“橫向擴展”（副本集）做負載均衡，提升整個搜索平台的並發能力。
分片：隨着數據規模越來越大，單機的內存、計算資源吃緊，造成單次請求響應超時，可以考慮分片，將大索引切分成小索引，從而滿足單機的性能。
將分片、副本集綜合起來構建分布式搜索引擎，不管以后是搜索量增長還是數據量增長，都可以通過擴展來滿足。
2）索引過程（全量索引、增量索引）
全量索引數據准備：上文提到“搜索系統中一條商品數據由商品基礎信息、價格、庫存、促銷、評價等信息組成，這些數據都分布在不同的業務系統中”。為了便於索引處理，對多個系統的數據進行合並，生成商品寬表。然后在數據平台上對數據進行清洗，形成一份待全量索引數據。
全量索引：由於全量數據比較龐大，采用hadoop進行“並行”處理。其實全量索引重點就是分布式索引，簡單方式可以根據一個數據切分規則，把數據分解成n塊（n對應分片數），由不同的機器同時構建索引。如下圖：
增量索引：接受MQ消息，然后實時調用各個業務接口建立索引。
3）檢索
一個檢索請求過來，先到merger，由merger將檢索請求分發給各個searcher節點，searcher節點進行檢索並返回結果給merger，然后merger進行合並排序，最后返回。
那么這里涉及兩次排序，第一次是在searcher里面排序，第二次是在merger做合並排序。（排序后面具體再說）
4）排序
上文提到一次搜索過程存在兩次排序：search排序，merge排序。
searcher排序注重文本策略，這里主要包括文本域、價格、銷量、好評等“商品綜合分”排序。
merger排序根據多個結果集進行合並排序，主要包括：店鋪多樣性、品牌多樣性、戰略扶持品牌等業務規則。
各大電商公司的排序都不太一樣，也會有“排序白皮書”供賣家進行參考，作為站內排序優化的參考書。
排序是電商搜索引擎的核心！
5）個性化搜索
個性化之前的搜索對於同一個查詢，不同用戶看到的結果是完全相同的。這可能並不符合所有用戶的需求。在商品搜索中，這個問題尤為特出。因為商品搜索的用戶可能特別青睞某些品牌、價格、店鋪的商品，為了減少用戶的篩選成本，需要對搜索結果按照用戶進行個性化展示。
個性化的第一步是對用戶和商品分別建模，第二步是將模型服務化。有了這兩步之后，在用戶進行查詢時，merger同時調用用戶模型服務和在線檢索服務，用戶模型服務返回用戶維度特征，在線檢索服務返回商品信息，排序模塊運用這兩部分數據對結果進行重排序，最后給用戶返回個性化結果。
6）擴展搜索范圍（Query Processer）
整合搜索用戶在使用搜索時，其目的不僅僅是查找商品，還可能查詢服務、活動等信息。為了滿足這一類需求，首先在Query Processor中增加對應意圖的識別。第二步是將服務、活動等一系列垂直搜索整合並服務化。一旦QP識別出這類查詢意圖，就條用整合服務，將對應的結果返回給用戶。
7）其他
緩存設計（分級緩存）
Detail Server（補充展示字段）
以上內容整理自：
京東11.11 - 商品搜索系統架構設計