場景
大家如果是做后端開發的，想必都實作過串列查詢的介面，當然有的查詢條件很簡單，一條 SQL 就搞定了，但有的查詢條件極其復雜，再加上庫表中設計的各種不合理，導致查詢介面特別難寫，然后加班什么的就不用說了（不知各位有沒有這種感受呢~），
下面以一個例子開始，這是某購物網站的搜索條件，如果讓你實作這樣的一個搜索介面，你會如何實作？（當然你說借助搜索引擎，像 Elasticsearch 之類的，你完全可以實作，但我這里想說的是，如果要你自己實作呢？）
從上圖中可以看出，搜索總共分為6大類，每大類中又分了各個子類，這中間，各大類條件之間是取的交集，各子類中有單選、多選、以及自定義的情況，最終輸出符合條件的結果集，
好了，既然需求很明確了，我們就開始來實作，關注公眾號Java技術堆疊回復面試，可以獲取整理的 Redis 系列面試題及全部答案，
實作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，計算結果在程式記憶體中進行計算，這篇Explain 最完整總結，推薦看下，
偽代碼如下：
$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, ...);
這種方案從性能上明顯比第一種要好很多，可是在功能驗收的時候，產品經理還是覺得查詢速度不夠快，MySQL 實作一個簡單版搜索引擎，這篇推薦看下，
小B自己也知道，每次查詢都會向資料庫查詢多次，而且有些歷史原因，部分條件是做不到單表查詢的，所以查詢等待的時間是避免不了的，
實作3
小C從上面的方案中看到了優化的空間，他發現小B在思路上是沒問題的，將復雜條件拆分，計算各個子維度的結果集，最后將所有的子結果集進行一個匯總合并，得到最終想要的結果，
于是他突發奇想，能否事先將各個子維度的結果集給快取起來，這要查詢的時候直接去取想要的子集，而不用每次去查庫計算，
這里小C采用 Redis 來存盤快取資料，用它的主要原因是，它提供了多種資料結構，并且在 Redis 中進行集合的交并集操作是一件很容易的事情，
具體方案，如圖所示：
這里每個條件都事先將計算好的結果集ID存入對應的key中，選用的資料結構是集合（Set），查詢操作包括：
子類單選：直接根據條件 key，獲取對應結果集；
子類多選：根據多個條件 Key，進行并集操作，獲取對應結果集；
最終結果：將獲取的所有子類結果集進行交集操作，得到最終結果；
這其實就是所謂的反向索引，
這里會發現，漏了一個價格的條件，從需求中可知，價格條件是個區間，并且是無窮舉的，所以上述的這種窮舉條件的 Key-Value 方式是做不到的，這里我們采用 Redis 的另一種資料結構進行實作，有序集合（Sorted Set）：
將所有商品加入 Key 為價格的有序集合中，值為商品ID，每個值對應的分數為商品價格的數值，這樣在 Redis 的有序集合中就可以通過ZRANGEBYSCORE命令，根據分數（價格）區間，獲取相應結果集，
至此，方案三的優化已全部結束，將資料的查詢與計算通過快取的手段，進行了分離，在每次查找時，只需要簡單的查找 Redis 幾次就能得出結果，查詢速度上符合了驗收的要求，
擴展
分頁
這里你或許發現了一個嚴重的功能缺陷，串列查詢怎么能沒有分頁，是的，我們馬上來看 Redis 是如何實作分頁的，關注公眾號Java技術堆疊回復面試，可以獲取整理的 Redis 系列面試題及全部答案，
分頁主要涉及排序，這里簡單起見，就以創建時間為例，
如圖所示：
圖中藍色部分是以創建時間為分值的商品有序集合，藍色下方的結果集即為條件計算而得的結果，通過ZINTERSTORE命令，賦結果集權重為0，商品時間結果為1，取交集而得的結果集賦予創建時間分值的新有序集合，對新結果集的操作即能得到分頁所需的各個資料：
頁面總數為：ZCOUNT命令
當前頁內容：ZRANGE命令
若以倒序排列：ZREVRANGE命令
資料更新
關于索引資料更新的問題，有兩種方式來進行，一種是通過商品資料的修改，來即時觸發更新操作，一種是通過定時腳本來進行批量更新，
這里要注意的是，關于索引內容的更新，如果暴力的洗掉 Key，再重新設定 Key，因為 Redis 中兩個操作不會是原子性進行的，所以中間可能存在空白間隙，建議采用僅移除集合中失效元素，添加新元素的方式進行，
性能優化
Redis 是記憶體級操作，所以單次的查詢會很快，但是如果我們的實作中會進行多次的 Redis 操作，Redis 的多次連接時間可能是不必要時間消耗，通過使用MULTI命令，開啟一個事務，將 Redis 的多次操作放在一個事務中，最后通過EXEC來進行原子性執行（注意：這里所謂的事務，只是將多個操作在一次連接中執行，如果執行程序中遇到失敗，是不會回滾的），
總結
這里只是一個采用 Redis 優化查詢搜索的一個簡單 Demo，和現有的開源搜索引擎相比，它更輕量，學習成本頁相應低些，其次，它的一些思想與開源搜索引擎是類似的，如果再加上詞語決議，也可以實作類似全文檢索的功能，
總結了一些2020年的面試題，這份面試題的包含的模塊分為19個模塊，分別是： Java 基礎、容器、多執行緒、反射、物件拷貝、Java Web 、例外、網路、設計模式、Spring/Spring MVC、Spring Boot/Spring Cloud、Hibernate、MyBatis、RabbitMQ、Kafka、Zookeeper、MySQL、Redis、JVM ，
獲取資料以上資料：關注公眾號：有故事的程式員，獲取學習資料，
記得點個關注+評論哦~
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/231806.html
標籤：其他