当前位置：首页 > news >正文

CacheSQL（三）：双 HTTP 引擎与 SQL 查询——接口抽象的价值

news 2026/5/3 6:47:38

CacheSQL（三）：双 HTTP 引擎与 SQL 查询——接口抽象的价值

CacheSQL 有两种用法。一种是 Java API 内嵌调用，另一台机器上的 Python、Node、shell 脚本 HTTP 调用。

两种场景对应两套引擎：JDK 内置和 Undertow NIO。如果一开始没做好抽象，这两套引擎会写成两套重复代码。好在一开始就定义了一个接口。

一、HttpServerEngine：一个接口，两个实现

publicinterfaceHttpServerEngine{voidstart(intport,intthreads);voidstop();voidregisterRoute(Stringpath,RouteHandlerhandler);interfaceRouteHandler{voidhandle(Requestreq,Responseresp)throwsException;}}

就三个方法：启动、停止、注册路由。具体的 HTTP 实现（JDK / Undertow）各写各的，业务代码只依赖接口。

一键切换：

# 开发/测试：零外部依赖 server.http.engine=jdk # 生产：换 Undertow，吞吐量提升 50-60% server.http.engine=undertow

切换了之后一行代码不用改。启动时HttpCacheServer读配置、反射加载引擎、绑定端口。

为什么保留两套引擎

JDK 引擎：com.sun.net.httpserver.HttpServer，Java 标准库自带，零依赖。适合开发环境、内嵌部署。缺点是 BIO——每连接一个线程，高并发天花板低。

Undertow 引擎：NIO 多路复用，Worker 线程和 IO 线程分离。8 线程读取 QPS 比 JDK 引擎高了 60%，写入高了 50%。代价是多一个 1.2MB 的依赖包。

两套引擎不是"一套高级一套低级"，是不同场景下的最优选择。JAR 包 80KB 的内嵌调用，挂 Undertow 太浪费。HTTP 服务对外暴露，必须上 NIO。

二、为什么 JSQLParser：不是造轮子，是站在轮子上

SQL 查询有三种做法：

自己写词法分析器→ 2000 行起跳，bug 无数
用正则抠字段→ 能跑但SELECT * FROM t WHERE name='O''Brien'会崩
用现成的解析库→ JSQLParser

JSQLParser 把 SQL 文本解析成结构化语法树——字段列表、表名、WHERE 条件的逻辑关系——全都是结构化的对象，不用自己去抠字符串。4.9 版本稳定多年，450KB，一个依赖搞定。

这不是偷懒。这是工程上正确的事——用成熟的轮子，把精力留给有价值的部分。

三、执行计划缓存：省掉 99% 的重复解析

同一模板的 SQL 会反复出现。WHERE AAC001 = 12345和WHERE AAC001 = 67890的结构一模一样，只是值不同。

如果在缓存时保存完整的 WHERE 条件（包含值12345），每次查询都匹配不上，缓存完全失效。解决方案是模板化——用正则把 SQL 中的字符串和数字替换成?：

原始：SELECT * FROM KCA2 WHERE AAC001 = 12345 AND AAC003 = '张三' 模板：SELECT * FROM KCA2 WHERE AAC001 = ? AND AAC003 = ?

以"模板"作为缓存 key，同一个 key 永远命中同一个执行计划。第二次查询直接走缓存，省掉解析过程。只有第一次 SQL 模板才是真正的 JSQLParser 解析开销。

取出缓存后，把具体参数（12345、张三）注入到执行计划的 PlanCondition 里，执行查询。具体参数从原始 SQL 中用正则提取：

privatestaticfinalPatternVALUE_PATTERN=Pattern.compile("('[^']*'|\\b\\d+(\\.\\d+)?\\b)");

缓存的一个细节问题

解析后的 PlanCondition 存入缓存，多线程并发查询都需要读同一个条件和修改它的值——如果不隔离，线程 A 可能在线程 B 把值改成67890之后才开始用12345查询，但读到的已经是67890。

不是 synchronized 的问题——synchronized 保证不崩，不保证不串。解法是深拷贝：

// 每次查询前深拷贝 PlanConditionPlanCondition[]copyConditions(){PlanCondition[]copy=newPlanCondition[conditions.length];for(inti=0;i<conditions.length;i++){copy[i]=newPlanCondition(conditions[i].op,conditions[i].column,conditions[i].value);copy[i].value2=conditions[i].value2;}returncopy;}

语义上是一个新对象——值互不干扰。多线程同时执行，每个线程各自填充自身拷贝的值，不串读。

另一个细节：缓存无上限

planCache是一个ConcurrentHashMap，没有配置容量上限。理论上，如果 SQL 模板不断增多，缓存会无限膨胀。

目前用了简单的兜底：超过 1024 个模板后直接planCache.clear()——粗暴但有效。CacheSQL 的使用场景是有缓的（几十条业务 SQL），模板数不会无限增长。但对比 OpLog 的环形缓冲区，这里的处理明显粗糙——承认了"当前场景够了，后面再说"。

四、索引优先级：等值优先

多条件查询中最常见的是WHERE AAC001 = 12345 AND AAC003 = '张三'——两个条件都要满足，两个字段都有索引。

但 B+ 树一次只能选择一个索引执行——不能"先查 AAC001 的 B+ 树，又查 AAC003 的 B+ 树，然后取交集"。因为没有下标层面的集合操作 API——两个 B+ 树分别返回对象列表，在 Java 里"取交集"只能遍历，O(N)。

所以只能选一个索引。优选等值：

privatestaticPlanConditionfindBestIndex(Tabletable,PlanCondition[]conditions){PlanConditionbest=null;intbestPriority=-1;for(PlanConditionc:conditions){if(table.getIndex().containsKey(c.column)){intpri=c.op==Op.EQ?10:5;// 等值 = 10，范围 = 5if(pri>bestPriority){bestPriority=pri;best=c;}}}returnbest;}

选择最优索引后，其余条件在内存中逐行过滤——只对索引查出的候选行做。如果索引过滤效果高（大部分行被过滤掉），内存过滤就不是瓶颈。

范围查询上还有个细节优化：WHERE age >= 20 AND age <= 30——两个条件在同一列，都是范围查询。如果分别调两次 B+ 树再取交集，耗时不翻倍吗？所以检测到>= + <=组合时直接合并为一次getMoreAndLessThen(lower, upper)调用：

privatestaticPlanConditionfindRangePartner(PlanCondition[]conditions,PlanConditionindexed){for(PlanConditionc:conditions){if(c.column.equals(indexed.column)){if((indexed.op==GE||indexed.op==GT)&&(c.op==LE||c.op==LT))returnc;if((indexed.op==LE||indexed.op==LT)&&(c.op==GE||c.op==GT))returnc;}}returnnull;// 没有范围搭档，单次调用一种边界方法}

五、LIKE 前缀查询：转化为范围查询

LIKE '张%'怎么走 B+ 树？B+ 树不支持模糊匹配。但它支持两个能力：

沿着链表从某个位置开始扫（searchmore找到第一个 ≥ 该值的位置）
沿着链表扫到某个位置停下（再自己判断超出上界即退出）

所以LIKE '张%'转换为"范围查询"——下界是张，上界是张的字典序后一位（即矛起始的 Unicode 码点）：

privatestaticStringprefixUpperBound(Stringprefix){charlast=prefix.charAt(prefix.length()-1);returnprefix.substring(0,prefix.length()-1)+(char)(last+1);}