【问题标题】：Is Event Sourcing applicable for batch inputs?事件溯源是否适用于批量输入？
【发布时间】：2017-12-12 07:21:45
【问题描述】：
我有一个用例，应用程序的输入来自成批的 XML 文件。例如，每晚一批银行交易。我正在尝试查看是否可以使用事件溯源来创建事件日志。根据我目前阅读的内容，这些示例似乎是基于用户驱动的输入（点击流、来自用户界面的更新等）。使用分布式日志机制（如 Kafka）进行事件溯源是否是基于批处理/文件的输入的有效方法？
以下是我想采取的方法：
- 在文件/xml 中以批处理形式接受输入
- 在内存中运行一些基本验证。
- 将批量输入转化为一系列事件
- 将事件日志写入 Kafka 主题。
- 使用事件日志将数据存储到数据库中，发送事件
到搜索引擎，更新缓存，运行 Spark 作业进行聚合
等等，
- 对其他传入批次重复该过程。
如果这种方法效率不高，还有哪些其他选项可用于分布式处理此类输入？
【问题讨论】：
标签：
apache-kafka
distributed-computing
microservices
event-sourcing
【解决方案1】：
您的输入是否来自看起来像事件存储的东西？ IE。一个数据库，充当不可变的事实来源，仅附加事件。
如果是这样，您就有了使用事件溯源以及 CQRS 的基础。 （它们不是一回事）
您必须意识到，所谓的写入端/命令端...已经为您完成了。
带有事务的传入批次 XML 文件...每个事务已经是一个事件。听起来您不需要将这些转换为事件，然后将它们放入 Kafka。您可以将这些映射到可以放入 Kafka 的内容，然后主题的所有订阅者都可以做相应的事情。
实际上，您将实现事件溯源 + CQRS 的读取端。
实际上，除非您要在写入端（生成 xml 文件的位置/接收用户输入的位置）做事... 我不会过于担心与 DDD 和 CQRS 相关的事件溯源的微妙之处。我会简单地将您正在做的事情视为将数据分发到多个服务的一种方式。
并确保考虑缓存、搜索引擎等仅在您获得这些 XML 文件时才会更新。
【解决方案2】：
如果这些 xml 文件中的每个单独事件都有一个时间戳，那么您可以将 Kafka 的输出视为迟到的事件流。 Kafka 允许您将这些消息的事件时间设置为事件的时间戳，而不是它被摄取到 Kafka 的时间。这样，任何下游处理应用程序（如 Kafka Streams）都可以将事件放入正确的时间上下文中，并聚合到适当的时间窗口或会话窗口中，甚至加入其他实时输入