虽然我已经遇到卡夫卡之前，我刚刚意识到卡夫卡也许可以作为（基础）一CQRS，eventstore。

Kafka支持的主要观点之一：

• 事件捕获/存储，当然都是HA。
• Pub / sub架构
• 重播事件日志的能力，使新订户可以在事件发生后向系统注册。

诚然，我不是100％精通CQRS /事件源，但是这似乎与事件存储区应该的非常接近。有趣的是：关于Kafka用作事件存储，我实在找不到太多，所以也许我错过了一些东西。

那么，卡夫卡缺少什么东西可以使其成为一个好的活动库？能行吗？用它生产吗？对洞察力，链接等感兴趣

基本上，系统状态是根据系统曾经收到的事务/事件保存的，而不仅仅是保存系统的当前状态/快照（通常这样做）。（将其视为会计中的总帐：最终所有事务都加到最终状态）。这允许进行各种有趣的事情，但请仔细阅读提供的链接。

Kafka旨在成为一个消息传递系统，它与事件存储库有很多相似之处，但是引述了它们的介绍：

Kafka群集将所有已发布的消息（无论是否已被使用）保留一段可配置的时间。例如，如果将保留时间设置为两天，则在发布消息后的两天内，该消息可供使用，之后将被丢弃以释放空间。Kafka的性能相对于数据大小实际上是恒定的，因此保留大量数据不是问题。

因此，尽管可以无限期地保留消息，但是期望消息将被删除。这并不意味着您不能将其用作事件存储，但是最好使用其他东西。看看EventStore作为替代方案。

更新

Kafka文档：

事件源是应用程序设计的一种样式，其中状态更改以时间顺序记录记录。Kafka对大量已存储日志数据的支持使其成为以这种风格构建的应用程序的绝佳后端。

更新2

使用Kafka进行事件采购的一个关注点是所需主题的数量。通常，在事件源中，每个实体（例如用户，产品等）都有事件流（主题）。这样，可以通过重新应用流中的所有事件来重构实体的当前状态。每个Kafka主题都包含一个或多个分区，每个分区都存储为文件系统上的目录。随着znode数量的增加，ZooKeeper也将带来压力。

我是Kafka的原始作者之一。Kafka可以很好地用作事件源的日志。它具有容错能力，可以扩展到巨大的数据大小，并且具有内置的分区模型。

我们在LinkedIn上将其用于此表单的多个用例。例如，我们的开源流处理系统Apache Samza 内置了对事件源的支持。

我想您对使用Kafka进行事件源知之甚少，主要是因为事件源术语在Kafka最流行的消费者网络领域似乎并不普遍。

我已经写了一些关于这种风格卡夫卡的使用这里。

我继续回到此质量检查。而且我发现现有答案不够细致，因此我添加了这个答案。

TL; DR。是或否，这取决于您的事件源使用情况。

我知道有两种主要的事件源系统。

下游事件处理器=是

在这种系统中，事件发生在现实世界中，并记录为事实。例如用于跟踪产品托盘的仓库系统。基本上没有冲突事件。一切都已经发生，即使它是错误的。（即，托盘123456放在卡车A上，但原定在卡车B上。）然后，通过报告机制检查事实是否存在异常。Kafka似乎非常适合这种下游事件处理应用程序。

在这种情况下，可以理解为什么卡夫卡人提倡将其作为事件采购解决方案。因为它与单击流中已使用的方法非常相似。但是，使用术语“事件源”（而不是“流处理”）的人可能是指第二种用法...

应用程序控制的真理来源=否

由于用户请求通过业务逻辑传递，这种应用程序声明了自己的事件。Kafka在这种情况下不能很好地工作，主要有两个原因。

缺乏实体隔离

这种情况需要能够为特定实体加载事件流。这样做的常见原因是为业务逻辑建立一个瞬态写入模型，以用于处理请求。在Kafka中这样做是不切实际的。使用每个实体的主题可能会允许这样做，但是当可能有成千上万个实体时，这不是入门。这是由于Kafka / Zookeeper中的技术限制所致。

以这种方式使用瞬态写入模型的主要原因之一是使业务逻辑更改便宜且易于部署。

建议不要为Kafka使用每个类型的主题，但这会要求为该类型的每个实体加载事件，只是为了获取单个实体的事件。由于您无法通过日志位置分辨哪些事件属于哪个实体。即使使用快照从已知的日志位置开始，这也可能是大量需要处理的事件。

缺乏冲突检测

其次，由于对同一实体的并发请求，用户可以创建竞争条件。保存冲突事件并在事件发生后解决它们可能是非常不希望的。因此，重要的是能够防止发生冲突的事件。为了扩展请求负载，通常使用无状态服务，同时使用条件写入来防止写入冲突（仅当最后一个实体事件为#x时才进行写入）。又名乐观并发。Kafka不支持乐观并发。即使它在主题级别提供了支持，它也必须一直到实体级别才能生效。要使用Kafka并防止发生冲突的事件，您将需要在应用程序级别使用有状态的序列化编写器。这是一个重要的体系结构要求/限制。

更多信息

每条评论更新

该评论已被删除，但问题是这样的：那么人们将什么用于事件存储？

似乎大多数人都将他们自己的事件存储实现放在现有数据库之上。对于非分布式方案，例如内部后端或独立产品，如何创建基于SQL的事件存储的文档已备有证明。并且在各种数据库之上都有可用的库。还有EventStore，是为此目的而构建的。

在分布式方案中，我已经看到了几种不同的实现。Jet的Panther项目使用Azure CosmosDB和Change Feed功能来通知侦听器。我在AWS上听说过的另一个类似实现是使用DynamoDB及其Streams功能来通知侦听器。分区键可能应该是流ID，以实现最佳的数据分发（以减少过度配置的数量）。但是，在Dynamo中跨流进行完全重播非常昂贵（读取和费用合理）。因此，还为Dynamo Streams设置了此impl以将事件转储到S3。当新的侦听器上线或现有的侦听器要进行完整重播时，它将读取S3以先追赶。

我当前的项目是一个多租户场景，我在Postgres之上建立了自己的项目。像Citus之类的东西似乎适合于可伸缩性，即按帐篷+流进行分区。

Kafka在分布式方案中仍然非常有用。将每个服务的事件公开给其他服务是不平凡的问题。事件存储通常不是为此创建的，但这恰恰是Kafka做得很好的。每个服务都有其自己的内部事实来源（可能是事件存储或其他），但会收听Kafka以了解“外部”正在发生的事情。该服务还可以向Kafka发布事件，以将“有趣的事情”通知“外部”。

您可以将Kafka用作事件存储，但不建议这样做，尽管它看起来似乎是不错的选择：

• Kafka仅保证至少交付一次，并且事件存储中有无法删除的重复项。 更新： 在这里您可以了解使用Kafka为何如此困难，以及有关如何最终实现此行为的一些最新消息：https : //www.confluent.io/blog/exactly-once-semantics-are-possible-heres-how -apache-kafka-does-it /
• 由于不变性，当应用程序演变且需要转换事件时，无法操纵事件存储（当然，有诸如上投的方法，但...）。可能有人说过您永远不需要转换事件，但这不是正确的假设，有可能您备份了原始文件，但将它们升级到了最新版本。这是事件驱动架构中的有效要求。
• 持久保存实体/聚合快照和重播的位置将变得越来越慢。从长期的角度来看，创建快照是事件存储的必需功能。
• 给定Kafka分区是分布式的，与数据库相比，它们很难管理和备份。数据库更简单:-)

因此，在做出选择之前，请三思。将事件存储作为应用程序层接口（监视和管理），SQL / NoSQL存储以及作为代理的Kafka的组合，比让Kafka扮演两个角色来创建完整功能的完整解决方案更好。

事件存储是一项复杂的服务，如果您认真考虑将事件源，CQRS，Sagas和其他模式应用于事件驱动的体系结构并保持高性能，那么它需要的不仅仅是Kafka所能提供的。

随时挑战我的答案！您可能不喜欢我所说的关于您最喜欢的具有很多重叠功能的经纪人的说法，但是，Kafka并不是作为事件存储而设计的，而是更多地作为高性能经纪人和缓冲区来同时处理快速生产者和缓慢消费者的情况，例如。

请查看eventuate.io微服务开源框架，以了解有关潜在问题的更多信息：http : //eventuate.io/

截至2018年2月8日更新

我不会在评论中加入新信息，但会在某些方面达成共识。此更新更多有关微服务事件驱动平台的一些建议。如果您对微服务的鲁棒性设计和可能的最高性能感到认真，那么我将为您提供一些您可能不感兴趣的提示。

1. 不要使用Spring-很棒（我经常使用它），但同时又又笨又慢。它根本不是微服务平台。它只是一个框架，可以帮助您实现一个框架（此背后的大量工作。）。其他框架是“仅仅是”轻量级的REST或JPA或侧重点不同的框架。我建议最好使用同类最佳的开源完整微服务平台，该平台可追溯到纯Java根：https : //github.com/networknt

如果您想了解性能，可以将自己与现有的基准套件进行比较。 https://github.com/networknt/microservices-framework-benchmark

2. 完全不要使用Kafka :-)）这是个半开玩笑。我的意思是，尽管卡夫卡很棒，但它是另一个以经纪人为中心的系统。我认为未来将出现在无代理消息系统中。您可能会感到惊讶，但是比Kafka系统快得多：-)，当然，您必须降到较低的水平。看编年史。

3. 对于事件存储，我建议使用称为TimescaleDB的高级Postgresql扩展，该扩展专注于大量的高性能时间序列数据处理（事件是时间序列）。当然，CQRS，事件源（重播等功能）是内置在light4j框架中的，该框架使用Postgres作为低存储空间。

4. 对于消息传递，请尝试查看编年史队列，地图，引擎，网络。我的意思是摆脱这种老式的以经纪人为中心的解决方案，而使用微消息系统（嵌入式消息传递系统）。编年史队列实际上比Kafka还要快。但是我同意这不是一站式解决方案，您需要进行一些开发，否则您就可以购买企业版（付费版）。最后，通过消除维护Kafka集群的负担，可以从Chronicle上构建自己的消息传递层而付出的努力。

是的，您可以将Kafka用作事件存储。它工作得很好，特别是在引入Kafka Streams的情况下尤其如此，它提供了一种Kafka本机的方式来将事件处理为可以查询的累积状态。

关于：

重播事件日志的能力，使新订户可以在事件发生后向系统注册。

这可能很棘手。我在这里详细介绍了这一点：https : //stackoverflow.com/a/48482974/741970

是的，Kafka在事件源模型（特别是CQRS）中效果很好，但是您在设置主题的TTL时要格外小心，并始终牢记Kafka不是为此模型设计的，但是我们可以很好地使用它。

我认为您应该看看轴突框架及其对Kafka的支持