技术文档丨查询接口的内部执行逻辑

赵立贺

悠易互通丨技术专家

技术产品中心

数据组

阅读完上篇《查询接口的演进过程》之后，我们一起来探索下《查询接口的内部执行逻辑》吧：

 上一篇《技术文档丨查询接口的演进过程》中我们讲到了经过一层层的重构，我们对接前端的接口变为了一个。那么今天我们一起来讨论下通过一个接口获取不同粒度的数据的内部处理逻辑是怎样流转的。

在介绍一个接口获取不同粒度数据之前，大家先想想，开发一个被经常访问的数据列表接口，我们通常会怎么处理呢？是不是会考虑数据存储在什么数据库里面，使用到了哪几张表，列表的字段和数据表的字段的对应关系是怎样的，字段是否需要经过特殊的转化以及是否需要将结果集缓存等过程。

对于一个普通的列表接口都需要考虑这么多的内容，那么一个接口能够处理不同粒度的数据是不是要复杂的多啊？答案是不一定，因为我们仅需要将上述涉及的各个考虑过程进行抽象，形成各自的处理模块，然后对不同的处理模块进行流程指定及处理模块的具体化即可，也就是使用代码实现上述的考虑过程。基于这样的抽象设计思路，目前已经将查询接口抽象出校验层、缓存层、路由层、处理层、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);}

通过上述各个模块的相互配合，一个基本的一个接口能够处理不同粒度数据的查询接口框架就完成了。看完了处理逻辑的描述，那么这套接口适应于什么场景呢？每套接口的产生都有其依赖的业务场景的，本套接口也不例外，它适用于那些需要对数据模型进行上卷，下转等操作的数据分析场景，如果是少量的固定报表，本套查询接口不是很适用。

看到这里，你是否已经在头脑中已经有了一个简单的查询处理逻辑呢？如果对哪部分不清楚或了解更多细节的话欢迎在文章下边给我留言，我们一起探讨，共同进步。