:根據需求拆解搜索接口的設計邏輯)
目錄一、搜索功能整體實現思路1. 為什么不用MySQL全程基于ES做搜索2. 整體核心邏輯傳參 → 處理 → 出參1.1 傳參構造ES查詢條件1.2 處理執行ES搜索1.3 出參封裝返回前端的完整數據二、核心代碼流程總覽核心復盤小結前言搜索功能的編寫比較復雜首先搜索條件繁多有關鍵字、價格、品牌、規格等。其次返回的結果除了搜索到的商品還要返回搜索面板包含關鍵字對應的品牌、品類、規格等還要將搜索條件回顯回去供前端操作。本篇先對大體實現思路進行回顧然后再細復盤每一處的實現。我們要實現的樣式可以參考京東的面板。一、搜索功能整體實現思路1. 為什么不用MySQL全程基于ES做搜索MySQL正排索引查詞要翻所有文檔只適合簡單 CRUD。面對商品關鍵字分詞、模糊檢索、多條件篩選、數據聚合場景性能極差、無法實現分詞匹配。而 Elasticsearch 基于倒排索引設計它會先拆詞再記這個詞在哪些文檔里專門適用于解決全文檢索場景。因此項目將商品搜索單獨抽離基于ES實現。2. 整體核心邏輯傳參 → 處理 → 出參1.1 傳參構造ES查詢條件關于傳參就看一個接收后是否需要處理。前端傳入GoodsSearchParamJSON參數和MySQL的Goods實體一樣是面向業務存儲設計的只保存商品主表字段而ES是面向搜索場景需要品牌、分類、規格等多表的冗余字段。我們需要把前端可讀的業務參數轉換成ES可識別的檢索語法適配ES的查詢規則。所以首先我們要把前端傳過來的數據構造成ES搜索條件。1.2 處理執行ES搜索我們的處理就是實現商品的搜索。ES實現商品搜索通過注入ElasticsearchTemplate調用search方法傳入構造好的ES查詢條件指定映射實體GoodsES即可完成ES數據查詢。1.3 出參封裝返回前端的完整數據這是整個接口的核心也是區別于普通查詢的關鍵。ES原始查詢結果不能直接返回前端需要二次封裝對應兩個核心需求1、分頁商品數據將ES查詢的原始數據封裝為Page分頁對象提供商品列表、總條數、頁碼等用于前端渲染商品列表2、搜索聚合面板數據遍歷所有搜索結果聚合去重品牌、品類、規格數據生成篩選面板同時回顯用戶的搜索參數保證前端搜索條件不丟失。二、核心代碼流程總覽// 搜索產品 Override public GoodsSearchResult search(GoodsSearchParam goodsSearchParam) { // 1.構造ES搜索條件 // 2.搜索 // 3.將查詢結果封裝為Page對象 // 4.封裝結果對象 // 4.1 查詢結果 // 4.2 查詢參數 // 4.3 查詢面板 return null; }核心復盤小結1、1、2步是內部查詢過程只負責和ES交互無對外返回數據2、3、4步是最終出參核心所有給前端展示的列表、分頁、篩選框、參數回顯全部來自這兩步也是搜索功能的業務核心。