相关疑难解决方法(0)

我没有在kafka上工作过多,但想在GCE中构建数据管道.所以我们想知道Kafka vs PUB/Sub.基本上我想知道如何在Kafka和Pub/sub中维护消息一致性,消息可用性,消息可靠性

谢谢

此问题类似于使用Kafka作为(CQRS)Eventstore.好主意？,但更具体的实施.如何使用kafka作为事件存储,当我有数千个事件"源"(DDD中的聚合根)？正如我在链接问题和其他一些地方读到的那样,我对每个来源的主题都有疑问.如果我按类型将事件拆分为主题,则使用和存储会更容易,但我需要访问特定源的事件流.如何使用kafka进行活动采购？

我Order聚合根能够发射多种Event,例如OrderCreated,OrderPaid,OrderCancelled.会是不错的设计,所有类型的订单事件的存储到单一卡夫卡的话题,有orderId作为的消息密钥,如建议在这里？或者我应该为每个人创建一个sepparate主题？

拥有单一主题的专家是维持事件的顺序,但消费者需要在他们的结尾过滤一些事件.第二种方法的专家是消费者会更简单,因为他们可以订阅他们需要的确切主题,但构建Order需要订阅多个主题,而他们不是来自正确序列的kafka,因为它们来自不同的主题.

谢谢

使用Kafka作为事件存储工作正常,它很容易将消息保留设置为无限制.

但我已经看到一些关于Kafka被用于事件采购的报道.这就是我对如何做到这一点感到困惑的地方.作为一个活动商店,我可以在那里推送我的消息.并根据需要消费或重播.

但对于事件采购,您很可能希望读取给定实体/聚合ID的事件.您当然可以使用分区,但这似乎滥用了这个概念,实际添加新实体很难,因为分区计数更多是在静态方面,即使您可以更改它.那里有没有明智的解决方案？Apache Kafka文档本身仅简要提及事件采购.

我正在考虑使用Apache Kafka作为事件存储来在微服务中存储事件.

我通过各种博客阅读的一件事是,Kafka可以被认为是单一的事实来源,其中Kafka日志将存储给定主题的所有事件.

我想知道Kafka是否有能力从一开始就重播消息(例如,如果发生硬盘驱动器/网络崩溃)？

(请注意,我发现在主题目录下的/ tmp文件夹中存储了一些日志).有没有人知道可以调用以重播主题中的消息的任何命令(如果有的话)？

我知道CQRS可以在有或没有的情况下实现event sourcing，但它在另一端起作用吗？难道event sourcing不CQRS有意义吗？如果是这样，应如何实施？

我目前正在评估设计/实施事件溯源 + CQRS 系统设计架构方法的选项。由于我们想将 Apache Kafka 用于其他方面（正常的发布 -订阅消息 + 流处理），下一个合乎逻辑的问题是，“我们可以使用 Apache Kafka 存储作为 CQRS 的事件存储吗？”，或者更重要的是明智的决定？

现在我不确定这一点。这个来源似乎支持它：https : //www.confluent.io/blog/okay-store-data-apache-kafka/

这个其他来源建议反对：https : //medium.com/serialized-io/apache-kafka-is-not-for-event-sourcing-81735c3cf5c

在我目前的测试/实验中，我遇到了与第二个来源描述的问题类似的问题，这些问题是：

1. 重构实体： Kafka 似乎不支持快速检索/搜索主题内的特定事件（例如：与订单历史相关的所有命令 - 重建实体实例所必需的，似乎需要扫描所有主题的事件并仅过滤那些与某些实体实例标识符匹配的事件，这是不行的）。[另一个人似乎得出了类似的结论：Query Kafka topic for specific record——也就是说，这是不可能的（不依赖一些hacky技巧）]
2. - 写入一致性： Kafka 不支持其存储中的事务原子性，因此在将事件异步导出到 Kafka 队列之前，将具有某种锁定方法（通常是乐观锁定）的 DB 放入数据库似乎是一种常见的做法（我可以接受这个）不过，第一个问题对我来说更为重要）。
3. 分区问题：在Kafka文档中，提到“顺序保证”，只存在于“主题的分区”中。同时他们也说分区是并行的基本单位，换句话说，如果你想并行化工作，把消息传播到分区（当然还有broker）。但这是一个问题，因为事件源系统中的“事件存储”需要订单保证，所以这意味着如果我绝对需要订单保证，我不得不在这个用例中只使用 1 个分区。这样对吗？

尽管这个问题有点开放，但实际上是这样的：您是否使用 Kafka 作为事件源系统上的主要事件存储？您如何处理从其命令历史记录中重组实体实例的问题（鉴于该主题有数百万个条目扫描所有集合不是一种选择）？您是否只使用了 1 个分区来牺牲潜在的并发消费者（假设订单保证仅限于特定主题分区）？

任何具体的或一般的反馈都将不胜感激，因为这是一个复杂的话题，有几个考虑因素。

提前致谢。

编辑 6 年前这里有一个类似的讨论： Using Kafka as a (CQRS) Eventstore。好主意？ 当时的共识也存在分歧，很多人认为这种方法很方便，提到了 Kafka 如何在本地处理大量实时数据。尽管如此，问题（至少对我而言）与此无关，而是与 Kafka 重建实体状态的能力有多么不方便有关 - 要么通过将主题建模为实体实例（其中主题数量呈指数级增长是不希望的） ，或通过建模主题 es 实体类型（其中主题内的大量事件使重建非常缓慢/不切实际）。

我计划使用 kafka 作为事件源的持久日志，我目前正在研究不同的序列化选项。我目前的重点是使用 thrift 对我将存储在 kafka 中的消息进行序列化和反序列化。

当使用 thrift 为 kafka 序列化消息时，最简单的方法似乎是每个 kafka 主题都有一个 thrift 结构。

问题：这是在实践中遵循的好模式吗？如果没有，您能否列出遵循这种方法的缺点？

注意：如果你觉得这个问题不符合stackoverflow标准，请帮我改进！

我一直在考虑在事件源配置中使用 Apache Kafka 作为事件存储。发布的事件将与特定资源相关联，传递到与资源类型相关联的主题，并按资源 id 分片到分区中。因此，例如，创建类型为 Folder 且 ID 为 1 的资源将产生一个 FolderCreate 事件，该事件将传递到分区中的“文件夹”主题，该分区通过将 id 1 分片到主题中的分区总数来给出。即使我不知道如何处理使日志不一致的并发事件。

最简单的场景是有两个并发操作，它们可以使彼此无效，例如一个更新文件夹，一个销毁同一个文件夹。在这种情况下，该主题的分区最终可能包含无效序列 [FolderDestroy, FolderUpdate]。这种情况通常通过对事件进行版本控制来解决，如此处所述，但 Kafka 不支持此类功能。

在这些情况下，如何确保 Kafka 日志本身的一致性？

考虑一个简单的用例，我想将产品评级作为事件存储在事件存储中。

我可以使用两种不同的方法：

1. 使用Axon：Rating聚合负责处理CreateRatingCommand并发送RatingCreatedEvent。发送事件会将评级存储在事件存储中。其他事件处理程序可以在连接到 Axon 服务器实例并执行评级所需的任何操作时重播事件流。在这种情况下，事件处理程序将用作流处理器。
2. 使用Kafka： KafkaProducer 将用于在 Kafka 主题中存储评级 POJO（正确序列化后）。将主题的保留时间设置为无限期将导致任何事件都不会及时丢失。在这种情况下，Kafka Streams 将用于执行实际的评级处理逻辑。

对于这两种方法，我都出现了一些架构问题：

使用轴突时：

1. 如果聚合内没有需要维护或更改的真实状态，那么使用 Axon（或类似解决方案）是否有任何附加值？聚合仅充当数据的“哑”占位符，但不提供任何状态更改逻辑。
2. Axon 如何处理同一事件类型的多个事件处理程序？它们是否都会并行处理相同的事件（相同的聚合 ID），或者相同的事件仅由其中一个处理程序处理一次？
3. 存储在 Axon 事件存储中的事件是否会保留到时间结束？

使用卡夫卡时：

1. Kafka 将具有相同键的事件/消息存储在同一分区中。在用户产品评级用例中，如何为密钥选择最佳值？UserId、ProductId 或两者的单独主题，并在两个主题中发布每个事件。
2. 为每个用户和每个产品使用单独的主题是否明智，从而导致集群上有大量主题？（大约<5k 个产品和>10k 个用户）。

我不知道 SO 是否是此类问题的首选论坛...我只是想知道您在这个特定用例中推荐什么作为最佳实践。期待您的反馈，并随时指出我在之前的问题中遗漏的其他想法。

编辑@12/11/2020：我刚刚找到了一个相关的讨论，其中包含与我的问题相关的有用信息。

将Kafka用作事件存储时，如何配置日志永不丢失数据（v0.10.0.0）？

我看过（旧的？）log.retention.hours，并且我一直在考虑使用压缩键，但是kafka是否可以选择从不删除消息？

还是在保留期内高得离谱的最佳选择？