Elasticsearch（ES）是一款基于Lucene的開源分布式搜尋引擎。由于其穩定、可靠、快速、安裝使用友善等優良特性，目前在業界已廣泛使用。ES用途主要分兩個方向：分布式實時檔案存儲 以及 分布式實時分析搜尋引擎。
一、為什麼需要查詢代理
屏蔽複雜的DSL
某二手交易平台使用ES，主要用來支援商品、使用者等(以下統稱文檔)的搜尋和分析。
ES為查詢功能提供了基于Json的完整Query DSL，功能非常強大，但同時也略顯複雜，學習成本不低。
以搜尋昵稱為化仁的使用者為例，DSL大緻如下：
json {"from" : 0, "size" : 20, "query" : {"bool" : { "must" : { "multi_match" : {"query" : "化仁", "fields": [ "nickname", "nickname.pinyin" ], "type" :"best_fields", "operator" : "OR","minimum_should_match" : "1", "tie_breaker" : 1.0} }, "filter" : { "term" : { "del" : 0 } } } } }
如果讓每個業務方根據需要編寫DSL實作相應功能，工作量及維護複雜程度可想而知！
避免依賴限制擴散
· ES要求用戶端和服務端JDK版本盡量保持一緻
· ES2.x要求JDK7以上
· ES5.x要求JDK8以上
· 大量Jar包依賴
· 其它可能出現的限制
使用查詢代理之後，各業務方無需引入上述依賴和限制
松耦合及管控
屏蔽底層引擎變動對線上業務的影響，例如底層引擎偶爾需要更新或重新開機，此時，隻需查詢代理層實作主從切換等機制，引擎的更新可做到對線上業務完全透明。
此外，查詢代理還可以屏蔽業務方錯誤的危險操作，防止叢集直接暴露給各業務方，進而降低不确定因素對系統的影響。
二、查詢代理層實作
業界做法
業界有将SQL作為代理層語言，實作一套SQL轉DSL的解析器，這種方式針對将ES作為DB使用的情況非常合适。但是，前面提到過，某二手交易平台的使用場景是文檔的搜尋，其中涉及到文檔的複雜排序，SQL無法完整實作目标需求，而且文檔屬性非常多的情況下，容易産生語句過于複雜的問題。
方案
種種因果，我們最終的實作方案如下：
請求文法
· 語句分為query域和param域，query域為篩選召回條件，param域為排序參數；
· 域為屬性字段的組合；
· 域使用URL參數文法表述；
還以搜尋昵稱為化仁的使用者為例，請求如下：
query:from=1&size=10&nickname=化仁 param: null 請求會自動轉換成前面提到的DSL例子。可以看到，相比之下還是非常簡單的。
實作邏輯
補充說明：
· 根據解析方式，字段大緻分為：内置字段 (起始位置、擷取數量、排序政策等) 和 配置字段 (字元串、數值、日期、經緯度等，會解析成對應ES支援的索引字段類型)
· 配置字段根據使用場景分為：比對篩選型、排序參數型、字段排序型、排序打分型、二次打分型等
· 各種類型的配置字段配有配置解析器和請求處理器
· 處理過程中會做諸如字段預設值、非法字段過濾等處理
· 處理過程生成query的梗概資訊作為外部緩存的key值，減輕ES叢集壓力
· 請求經過校驗、解析、處理後拼裝成ES的DSL，請求發送到系統配置設定ES叢集
配置樣例：
yml entry.user:index: user type: user query_fields: - { face: id, type: Number, class: Long }- { face: nickname, type: StringMultiMatch, fieldName:"nickname,nickname.pinyin", _tie_breaker: 1 } order_strategys:default: boostMode: multiply scores: - type: NumberTermsFilter fieldName: label_idclass: Long values: "1141730738345" weight: 2
三、總結
本文從ES查詢接口的必要性出發，主要講述了某二手交易平台ES查詢接口的文法設計和實作邏輯及簡要說明。其中有不合理之處，歡迎指正交流。
奈學開發者社群_專業IT技能學習平台ask.naixuejiaoyu.com
http://api.naixuejiaoyu.com/scan?channelcode=wx&key=java&putcode=3-zh (二維碼自動識别)