產品提了個每秒 20W 次的檢索需求，架構如何演進？

作者：58沈劍 2025-09-23 07:08:40

以同城的帖子業務場景為例，帖子的標題，帖子的內容有很強的用戶檢索需求，在業務、流量、并發量逐步遞增的各個階段，應該如何實現檢索需求呢？

產品提了一個需求：

我想做一個內容檢索功能，不復雜，100億數據，每秒10萬查詢而已，兩個星期能上線嗎？

大部分工程師未必接觸過“搜索內核”，但互聯網業務，基本會涉及“檢索”功能。以同城的帖子業務場景為例，帖子的標題，帖子的內容有很強的用戶檢索需求，在業務、流量、并發量逐步遞增的各個階段，應該如何實現檢索需求呢？

創業階段，常常用這種方法來快速實現。

數據在數據庫中可能是這么存儲的：

t_tiezi(tid, title, content)

滿足標題、內容的檢索需求可以通過LIKE實現：

select tid from t_tiezi where content like ‘%天通苑%’

這種方式確實能夠快速滿足業務需求，存在的問題也顯而易見：

如何快速提高效率，支持分詞，并對原有系統架構影響盡可能小呢，第一時間想到的是建立全文索引：

alter table t_tiezi add fulltext(title,content)

使用match和against實現索引字段上的查詢需求。

全文索引能夠快速實現業務上分詞的需求，并且快速提升性能（分詞后倒排，至少不要全表掃描了），但也存在一些問題：

為了解決全文索引的局限性，當數據量增加到大幾百萬，千萬級別時，就要考慮外置索引了。外置索引的核心思路是：索引數據與原始數據分離，前者滿足搜索需求，后者滿足CURD需求，通過一定的機制（雙寫，通知，定期重建）來保證數據的一致性。

Solr，Lucene，ES都是常見的開源方案。其中，ES（ElasticSearch）是目前最為流行的。

Lucene雖好，潛在的不足是：

為了改善Lucene的各項不足，解決方案都是“封裝一個接口友好的服務，屏蔽底層復雜性”，于是有了ES：

目前，快狗打車使用ES作為核心的搜索服務，實現業務上的各類搜索需求，其中：

所以，ES完全能滿足10億數據量，5k吞吐量的常見搜索業務需求。

當數據量進一步增加，達到10億、100億數據量；并發量也進一步增加，達到每秒10萬吞吐量；業務個性也逐步增加的時候，就需要自研搜索引擎了，定制化實現搜索內核了。

到了定制化自研搜索引擎的階段，超大數據量、超高并發量為設計重點，為了達到“無限容量、無限并發”的需求，架構設計需要重點考慮“擴展性”，力爭做到：增加機器就能擴容（數據量+并發量）。

同城的自研搜索引擎E-search初步架構圖如下：

(1) 上層proxy（粉色）是接入集群，為對外門戶，接受搜索請求，其無狀態性能夠保證增加機器就能擴充proxy集群性能；

(2) 中層merger（淺藍色）是邏輯集群，主要用于實現搜索合并，以及打分排序，業務相關的rank就在這一層實現，其無狀態性也能夠保證增加機器就能擴充merger集群性能；

(3) 底層searcher（暗紅色大框）是檢索集群，服務和索引數據部署在同一臺機器上，服務啟動時可以加載索引數據到內存，請求訪問時從內存中load數據，訪問速度很快：

如此設計，真正做到增加機器就能承載更多的數據量，響應更高的并發量。

簡單小結一下：

為了滿足搜索業務的需求，隨著數據量和并發量的增長，搜索架構一般會經歷這么幾個階段：

你們公司，經歷到哪個階段了？

知其然，知其所以然。

思路比結論更重要。

責任編輯：趙寧寧來源：架構師之路