cqrs - EventStore 事件的部分排序和其他功能

Question

我正在尝试评估 EventStore就像服务器软件内部的可靠排队机制一样。

MSMQ 作为替代方案失败了，因为它不能支持部分排序​​，消息“对话”中的有序消息。并且由于它的 4MB 消息大小限制(可以通过部分排序来克服)。 SQL Service Broker 确实支持部分排序​​，但是以编程方式设置和管理是一件麻烦事。

由于 EventStore 的文档确实很少，有 EventStore 经验的人可以提供以下帮助吗？

EventStore 是否支持事件的事务处理——也就是说，
如果处理失败，可以回滚出队吗？

在各种线程、进程或机器中使用多个阅读器，
EventStore 是否强制将每个事件(？)分派(dispatch)给一个
阅读器(一次，也许在交易期间)

假设上述情况是可能的，不同“对话”上的事件是否可以
以任意顺序同时阅读，而同一对话中的消息被
单独阅读并按顺序阅读？

我读到 EventStore 基本上是“至少一次”交付。是吗
可能，使用某些存储提供程序，以确保“恰好一次”
交货？

“毒”事件如何处理？处理期间出错的事件。也许
错误本质上是暂时的，可以重试。也许它本质上是永久的，并且
需要行政干预。

如有必要，是否可以手动操作 EventStore 存储？它可以
在其他读者继续阅读的同时完成？

(我读到存储引擎中的事务不是必需的，但我仍然使用事务的语言来表示在 EventStore 级别替换事务的任何内容。如果在从事务切换到任何内容时有关键的功能后果，请评论它们.我不需要马上了解每一个方面，只需要希望能有更多的时间去尝试。)

Answer 1

虽然 EventStore 可能被用来构建一个完整的队列，但它的设计从未考虑到这一点。这意味着在构建库时有很多固执己见的决定与您的问题所提出的要求背道而驰。

例如，消息传递系统并不真正支持精确一次传递的概念。上面提到的其他事情，比如有毒消息，并不是真正的问题，因为 EventStore 没有以这种方式连接到消息管道中。

您尝试解决的问题似乎不是 EventStore 可以帮助您的问题。因此，我建议评估一个成熟的消息队列，例如 RabbitMQ。

另外，您的邮件中有哪些内容使它们大于 4MB？如果您正在推送文件或大型二进制流，为什么不将它们推送到某种高度可用的“全局”存储(如 Amazon S3)，然后在消息中获得指向这些内容的指针？