技術文檔丨查詢接口的內部執行邏輯

趙立賀

悠易互通丨技術專家

技術產品中心

數據組

閱讀完上篇《查詢接口的演進過程》之后，我們一起來探索下《查詢接口的內部執行邏輯》吧：

 上一篇《技術文檔丨查詢接口的演進過程》中我們講到了經過一層層的重構，我們對接前端的接口變為了一個。那么今天我們一起來討論下通過一個接口獲取不同粒度的數據的內部處理邏輯是怎樣流轉的。

在介紹一個接口獲取不同粒度數據之前，大家先想想，開發一個被經常訪問的數據列表接口，我們通常會怎么處理呢？是不是會考慮數據存儲在什么數據庫里面，使用到了哪幾張表，列表的字段和數據表的字段的對應關系是怎樣的，字段是否需要經過特殊的轉化以及是否需要將結果集緩存等過程。

對于一個普通的列表接口都需要考慮這么多的內容，那么一個接口能夠處理不同粒度的數據是不是要復雜的多??？答案是不一定，因為我們僅需要將上述涉及的各個考慮過程進行抽象，形成各自的處理模塊，然后對不同的處理模塊進行流程指定及處理模塊的具體化即可，也就是使用代碼實現上述的考慮過程?；谶@樣的抽象設計思路，目前已經將查詢接口抽象出校驗層、緩存層、路由層、處理層、SQL構造層和元數據等處理模塊。通過這幾個處理模塊的齊心協力，最終實現一個接口能夠獲取不同粒度的數據，結構圖如下圖所示。下邊分別介紹各個處理模塊的主要處理邏輯

首先，校驗層會獲取到這個查詢對象，校驗這個對象攜帶的信息是否符合業務要求，如開始時間(since),結束時間(until), 查詢字段(queryFields)等屬性不能為空，開始時間不能晚于結束時間等。通過了校驗層后，就進入了緩存層。緩存層的作用主要是緩存查詢結果，其次是使用布隆隆過濾器?來防止查詢攻擊。

如果緩存層未命中，則進入了路由層，路由層的作用是確定查詢對象對應的最優查詢引擎，具體是通過元數據來獲取包含查詢字段的所有查詢引擎，然后根據查詢引擎的優先級來分別構造查詢的SQL腳本，如果能夠構造成功，則確定該查詢引擎為最優查詢引擎。對應到簡單的普通列表查詢，路由層類似于普通查詢中的確定數據對應的數據庫。核心方法如下：

     /**     * 路由的主函數     */    public StorageEngine route(QueryBase queryBase, int rejectEngine){        ...    }}

確定了查詢對象對應的查詢引擎后，則進入查詢處理層，查詢處理層主要工作是執行查詢前的對象加工，執行具體SQL查詢及查詢后的結果集加工等操作，比如查詢前，需要添加查詢指標大于零的過濾條件，查詢后填充默認值及類型轉化等。對應到普通查詢，查詢處理層類似于數據加工及數據查詢等操作。核心方法如下：

public interface ISqlBuilder {    String getSqlScript();}
public interface ISqlProcessor {    /**     * 獲取過濾條件表達式     */    String getFilterExpression(List<IFilter>filters, StorageCategory category, FilterCategory filterCategory
    /**     * 獲取字段排序表達式     */    String getOrderExpression(List<OrderItem> orderItems);
    /**     * 獲取表join表達式     */    String getJoinExpression(Pair<String, String> tables);
    /**     * 獲取分頁表達式     */    String getPageInfoExpression(PageInfopageInfo);}

通過上述各個模塊的相互配合，一個基本的一個接口能夠處理不同粒度數據的查詢接口框架就完成了?？赐炅颂幚磉壿嫷拿枋?，那么這套接口適應于什么場景呢？每套接口的產生都有其依賴的業務場景的，本套接口也不例外，它適用于那些需要對數據模型進行上卷，下轉等操作的數據分析場景，如果是少量的固定報表，本套查詢接口不是很適用。

看到這里，你是否已經在頭腦中已經有了一個簡單的查詢處理邏輯呢？如果對哪部分不清楚或了解更多細節的話歡迎在文章下邊給我留言，我們一起探討，共同進步。