每秒处理百万级行情、延迟压到个位数毫秒——这套数字放在2024年依然能打。但更让人意外的是，实现它的核心架构从2001年发布至今，几乎没变过。
这就是kdb+的tick架构。全球顶尖的对冲基金、投行交易台、甚至部分高频做市商，底层跑的都是同一套模板。它不是某个新锐团队的创业作品，而是一个活了23年的"老古董"，至今没有像样的替代品。
本文是第一篇，先拆解这套架构的骨架。后续我们会用Java和q语言，从零搭出一个能跑的生产级系统。
为什么金融数据非要"特殊对待"
普通数据库的设计假设是：数据来了，先写磁盘，再响应查询。这个假设在电商、社交场景下完全合理——用户能容忍几十毫秒的延迟，甚至无感知。
但行情数据是另一套逻辑。纽交所开盘瞬间，一只股票可能在1秒内产生数千笔报价和成交。如果你的风控系统、算法交易引擎、实时盈亏计算都依赖这些数据，"先落盘再处理"就等于主动认输。
kdb+的解法很直接：把数据锁在内存里，用列式存储压缩时间戳和数值，再用一门专为向量化计算设计的语言q来操作。
q语言和存储引擎是一体设计的。你写的查询不会被翻译成另一套执行计划，而是直接映射到内存布局。这种"零阻抗"设计，让kdb+在时间序列场景下把通用数据库甩开几个数量级。
一个冷知识：q的语法极简到近乎刻薄。筛选某只股票过去1分钟的成交，一行代码就够了。这种极简不是炫技，而是为了减少解析开销——在高频场景下，解释器每省一个CPU周期，都是真金白银。
tick架构的四个角色
单台kdb+实例叫一个q进程。生产环境从不会只有一个q进程在跑，而是拆成四个专门化的角色，像流水线一样协作。
第一个是tickerplant（行情分发器）。它是整个系统的入口，唯一职责是接收上游行情源的数据，打上时间戳，然后广播给所有订阅方。tickerplant自己不存储历史数据，只做实时转发，所以能撑住极高的吞吐量。
设计哲学在这里体现得很明显：让最快的组件只做一件事。如果tickerplant还要兼顾查询或持久化，延迟就会不可控。
第二个是real-time database（实时数据库，简称RDB）。它订阅tickerplant的数据流，把当天的所有行情保存在内存中。交易员、风控系统、算法引擎都直接连RDB查数——内存访问的速度，足够支撑盘中决策。
RDB的脆弱性也在于此：一旦进程崩溃，当天的数据就丢了。所以tick架构里还有第三个角色。
第三个是historical database（历史数据库，简称HDB）。每天收盘后，RDB把全量数据刷到磁盘，按日期分区存储。HDB的数据量可以是TB级，但查询依然很快——列式存储+分区裁剪，让跨月、跨年的历史回溯不至于变成灾难。
这里有个精妙的分工：RDB负责"现在"，HDB负责"过去"。盘中查询走RDB，盘后分析、回测、监管报送走HDB。两者数据格式完全一致，用同一套q语法就能切换。
第四个是gateway（网关）。它是对外的统一入口，把客户端的查询路由到RDB或HDB，自己不做计算。这个设计解耦了客户端和存储层——后端扩容、切换、维护，对上层透明。
四个角色，四种q进程，通过TCP/IP互相订阅和推送。没有消息队列中间件，没有复杂的协调服务，就是原生的socket通信。这种"简陋"在工程上反而是优势：故障排查时，netstat和抓包就能定位问题。
Java怎么挤进这个纯q的圈子
kdb+生态长期是q语言的独角戏，但金融机构的系统架构早就是Java的天下了。交易引擎、风控平台、报表系统，九成用Java写。让这批系统重写不现实，所以互操作性成了刚需。
官方给的答案是javakdb——一个轻量级的Java客户端库。它不做任何魔法，只是封装了kdb+的网络协议，让Java进程能像q进程一样订阅tickerplant、查询RDB、甚至向系统里写数据。
典型的混合架构是这样的：tickerplant和RDB/HDB继续用q跑，发挥性能极限；Java服务通过javakdb订阅实时行情，做复杂业务逻辑，再把计算结果写回kdb+供其他组件消费。
这种架构在大型投行里很常见。某头部做市商的技术负责人曾私下吐槽：「我们的Java团队比q团队大十倍，但行情数据只要进了kdb+，就没人想再迁出来。」
原因很现实：自研一个能匹敌kdb+吞吐量的时序数据库，人力成本以年为单位，稳定性还要赌运气。相比之下，每年付授权费反而是更理性的账。
这套架构的"暗面"
tick架构不是没有代价。q语言的陡峭学习曲线劝退过无数工程师——它不像SQL有庞大的社区和教程，出了问题往往只能翻官方文档或者问Kx Systems（kdb+的母公司）的支持。
授权模式也是争议点。kdb+按核心数或数据量收费，对于数据规模爆炸的买方机构，账单数字相当可观。这些年开源替代品如ClickHouse、TimescaleDB、甚至 specialized 的QuestDB都在追赶，但论极限性能和金融场景的成熟度，差距依然明显。
更隐蔽的问题是人才断层。懂tick架构的老手很多在2010年前入行，年轻一代更熟悉云原生技术栈。某对冲基金CTO去年在一场闭门会上直言：「我们最怕的不是系统故障，是核心q工程师退休。」
kdb+的母公司KX（原Kx Systems）显然也意识到了这一点。近年他们在推云托管版本，也在尝试用Python接口降低门槛。但核心架构本身——tickerplant、RDB、HDB、gateway的四层分工——23年来没有动摇。
下一篇我们会进入实操：用开源的tick脚本搭出基础架构，让tickerplant真正跑起来接收模拟行情。再下一篇接入Java，实现一个能订阅实时数据、执行交易信号的服务。
如果你现在就要动手，可以先去GitHub搜"kdb-tick"，这是Kx官方维护的参考实现，代码量不大，但注释里藏着很多设计决策的线索。有个细节很有意思：tickerplant的日志文件格式从2001年到现在没变过，这意味着你今天写的回放工具，能直接读取二十年前的行情记录——这种向后兼容性，在金融监管场景下是硬性要求，也是kdb+难以被取代的护城河之一。
你的团队在用kdb+吗，还是已经找到了替代方案？
热门跟贴