Java 一种可伸缩的事件重构体系结构

我的任务是开发数据转换管道的体系结构。 从本质上讲，数据从一端进入，并在到达目的地之前通过各种内部系统以不同的形式进行路由

主要目标是-

• 容错性。如果其中一个中间系统出现故障，则该消息应可恢复
• 重播/重新排序-消息可以从任何阶段重播，并且应该能够以幂等方式重新创建事件

我有一些定制解决方案要解决

• 实现一个检查点系统，在该系统中，可以在每个检查点的入口点和出口点记录消息，以便我们知道故障发生的位置
• 实现一种恢复机制，该机制可以转到已记录的存储（数据库、日志文件等）并以编程方式重建事件

然而，我觉得这是一个相当标准的问题，有明确的解决方案

因此，我欢迎大家对合适的体系结构、工具/包/模式等有任何想法

谢谢

是显而易见的选择。当然Scala版本更强大，但即使使用Java绑定，您也可以实现很多功能

我认为你们可以按照这个方法使用这个模块。在这种情况下，很容易重播任何事件序列，因为您总是有一个持久的日志

通常情况下，Actor模型使用提供容错性

将为您提供所需的可扩展性

使用Akka持久性和Cassandra（不幸的是，只有Scala）的Akka集群是一个非常棒的例子

一种常见的解决方案是，中心组件（JMS代理）保存挂起消息的事务存储。因为除此之外它什么也不做，所以它可以有很高的正常运行时间（使用故障转移群集可以进一步增加正常运行时间，在这种情况下，它的持久性存储也可能是故障转移群集）

发送JMS消息可以是事务性的，使用消息也可以是事务性的。这些事务可以通过XA事务与数据库事务同步，XA事务尽最大努力实现尽可能精确的一次交付，但这是一个相当繁重的机器

---

在许多情况下（幂等接收器），至少一次传送就足够了。这可以通过使用同步事务发送消息（即，只有在代理确认收到消息后，发送方才能成功），并且只有在处理完消息后才使用消息来实现

如果邮件不能在传输过程中丢失，您还需要重播功能吗？也就是说，您是否需要重播来处理丢失的消息，或者是否存在将系统回滚到以前状态的实际业务原因？将系统回滚到以前状态没有任何用处。它主要是重放丢失的消息，无论它们在哪里丢失。