涉及两个主题： 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。将状态主题读入手动添加的状态存储。您还可以将状态存储连接到处理注解主题的处理器—这样，在直接处理命令时，进程可以读取和修改状态—需要将任何内容写回状态输入主题。