我正在尝试将EventStore评估为服务器软件内部的可靠排队机制。
MSMQ 作为替代方案失败了,因为它不能支持部分排序,消息“对话”中的有序消息。并且由于它的 4MB 消息大小限制(可以通过部分排序来克服)。SQL Service Broker 确实支持部分排序,但是以编程方式设置和管理是一件麻烦事。
由于 EventStore 的文档确实很少,有 EventStore 经验的人可以提供以下帮助吗?
- EventStore 是否支持事件的事务处理——也就是说,如果处理失败,出队是否可以回滚?
- 在不同的线程、进程或机器中有多个读取器,EventStore 是否强制每个事件被分派(?)到只有一个读取器(一次,可能在事务期间)
- 假设上述情况是可能的,不同“对话”中的事件是否可以按任何顺序同时阅读,而同一对话中的消息可以单独按顺序阅读?
- 我读到 EventStore 基本上是“至少一次”交付。是否有可能使用某些存储提供商来确保“精确一次”交付?
- “毒”事件如何处理?处理期间出错的事件。也许错误本质上是暂时的,可以重试。也许它本质上是永久性的,需要行政干预。
- 如有必要,是否可以手动操作 EventStore 存储?可以在其他读者继续阅读的同时完成吗?
(我读到存储引擎中的事务不是必需的,但我仍然使用事务的语言来表示在 EventStore 级别替换事务的任何内容。如果在从事务切换到任何内容时有关键的功能后果,请评论它们.我不需要马上了解每一个方面,只需要希望能有更多的时间去尝试。)