就是這么迅猛的實現搜索需求
一、緣起
《深入淺出搜索架構(上篇)》詳細介紹了：
(1)全網搜索引擎架構與流程
(2)站內搜索引擎架構與流程
(3)搜索原理與核心數據結構
本文重點介紹：
(4)流量數據量由小到大，常見搜索方案與架構變遷
(5)數據量、并發量、擴展性方案
只要業務有檢索需求，本文一定對你有幫助。
二、檢索需求的滿足與架構演進
任何互聯網需求，或多或少有檢索需求，還是以58同城的帖子業務場景為例，帖子的標題，帖子的內容有很強的用戶檢索需求，在業務、流量、并發量逐步遞增的各個階段，應該如何實現檢索需求呢?
1. 原始階段-LIKE
數據在數據庫中可能是這么存儲的：
- t_tiezi(tid, title, content)
- 滿足標題、內容的檢索需求可以通過LIKE實現：
- select tid from t_tiezi where content like ‘%天通苑%’
能夠快速滿足業務需求，存在的問題也顯而易見：
(1)效率低，每次需要全表掃描，計算量大，并發高時cpu容易100%
(2)不支持分詞
2. 初級階段-全文索引
如何快速提高效率，支持分詞，并對原有系統架構影響盡可能小呢，第一時間想到的是建立全文索引：
alter table t_tiezi add fulltext(title,content)
使用match和against實現索引字段上的查詢需求。
全文索引能夠快速實現業務上分詞的需求，并且快速提升性能(分詞后倒排，至少不要全表掃描了)，但也存在一些問題：
(1)只適用于MyISAM
(2)由于全文索引利用的是數據庫特性，搜索需求和普通CURD需求耦合在數據庫中：檢索需求并發大時，可能影響CURD的請求;CURD并發大時，檢索會非常的慢;
(3)數據量達到百萬級別，性能還是會顯著降低，查詢返回時間很長，業務難以接受
(4)比較難水平擴展
3. 中級階段-開源外置索引
為了解決全文索的局限性，當數據量增加到大幾百萬，千萬級別時，就要考慮外置索引了。外置索引的核心思路是：索引數據與原始數據分離，前者滿足搜索需求，后者滿足CURD需求，通過一定的機制(雙寫，通知，定期重建)來保證數據的一致性。
原始數據可以繼續使用Mysql來存儲，外置索引如何實施?Solr，Lucene，ES都是常見的開源方案。
樓主強烈推薦ES(ElasticSearch)，原因是Lucene雖好，但始終有一些不足：
(1)Lucene只是一個庫，潛臺詞是，需要自己做服務，自己實現高可用/可擴展/負載均衡等復雜特性
(2)Lucene只支持Java，如果要支持其他語言，還是得自己做服務
(3)Lucene不友好，這是很致命的，非常復雜，使用者往往需要深入了解搜索的知識來理解它的工作原理，為了屏蔽其復雜性，一個辦法是自己做服務
為了改善Lucene的各項不足，解決方案都是“封裝一個接口友好的服務，屏蔽底層復雜性”，于是有了ES：
(1)ES是一個以Lucene為內核來實現搜索功能，提供REStful接口的服務
(2)ES能夠支持很大數據量的信息存儲，支持很高并發的搜索請求
(3)ES支持集群，向使用者屏蔽高可用/可擴展/負載均衡等復雜特性
目前58到家使用ES作為核心，實現了自己的搜索服務平臺，能夠通過在平臺上簡單的配置，實現業務方的搜索需求。
搜索服務數據量最大的“接口耗時數據收集”需求，數據量大概在7億左右;并發量最大的“經緯度，地理位置搜索”需求，線上平均并發量大概在600左右，壓測數據并發量在6000左右。
結論：ES完全能滿足10億數據量，5k吞吐量的常見搜索業務需求，強烈推薦。
4. 高級階段-自研搜索引擎
當數據量進一步增加，達到10億、100億數據量;并發量也進一步增加，達到每秒10萬吞吐;業務個性也逐步增加的時候，就需要自研搜索引擎了，定制化實現搜索內核了。
三、數據量、并發量、擴展性方案
到了定制化自研搜索引擎的階段，超大數據量、超高并發量為設計重點，為了達到“無限容量、無限并發”的需求，架構設計需要重點考慮“擴展性”，力爭做到：增加機器就能擴容(數據量+并發量)。
58同城的自研搜索引擎E-search初步架構圖如下：
(1)上層proxy(粉色)是接入集群，為對外門戶，接受搜索請求，其無狀態性能夠保證增加機器就能擴充proxy集群性能
(2)中層merger(淺藍色)是邏輯集群，主要用于實現搜索合并，以及打分排序，業務相關的rank就在這一層實現，其無狀態性也能夠保證增加機器就能擴充merger集群性能
(3)底層searcher(暗紅色大框)是檢索集群，服務和索引數據部署在同一臺機器上，服務啟動時可以加載索引數據到內存，請求訪問時從內存中load數據，訪問速度很快
- 為了滿足數據容量的擴展性，索引數據進行了水平切分，增加切分份數，就能夠無限擴展性能，如上圖searcher分為了4組
- 為了滿足一份數據的性能擴展性，同一份數據進行了冗余，理論上做到增加機器就無限擴展性能，如上圖每組searcher又冗余了2份
如此設計，真正做到做到增加機器就能承載更多的數據量，響應更高的并發量。
三、總結
為了滿足搜索業務的需求，隨著數據量和并發量的增長，搜索架構一般會經歷這么幾個階段：
(1)原始階段-LIKE
(2)初級階段-全文索引
(3)中級階段-開源外置索引
(4)高級階段-自研搜索引擎
【本文為51CTO專欄作者“58沈劍”原創稿件，轉載請聯系原作者】
