虽然我之前遇到过Kafka，但我最近才意识到 Kafka 可能被用作（基础）CQRS、eventstore。
Kafka 支持的主要功能之一：
诚然，我并不完全了解 CQRS / 事件源，但这似乎非常接近事件存储应该具备的功能。有趣的是：我真的找不到关于 Kafka 作为事件存储使用的太多信息，所以也许我错过了什么。
那么，Kafka 是否还缺少一些东西才能成为一个好的事件存储？它会起作用吗？使用其生产环境？有兴趣了解见解、链接等。
基本上，系统的状态是基于系统曾经接收过的事务/事件来保存的，而不仅仅是保存当前状态/系统快照，这通常是所做的。 （将其视为会计中的总分类帐：所有交易最终都加起来得出最终状态）。 这可以实现各种酷炫的功能，但只需阅读提供的链接即可了解更多信息。Kafka旨在成为一个消息系统，与事件存储有许多相似之处，但引用它们的介绍：
Kafka集群保留所有已发布的消息-无论是否消费-可配置一段时间。例如，如果保留期设置为两天，则在消息发布后的两天内，它可供消费，之后将被丢弃以释放空间。 Kafka的性能实际上是针对数据大小恒定的，因此保留大量数据并不成问题。
因此，虽然消息可能会被无限期地保留，但预期它们将被删除。这并不意味着您不能将其用作事件存储，但最好使用其他东西。查看EventStoreDB以获取替代方案。
事件源是一种应用程序设计风格，其中状态更改记录为时间排序的记录序列。 Kafka对于非常大的存储日志数据的支持使其成为构建采用此风格的应用程序的出色后端。
使用Kafka进行事件源的一个问题是所需主题的数量。通常，在事件源中，每个实体（例如用户、产品等）都会有一个事件流（主题）。这样，可以通过重新应用流中的所有事件来重构实体的当前状态。每个Kafka主题由一个或多个分区组成，并且每个分区都存储为文件系统上的目录。还将有来自ZooKeeper的压力，因为znode数量增加。
我一直在关注这个问题。但我发现现有的答案不够细致，所以我添加了这个。
据我所知，有两种主要类型的事件溯源系统。
在这种系统中，事件在现实世界中发生并记录为事实。例如，仓库系统用于跟踪产品托盘。基本上没有冲突的事件。即使是错误的，一切都已经发生了。（例如：托盘123456放在卡车A上，但计划放在卡车B上。）然后稍后通过报告机制检查异常情况。Kafka似乎非常适合这种下游事件处理应用程序。
在这种情况下，可以理解为什么Kafka的人们正在将其推广为事件溯源解决方案。因为它与例如点击流中已经使用的方式非常相似。但是，使用术语“事件溯源”（而不是流处理）的人们可能指的是第二种用法...
这种应用程序声明自己的事件是由用户请求通过业务逻辑产生的结果。Kafka在这种情况下不起作用，有两个主要原因。
这种情况需要能够为特定实体加载事件流。这样做在Kafka中是不切实际的。使用每个实体的主题可以允许此操作，但是当可能存在数千或数百万个实体时，这是行不通的。这是由于Kafka / Zookeeper的技术限制造成的。
使用短暂的写入模型的主要原因之一是使业务逻辑更改变得便宜且易于部署。
对于Kafka，建议使用按类型分主题，但这将要求为该类型的每个实体加载事件，以获取单个实体的事件。由于您无法通过日志位置确定哪些事件属于哪个实体，即使使用快照从已知的日志位置开始，如果需要结构更改来支持逻辑更改，则需要处理大量事件。
其次，用户可以创建竞争条件，因为对同一实体进行并发请求。保存冲突事件并在事后解决可能是非常不希望的。因此，重要的是能够防止冲突事件。为了扩展请求负载，通常会使用无状态服务，同时使用条件写入（仅在上一个实体事件为＃x时才写入）。也称为乐观并发。Kafka不支持乐观并发。即使它在主题级别支持它，它也需要一直到实体级别才能有效。为了使用Kafka并防止冲突事件，您需要在应用程序级别使用有状态的序列化编写器（每个“ shard”或Kafka等效项）。这是一个重要的架构要求/限制。
添加于2021/09/29
Kafka旨在解决大规模数据问题。应用程序控制的真相来源是一个小规模、深入的解决方案。有效使用事件源需要制定与业务流程匹配的事件和流。这通常比通常对于大规模消费者有用的细节级别要高得多。考虑一下，如果您的银行对每个银行内部交易过程的每个步骤都有一个条目，那会怎样。在确认到您的账户之前，单笔存款或提款可能会有很多条目。银行需要这种详细级别来处理交易。但对于您来说，它大多是晦涩难懂的银行术语（领域特定语言），无法用于调整您的账户。相反，银行为消费者发布单独的事件。这些是每个完成的交易的粗略摘要。这些摘要事件是消费者在其银行对账单上所知道的“交易”。对于事件溯源，仍然需要进行扩展。策略取决于原因。通常，事件流具有“完成”或“不再有用”的状态。如果事件大小/数量成为问题，则将这些流存档是一个好答案。分片是另一个选择——非常适合区域或租户隔离的场景。在较少隔离的情况下，当流以可以跨越分片边界的方式任意相关联时，分片仍然是移动（按流ID进行分区）。但是，在流之间没有排序保证，这可能会使事件消费者的工作更加困难。例如，消费者可能会在接收描述所涉及帐户的事件之前接收交易事件。第一反应是“只使用时间戳”来排序接收到的事件。但是仍然无法保证完美发生顺序。太多不可控因素。网络故障、时钟漂移、宇宙射线等。理想情况下，设计消费者不需要跨流依赖。拥有临时缺失数据的策略。就像数据的渐进增强一样。如果您确实需要数据不可用而不是不完整，请使用相同的策略。但要将不完整的数据放在单独的区域或标记为不可用，直到填充所有数据为止。您也可以尝试处理每个事件，知道它可能由于缺少先决条件而失败。将失败的事件放入重试队列中，处理下一个事件，并稍后重试失败的事件。但要注意毒消息（事件）。
你能强制Kafka为应用程序控制的真相来源工作吗？如果你足够努力并且集成得足够深入，那么当然可以。但是这是一个好主意吗？不是。
根据评论更新
评论已被删除，但问题大致是：人们用什么来存储事件？
看起来大多数人会在现有数据库的基础上自己实现事件存储。对于非分布式场景，例如内部后端或独立产品，如何创建基于SQL的事件存储是有充分文档支持的。还有一些库可以用于各种不同类型的数据库。也有EventStoreDB专为此目的而构建。
在分布式场景中，我见过几种不同的实现。Jet的Panther项目使用Azure CosmosDB，利用Change Feed功能通知监听器。我听说AWS上类似的实现是使用DynamoDB和其Streams功能来通知监听器。分区键可能应该是流ID，以获得最佳数据分布（以减少过度预配的数量）。然而，在Dynamo中跨流进行完整重放是昂贵的（无论是读取还是成本方面）。因此，这个实现也设置了Dynamo Streams将事件转储到S3中。当新的监听器上线或现有的监听器想要进行完整重放时，它会首先读取S3以进行追赶。
我的当前项目是一个多租户场景，我在Postgres之上自己实现了一个类似的事件存储。像Citus这样的东西似乎适合可扩展性，按租户+流进行分区。
Kafka在分布式场景中仍然非常有用。将每个服务的关键事件暴露给其他服务是一个不容易解决的问题。事件存储通常不是为此而构建的，但这正是Kafka擅长的。每个服务都有自己的内部真相来源（可能是事件、BNF、图形等），然后侦听Kafka以了解“外部”正在发生的事情。服务向Kafka发布公共事件，以通知外界它遇到的有趣事情。
所有现有的答案似乎都相当全面，但是有一个术语问题，我想在我的回答中解决。
如果你看五个不同的地方，似乎会得到五个不同的答案。
然而，如果你看一下 Greg Young 在 2010 年的 论文，它从第 32 页开始很好地概括了这个想法，但它并没有包含最终的定义，所以我敢自己来阐述。
事件溯源是一种持久化状态的方式。与通过状态突变替换一个状态不同，你持久化代表该突变的事件。因此，你可以通过读取所有实体事件并按顺序应用这些状态突变来始终获取实体的当前状态。通过这样做，当前实体状态成为该实体所有事件的左折叠。
任何持久化机制都需要执行两个基本操作：
这里是Greg谈论实体流概念的地方，每个实体都有自己的事件流，由实体ID唯一标识。当你拥有一个能够通过实体ID读取所有实体事件的数据库（读取流），使用事件溯源并不是一个难题。
正如Greg的论文在CQRS的背景下提到事件溯源，他解释了为什么这两个概念很好地结合在一起。虽然你拥有一个充满了一堆实体的原子状态变化的数据库，但跨多个实体的当前状态进行查询是一项艰巨的工作。这个问题可以通过将事务性（事件溯源）存储与报告（查询、读取）存储分离来解决，前者用作真相来源，后者用于跨多个实体查询当前系统状态和报告。查询存储不包含任何事件，它包含多个实体的“投影”状态，根据查询数据的需要组成。它不一定需要包含每个实体的快照，你可以自由选择查询模型的形状和形式，只要你能将事件投影到该模型中即可。
因此，“适当的”事件数据库需要支持我们所谓的“实时订阅”，以向查询模型传递新的（和历史的，如果需要重播）事件来进行投影。Kafka是一种高度可扩展的消息代理，基于追加日志。 Kafka中的消息被生产到主题中，现在一个主题通常包含一个单一的消息类型，以便与模式注册表配合使用。主题可以是像cpu-load这样的东西，我们为许多服务器生成CPU负载的时间序列测量。
Kafka主题可以分区。分区允许您并行地生产和消费消息。消息仅在单个分区内排序，并且通常需要使用可预测的分区键，以便Kafka可以将消息分布在分区之间。
现在，让我们逐一检查：
Version列。对于NoSQL数据库，你可能使用了文档eTag。两者都允许你确保你更新的实体处于你知道的状态，并且在你的操作期间没有被改变。Kafka 不提供任何支持此类状态转换的乐观并发性的东西。将事件折叠到某种状态表示中，并异步地将此状态存储在另一个数据库中，是事件溯源的一个附带功能。我们通常称这些操作为“投影”，因为您可以以许多不同的方式将事件折叠到状态中。这是一个有用的功能，因为您可以随意构建特定于用例的查询模型，并从时间的开始或从某个时间点重新构建它们，因为您可以使用日志中的完整事件历史记录。
然而，这并不是事件溯源的全部内容，因为您可以使用队列完全相同的方式进行操作，没有人会说通过队列传递消息并在消息消费者中更新数据库记录是“事件溯源”。
我认为很多人声称Kafka是事件源系统的良好选择的原因是他们将事件溯源和简单的发布-订阅(可以使用一个炒作词“EDA”，或事件驱动架构)混淆了起来。使用消息代理将事件传播到其他系统组件是一个已经存在几十年的模式。传统消息代理的问题在于消息一旦被消耗就会消失，因此您无法构建像查询模型这样从历史记录中构建出来的东西。另一个问题是，在投影事件时，您希望它们按照产生顺序被消耗，但传统的代理通常旨在支持竞争消费者模式，这不支持有序的消息处理。不要误解，Kafka不支持竞争消费者，它有一个限制即每个分区只能有一个或多个消费者，但不能反过来。Kafka完美地解决了排序问题和历史消息保留问题。因此，您现在可以从通过Kafka推送的事件构建查询模型。但这并不是事件溯源的原始想法所关注的，这正是我们今天所说的EDA。一旦这种分离变得清晰，我们就可以停止看到任何仅追加事件日志的声明成为事件源系统事件存储数据库的良好候选。
你可以使用 Kafka 作为事件存储，但我不建议这样做，尽管它看起来是一个不错的选择：
因此，在做出选择之前，请三思而后行。事件存储作为应用程序层接口（监控和管理）、SQL/NoSQL 存储和 Kafka 作为代理的组合是比让 Kafka 承担两个角色来创建完整的功能解决方案更好的选择。
如果您认真考虑了事件驱动架构中的事件源、CQRS、Sagas 和其他模式，并保持高性能，那么事件存储是一个复杂的服务，需要比 Kafka 更多的功能。
欢迎挑战我的答案！ 您可能不喜欢我对您最喜爱的代理的许多重叠功能所说的话，但是 Kafka 的设计不是作为事件存储，而是作为高性能代理和缓冲器同时处理快速生产者与慢速消费者的情况等。
请查看 eventuate.io 微服务开源框架，了解更多潜在问题：http://eventuate.io/我不会把评论中的新信息融入其中，但同意其中的一些方面。 这次更新更多是关于微服务事件驱动平台的一些建议。 如果您真的关心微服务的稳健设计和最高可能的性能，我将为您提供几个有用的提示。
如果您想了解性能，可以将其与现有基准套件进行比较。 https://github.com/networknt/microservices-framework-benchmark
根本不要使用Kafka :-)) 这是半个玩笑。 我的意思是，虽然 Kafka 很棒，但它仍然是另一个以 Broker 为中心的系统。我认为未来在无 broker 的消息传递系统。您可能会感到惊讶，但有些比 Kafka 更快的系统：）当然，您必须降到更低的级别。看看 Chronicles。
对于事件存储，我推荐卓越的Postgresql扩展名TimescaleDB，其专注于大容量高性能时间序列数据处理（事件属于时间序列）。 当然，CQRS，事件源（重放等功能）内置于 light4j 框架中，后者将 Postgres 作为低级存储。
如果想要进行消息传递，可以考虑使用Chronicle Queue、Map、Engine和Network。我是说，摆脱这种老式的以代理为中心的解决方案，转而使用微型消息系统（嵌入式消息系统）。实际上，Chronicle Queue甚至比Kafka更快。但我同意它不是一个全能的解决方案，您需要进行一些开发，否则您就会购买企业版本（收费版本）。最终，从Chronicle构建自己的消息传递层所需的工作将通过去除维护Kafka集群的负担得到回报。
我认为你应该看一下Axon框架，以及他们对Kafka的支持。
是的，Kafka在事件溯源模型中特别是CQRS方面表现良好，但是在设置主题的TTL时需要小心，并始终记住Kafka并不是为这种模型而设计的，尽管我们可以很好地使用它。