對於後端開發人員來講使用一條SQl就可以實現列表查詢的接口，如果查詢條件很複雜，表庫設計不合理，會導致查詢很困難，這篇文章和大家分享一下用Redis實現搜索接口。
下面以一個例子開始，這是某購物網站的搜尋條件，如果讓你實現這樣的一個搜尋接口，你會如何實現?
當然你說借助搜尋引擎，像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，和現有的開源搜尋引擎相比，它更輕量，學習成本頁相應低些。
其次，它的某些想法與開源搜尋引擎是類似的，如果再加上詞語解析，也可以實現類似全文檢索的功能。
以上是怎麼用Redis實作搜尋接口的詳細內容。更多資訊請關注PHP中文網其他相關文章！
