KDB+ TorQ架构下模拟Slow Subscriber遇到的问题咨询

问题根源 #

你混淆了KDB+原生发布订阅机制和TorQ STP（Streaming Transport Process）的专属机制。TorQ的流数据管理完全依赖STP组件，原生的.u模块、.z.W队列在这里不生效，这就是你看不到队列消息、订阅报错的核心原因。

分步解决 #

1. 把目标表加入STP发布列表 #

报错“Table tab is not in list of stp pub/sub tables”说明tab不在TorQ STP的发布清单里，你之前用.z.w查的是原生KDB+的发布列表，和STP无关。

• 永久配置：修改TP进程的配置文件（如config/process.cfg），找到TP的配置段，添加pubtables: tab（多表用逗号分隔），重启TP生效。
• 临时生效：在TP端执行.stp.addpub[tab]`，但重启后会丢失，仅用于测试。
• 验证：在TP端执行.stp.pubtables，确认tab在输出列表中。

2. 用STP标准接口发布数据 #

放弃原生.u.pub，改用TorQ STP的发布方法：

q) data:([]time:99?.z.p; sym:99?`AAPL`GOOG`AAPL; table:99?`tab1`tab2`tab3; size:99?53.54)
q) .stp.pub[`tab;data]  // TorQ STP官方发布接口

3. 查看STP的订阅者队列 #

.z.W是原生KDB+的队列，STP用自己的队列存储待发送消息，要查看堆积情况，用STP专用命令：

q) .stp.stats[]  // 查看完整STP统计，含队列长度、订阅者状态
q) .stp.qlen[]   // 直接输出每个订阅者的队列消息数

4. 正确模拟慢订阅者 #

直接执行system "sleep 500"只是让RDB进程休眠，不会影响STP的消息处理逻辑。要模拟慢订阅，需修改RDB端的STP消息回调函数，给数据处理加延迟：

q) // 替换默认的表处理回调，每条消息处理延迟10ms
q) .stp.tblHandler:{[t;d] system "sleep 10"; upsert[t;d]}

这样当RDB处理速度跟不上TP发布速度时，TP端的STP队列就会堆积，此时用.stp.qlen就能看到队列长度增长。

5. 用STP接口订阅表 #

在RDB端不要用原生.u.sub，改用TorQ的STP订阅命令：

q) .stp.sub[`tab;`]  // TorQ STP标准订阅接口

内容的提问来源于stack exchange，提问作者Zahid Kazi