涉及两个主题: commands
你不会相信的命令,和 state
,它是ktable(只是普通的,不是globalktable)。
拓扑结构如下所示: commands.leftJoin(state, computeNewState).to(state)
i、 命令作用于当前状态并为同一主题生成新的状态。有点 command X state -> state
在功能程序方面;最终结果在哪里 state
是在同一个地方产生的,初始状态是从那里取得的。
在我看来,经典的种族条件隐藏在那里;由于两个(几乎)同时发出的命令可能会产生以下顺序: command_1
到达并消耗 state_1
;
重新计算后, state_2
是通过应用 command_1
; state_2
React to
节点和有效的异步ioKafka发生。。。
……但它还不够快,无法应用;同时 command_2
带着同样的钥匙 leftJoin
作用于 state_1
而不是 state_2
只是因为 state_2
尚未交付给Kafka,也尚未被Kafka看到;
量化宽松。
我说得对吗?
1条答案
按热度按时间55ooxyrt1#
你所描述的是正确的。
也许您可以只使用一个输入主题,而使用聚合来修改状态?对于这种情况,状态的更新是同步的。
如果这是不可能的,我建议回到处理器api。将状态主题读入手动添加的状态存储。您还可以将状态存储连接到处理注解主题的处理器—这样,在直接处理命令时,进程可以读取和修改状态—需要将任何内容写回状态输入主题。