我们使用Kafka已经一年多了，希望继续进行更深层次的集成。但有一个概念我很难理解。我将尝试解释我们想要实现什么，以及我们想出的解决方案是什么样子的。从我的角度来看，这不是一个真正优雅的方式，这就是为什么我质疑我是否做对了。
问题
我们有一个具有复杂结构化事件(嵌套结构(的流。消费者正在接受这些事件，将它们拆开，并将这些片段放在不同的主题中。每个主题背后都有许多不同的其他服务，它们以流处理的方式丰富了主题中的事件。最后，我们有许多主题，每个主题都有部分丰富的事件，我们希望将它们放在一起，在整个过程结束时将它们作为一个完整的事件重新组合起来。但这说起来容易做起来难。
解决方案
最后，我们有一个服务，它消耗所有的主题，并构建一个缓冲区，直到所有的部分事件传入，并将它们放在一起发布到一个新的主题中。我们面临的挑战是确保我们只在最后的主题中制作完整的事件。这是可行的，但有一些陷阱
- 缓冲区不能是内部的，它必须是外部的，多个消费者可以共享信息
- 理论上，我们可以在时间问题上运行并创建死条目
- 我们可能会遇到一致性问题
- 等等
我的问题
即使它有效，而且我不认为这是一种非常优雅的方式，我们是否走在了正确的轨道上，或者我们在卡夫卡事件的概念和处理以及流处理方面误解了什么？有更好的方法吗？有人对此有经验吗？可以分享一些倾向或以稳定的方式整合它的方法吗？
谢谢！如有任何意见，我们将不胜感激。
我们经历了一个非常相似的用例和体系结构。我知道您将初始嵌套消息拆分为多个主题，以提高并行性，从而提高吞吐量。
根据我们的经验，这导致了一个高度复杂的体系结构，因为连接流(正如您已经描述的(可能很难操作。我们遇到的主要问题是：
- 如果其中一个富集作业失败，所有其他消息应该等待多久？修复这个错误可能需要几个小时或几天的时间
- 如果这些富集作业依赖于外部系统，并且在一段时间内无法访问。您应该等待多长时间才能再次使用它们
根据我们的经验，您所描述的当前方法带来了许多复杂性和(有时是不可控的(依赖性。
最后，我们将所有数据放在一起，并显著增加了主题的分区以提高吞吐量。这样，每条消息本身都是一致的，如果任何富集出现问题，整个消息都会受到影响，而不仅仅是其中的一部分。为了降低单个作业的复杂性，我们在Kafka主题中缓冲了临时数据，在您的情况下，这可能意味着各种富集作业按顺序运行，而不是与其间的主题并行。这样，每个作业都保持合理的小规模，并且您可以利用Kafka附带的重新播放功能。
操作流连接是最复杂的事情之一，我建议尽可能避免这种情况，除非出现短期不一致是可以接受的，并且您不需要处理所有消息，而是可能会丢弃其中一条或另一条。