大佬用 Redis 實現一個輕量級的搜索引擎，牛x啊 !

場景

你們若是是作後端開發的，想必都實現過列表查詢的接口，固然有的查詢條件很簡單，一條 SQL 就搞定了，但有的查詢條件極其複雜，再加上庫表中設計的各類不合理，致使查詢接口特別難寫，而後加班什麼的就不用說了（不知各位有沒有這種感覺呢~）。

下面以一個例子開始，這是某購物網站的搜索條件，若是讓你實現這樣的一個搜索接口，你會如何實現？（固然你說藉助搜索引擎，像 Elasticsearch 之類的，你徹底能夠實現。但我這裏想說的是，若是要你本身實現呢？）

從上圖中能夠看出，搜索總共分爲6大類，每大類中又分了各個子類。這中間，各大類條件之間是取的交集，各子類中有單選、多選、以及自定義的狀況，最終輸出符合條件的結果集。

好了，既然需求很明確了，咱們就開始來實現。

實現1

率先登場是小A同窗，他是寫 SQL 方面的「專家」。小A信心滿滿的說：「不就是一個查詢接口嗎？看着條件不少，但憑着我豐富的 SQL 經驗，這點仍是難不倒個人。」

因而乎就寫出了下面這段代碼（這裏以 MYSQL 爲例）：

select ... from table_1
left join table_2
left join table_3
left join (select ... from table_x where ...) tmp_1
...
where ...
order by ...
limit m,n

代碼在測試環境跑了一把，結果好像都匹配上了，因而準備上預發。這一上預發，問題就開始暴露出來。預發爲了儘量的逼真線上環境，因此數據量天然而然要比測試大的多。因此這麼一個複雜的 SQL，它的執行效率可想而知。測試同窗果斷把小A的代碼給打了回來。

實現2

總結了小A失敗的教訓，小B開始對SQL進行了優化，先是經過了explain關鍵字進行SQL性能分析，對該加索引的地方都加上了索引。同時將一條複雜SQL拆分紅了多條SQL，計算結果在程序內存中進行計算。

僞代碼以下：

$result_1 = query('select ... from table_1 where ...');
$result_2 = query('select ... from table_2 where ...');
$result_3 = query('select ... from table_3 where ...');
...

$result = array_intersect($result_1, $result_2, $result_3, ...);

這種方案從性能上明顯比第一種要好不少，但是在功能驗收的時候，產品經理仍是以爲查詢速度不夠快。小B本身也知道，每次查詢都會向數據庫查詢屢次，並且有些歷史緣由，部分條件是作不到單表查詢的，因此查詢等待的時間是避免不了的。

實現3

小C從上面的方案中看到了優化的空間。他發現小B在思路上是沒問題的，將複雜條件拆分，計算各個子維度的結果集，最後將全部的子結果集進行一個彙總合併，獲得最終想要的結果。

因而他突發奇想，可否事先將各個子維度的結果集給緩存起來，這要查詢的時候直接去取想要的子集，而不用每次去查庫計算。

這裏小C採用 Redis 來存儲緩存數據，用它的主要緣由是，它提供了多種數據結構，而且在 Redis 中進行集合的交併集操做是一件很容易的事情。

具體方案，如圖所示：

這裏每一個條件都事先將計算好的結果集ID存入對應的key中，選用的數據結構是集合（Set）。查詢操做包括：

• 子類單選：直接根據條件 key，獲取對應結果集；
• 子類多選：根據多個條件 Key，進行並集操做，獲取對應結果集；
• 最終結果：將獲取的全部子類結果集進行交集操做，獲得最終結果；

這其實就是所謂的反向索引。

這裏會發現，漏了一個價格的條件。從需求中可知，價格條件是個區間，而且是無窮舉的。因此上述的這種窮舉條件的 Key-Value 方式是作不到的。這裏咱們採用 Redis 的另外一種數據結構進行實現，有序集合（Sorted Set）：

將全部商品加入 Key 爲價格的有序集合中，值爲商品ID，每一個值對應的分數爲商品價格的數值。這樣在 Redis 的有序集合中就能夠經過ZRANGEBYSCORE命令，根據分數（價格）區間，獲取相應結果集。

至此，方案三的優化已所有結束，將數據的查詢與計算經過緩存的手段，進行了分離。在每次查找時，只須要簡單的查找 Redis 幾回就能得出結果。查詢速度上符合了驗收的要求。

擴展

分頁

這裏你或許發現了一個嚴重的功能缺陷，列表查詢怎麼能沒有分頁。是的，咱們立刻來看 Redis 是如何實現分頁的。

分頁主要涉及排序，這裏簡單起見，就以建立時間爲例。

如圖所示：

圖中藍色部分是以建立時間爲分值的商品有序集合，藍色下方的結果集即爲條件計算而得的結果，經過ZINTERSTORE命令，賦結果集權重爲0，商品時間結果爲1，取交集而得的結果集賦予建立時間分值的新有序集合。對新結果集的操做即能獲得分頁所需的各個數據：

• 頁面總數爲：ZCOUNT命令
• 當前頁內容：ZRANGE命令
• 若以倒序排列：ZREVRANGE命令

數據更新

關於索引數據更新的問題，有兩種方式來進行。一種是經過商品數據的修改，來即時觸發更新操做，一種是經過定時腳原本進行批量更新。

這裏要注意的是，關於索引內容的更新，若是暴力的刪除 Key，再從新設置 Key。由於 Redis 中兩個操做不會是原子性進行的，因此中間可能存在空白間隙，建議採用僅移除集合中失效元素，添加新元素的方式進行。

性能優化

Redis 是內存級操做，因此單次的查詢會很快。可是若是咱們的實現中會進行屢次的 Redis 操做，Redis 的屢次鏈接時間多是沒必要要時間消耗。經過使用MULTI命令，開啓一個事務，將 Redis 的屢次操做放在一個事務中，最後經過EXEC來進行原子性執行（注意：這裏所謂的事務，只是將多個操做在一次鏈接中執行，若是執行過程當中遇到失敗，是不會回滾的）。

總結

這裏只是一個採用 Redis 優化查詢搜索的一個簡單 Demo，和現有的開源搜索引擎相比，它更輕量，學習成本頁相應低些。其次，它的一些思想與開源搜索引擎是相似的，若是再加上詞語解析，也能夠實現相似全文檢索的功能。

來源：https://github.com/jasonGeng8...