使用Kafka作为（CQRS）Eventstore。好主意？

作者: 無口君
发布时间: 2025-01-23 04:17:07 (14天前)
转自：

6 条回复

0#
回复此人
那年 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> Kafka是一个消息传递系统，它与事件存储有很多相似之处，但引用它们的介绍： </p> <BLOCKQUOTE> <P> Kafka集群保留所有已发布的消息 - 无论它们是否存在已消耗 - 的<strong> 在一段可配置的时间内 </强> 。例如，如果保留时间设置为两天，然后设置为两天后消息发布后可供消费，之后就可以了将被丢弃以释放空间。卡夫卡的表现是有效的在数据大小方面保持不变，因此保留大量数据不是问题。 </p> </BLOCKQUOTE> <P> 因此，虽然可以无限期地保留消息，但期望它们将被删除。这并不意味着您不能将其用作事件存储，但使用其他东西可能更好。看一眼 <a href="http://geteventstore.com/" rel="noreferrer"> EventStore </A> 替代方案。 </p> <H1> UPDATE </H1> <P> <a href="http://kafka.apache.org/documentation.html" rel="noreferrer"> 卡夫卡文件 </A> ： </p> <BLOCKQUOTE> <P> 事件源是一种应用程序设计风格，其中状态更改被记录为按时间排序的记录序列。 Kafka对非常大的存储日志数据的支持使其成为以这种风格构建的应用程序的出色后端。 </p> </BLOCKQUOTE> <H1> 更新2 </H1> <P> 使用Kafka进行事件采购的一个问题是所需主题的数量。通常在事件源中，每个实体（例如用户，产品等）存在事件流（主题）。这样，可以通过重新应用流中的所有事件来重构实体的当前状态。每个Kafka主题由一个或多个分区组成，每个分区都存储为文件系统上的目录。随着znode数量的增加，ZooKeeper也会有压力。 </p> </DIV>

编辑
1#
回复此人
岁爵 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 您可以使用Kafka作为事件存储，但我不建议这样做，尽管它可能看起来不错： </p> <UL> <LI> Kafka只保证至少一次交付，并且有重复在无法删除的事件存储中。的<strong> 更新： </强> 在这里，您可以阅读Kafka为何如此难以及有关如何最终实现此行为的最新消息： <a href="https://www.confluent.io/blog/exactly-once-semantics-are-possible-heres-how-apache-kafka-does-it/" rel="noreferrer"> https://www.confluent.io/blog/exactly-once-semantics-are-possible-heres-how-apache-kafka-does-it/ </A> </LI> <LI> 由于不变性，当应用程序发展并且需要转换事件时，没有办法操纵事件存储（当然有像upcasting这样的方法，但是......）。一旦可能会说你永远不需要转换事件，但这不是正确的假设，可能会有你原始备份的情况，但你将它们升级到最新版本。这是事件驱动架构中的有效要求。 </LI> <LI> 没有地方可以保留实体/聚合的快照并且重放将变得越来越慢。从长远角度来看，创建快照是事件存储的必备功能。 </LI> <LI> 鉴于Kafka分区是分布式的，它们很难管理备份与数据库比较。数据库简单易懂:-) </LI> </UL> <P> 所以，在你做出选择之前，你要三思而后行。事件存储作为应用程序层接口（监视和管理），SQL / NoSQL存储和Kafka作为代理的组合是比Kafka处理这两个角色以创建完整功能完整解决方案更好的选择。 </p> <P> 事件存储是一项复杂的服务，如果您认真考虑在事件驱动架构中应用事件源，CQRS，Sagas和其他模式并保持高性能，则需要更多Kafka所能提供的服务。 </p> <P> 的<strong> 随意挑战我的答案！ </强> 您可能不喜欢我对您最喜欢的具有大量重叠功能的经纪人所说的话，但Kafka仍然不是设计为事件存储，而是更多地作为高性能代理和缓冲区同时处理快速生产者与慢速消费者场景，例如。 </p> <P> 请查看eventuate.io微服务开源框架，以发现有关潜在问题的更多信息： <a href="http://eventuate.io/" rel="noreferrer"> http://eventuate.io/ </A> </p> <H2> 自2018年2月8日起更新 </H2> <P> 我没有收录评论中的新信息，但同意其中的一些方面。此更新更多是关于微服务事件驱动平台的一些建议。如果您认真对待微服务稳健设计和最高性能，我将为您提供一些您可能感兴趣的提示。 </p> <OL> <LI> 不要使用Spring - 它很棒（我自己经常使用它），但同时又重又慢。它根本不是微服务平台。它只是一个框架来帮助你实现一个（这背后的很多工作......）。其他框架“只是”轻量级REST或JPA或不同的框架。我推荐可能是一流的开源完整微服务平台，它可以回归纯Java根源： <a href="https://github.com/networknt" rel="noreferrer"> https://github.com/networknt </A> </LI> </醇> <P> 如果您对性能有疑问，可以将自己与现有的基准测试套件进行比较。 <a href="https://github.com/networknt/microservices-framework-benchmark" rel="noreferrer"> https://github.com/networknt/microservices-framework-benchmark </A> </p> <ol start =“2”> <LI> <P> 根本不要使用Kafka :-)）这是半开玩笑。我的意思是，虽然卡夫卡很棒，但它是另一个以经纪人为中心的系统。我认为未来是在无需经纪人的邮件系统中。你可能会感到惊讶，但有比Kafka系统更快的速度:-)，当然你必须降到更低的水平。看看纪事。 </p> </LI> <LI> <P> 对于事件存储，我建议使用名为TimescaleDB的高级Postgresql扩展，它专注于大容量的高性能时间序列数据处理（事件是时间序列）。当然CQRS，事件采购（重放等功能）都是在light4j框架中构建的，它使用Postgres作为低存储空间。 </p> </LI> <LI> <P> 对于消息传递，请尝试查看Chronicle Queue，Map，Engine，Network。我的意思是摆脱这个的<strong> 老式的经纪人中心 </强>解决方案并采用微信息系统（嵌入式系统）。 Chronicle Queue实际上比Kafka更快。但我同意这不是一个解决方案，你需要做一些开发，否则你去购买企业版（付费一个）。最后，通过消除维护Kafka集群的负担，将从Chronicle构建您自己的消息传递层。 </p> </LI> </醇> </DIV>

编辑
2#
回复此人
那月静好 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 我是卡夫卡的原作者之一。 Kafka将作为事件采购的日志工作得非常好。它具有容错能力，可扩展到巨大的数据大小，并具有内置的分区模型。 </p> <P> 我们在LinkedIn使用此表单的几个用例。例如，我们的开源流处理系统Apache Samza随附 <a href="http://samza.incubator.apache.org/learn/documentation/0.7.0/container/state-management.html"> 内置支持 </A> 用于事件采购。 </p> <P> 我认为你没有太多关于使用Kafka进行事件采购的原因，主要是因为事件采购术语在Kafka最受欢迎的消费者网络空间中似乎并不普遍。 </p> <P> 我已经写了一些关于这种卡夫卡用法的文章 <a href="http://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying"> 这里 </A> 。 </p> </DIV>

编辑
3#
回复此人
夏花 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 是的，您可以将Kafka用作活动商店。它运作得很好，特别是在引入时 <a href="https://docs.confluent.io/current/streams/index.html" rel="noreferrer"> 卡夫卡流 </A> ，它提供了一种Kafka本地方式来处理您的事件累积 <a href="https://docs.confluent.io/current/streams/concepts.html#interactive-queries" rel="noreferrer"> 说明你可以查询 </A> 。 </p> <P> 关于： </p> <BLOCKQUOTE> <P> 能够重放事件日志，允许新订户在事后注册系统。 </p> </BLOCKQUOTE> <P> 这可能很棘手。我在这里详细介绍了这一点： <a href="https://stackoverflow.com/a/48482974/741970"> https://stackoverflow.com/a/48482974/741970 </A> </p> </DIV>

编辑
4#
回复此人
生如夏花 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> <EM> 我一直回到这个QA。而且我没有发现现有的答案有细微差别，所以我添加了这个。 </EM> </p> <H1> TL; DR。是或否，取决于您的活动采购用途。 </H1> <P> 我知道有两种主要的事件源系统。 </p> <H2> 下游事件处理器=是 </H2> <P> 在这种系统中，事件发生在现实世界中并被记录为事实。如仓库系统，以跟踪产品的托盘。基本上没有冲突的事件。一切都已经发生，即使它是错的。（即，托盘123456放在卡车A上，但是计划用于卡车B.）然后通过报告机制检查事实的异常情况。 Kafka似乎非常适合这种下游事件处理应用程序。 </p> <P> 在这种情况下，为什么Kafka人们将其作为事件采购解决方案提倡是可以理解的。因为它与已经使用的方式非常相似，例如，点击流。然而，使用术语事件采购（与流处理相对）的人可能指的是第二种用法...... </p> <H2> 应用程序控制的事实来源=否 </H2> <P> 由于用户请求通过业务逻辑，这种应用程序声明自己的事件。由于两个主要原因，卡夫卡在这种情况下效果不佳。 </p> <H3> 缺乏实体隔离 </H3> <P> 此方案需要能够为特定实体加载事件流。这样做的常见原因是为业务逻辑构建一个临时写模型，用于处理请求。这样做在卡夫卡是不切实际的。使用每个实体主题可以允许这样做，但是当可能有数千或数百万个实体时，这是非启动性的。这是由于Kafka / Zookeeper的技术限制。建议使用每个类型的主题代替Kafka，但这需要加载事件 <EM> 每个实体 </EM> 该类型只是为了获得单个实体的事件。由于您无法通过日志位置判断哪些事件属于哪个实体。即使使用 <a href="https://www.martinfowler.com/eaaDev/Snapshot.html" rel="nofollow noreferrer"> 快照 </A> 从已知的日志位置开始，这可能是大量的事件。但快照无法帮助您更改代码。因为向业务逻辑添加新功能可能会使以前的快照在结构上不兼容。因此，在这些情况下仍然需要进行主题重放以构建新模型。使用瞬态写入模型而不是持久性写入模型的主要原因之一是使业务逻辑变更便宜且易于部署。 </p> <H3> 缺乏冲突检测 </H3> <P> 其次，由于针对同一实体的并发请求，用户可以创建竞争条件。保存冲突事件并在事后解决它们可能是非常不受欢迎的。因此，能够防止冲突事件非常重要。为了扩展请求负载，通常使用无状态服务，同时使用条件写入防止写入冲突（仅在最后一个实体事件为#x时写入）。又名乐观并发。 Kafka不支持乐观并发。即使它在主题级别支持它，它也需要一直到实体级别才能生效。要使用Kafka并防止冲突事件，您需要在应用程序级别使用有状态的序列化编写器。这是一个重要的架构要求/限制。 </p> <P> <a href="https://medium.com/serialized-io/apache-kafka-is-not-for-event-sourcing-81735c3cf5c" rel="nofollow noreferrer"> 更多的信息 </A> </p> <HR /> <P> <EM> 每条评论更新 </EM> </p> <P> 该评论已被删除，但问题是：人们用什么来进行事件存储呢？ </p> <P> 似乎大多数人在现有数据库之上推出自己的事件存储实现。对于非分布式场景，如内部后端或独立产品，它是 <a href="https://cqrs.wordpress.com/documents/building-event-storage/" rel="nofollow noreferrer"> 充分证明 </A> 如何创建基于SQL的事件存储。并且在各种数据库之上有可用的库。还有EventStore，它是为此目的而构建的。 </p> <P> 在分布式场景中，我看到了几种不同的实现。李连杰的 <a href="https://www.youtube.com/watch?v=dSCzCaiWgLM" rel="nofollow noreferrer"> Panther项目使用Azure CosmosDB </A> ，使用Change Feed通知听众的功能。我在AWS上听到的另一个类似的实现是使用DynamoDB及其Streams功能来通知侦听器。分区键可能应该是用于最佳数据分发的流ID（以减少过度配置的数量）。但是，在Dynamo中跨流的完整重播是昂贵的（阅读和成本方面）。因此，这个impl也被设置为Dynamo Streams将事件转储到S3。当一个新的监听器上线，或者一个现有的监听器想要一个完整的重放时，它会先读取S3以便赶上。 </p> <P> 我目前的项目是一个多租户场景，我在Postgres上推出了自己的项目。像Citus这样的东西似乎适合于可扩展性，可以通过tentant + stream进行分区。 </p> <P> Kafka在分布式场景中仍然非常有用。将每个服务的事件暴露给其他服务是一个非常重要的问题。事件存储不是为此而构建的，但这正是Kafka所做的。每个服务都有自己的内部事实来源（可能是事件存储或其他），但是听听Kafka知道“外部”发生了什么。该团队还可以将其服务活动发布到Kafka，以告知服务所做的有趣事情的“外部”。 </p> </DIV>

编辑

登录后才能参与评论