2

我的任务是开发数据转换管道的架构。从本质上讲，数据来自一端，并通过各种内部系统进行路由，获取不同的形式，然后到达目的地。

主要目标是 -

  • 容错。如果中间系统之一发生故障，该消息应该是可恢复的。
  • 重播/重新排序 - 消息可以从任何阶段重播，并且应该可以以幂等方式重新创建事件。

我有一些自定义解决方案要解决

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

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

所以，我欢迎任何关于合适架构的想法，任何工具/包/模式参考等等。

谢谢

4

2 回答 2

1

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

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

通常，Actor 模型使用监督为您提供容错。

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

将 Akka Clustering 与 Akka Persistence 和 Cassandra 一起使用的非常棒的示例 - https://github.com/boldradius/akka-dddd-template（不幸的是只有 Scala）。

于 2015-04-10T03:55:27.627 回答
0

一种常见的解决方案是JMS，其中一个中央组件（JMS 代理）保存待处理消息的事务存储。因为它除此之外什么都不做，它可以有很长的正常运行时间（正常运行时间可以通过故障转移集群进一步增加，在这种情况下，您很可能它的持久性存储也是一个故障转移集群）。

发送 JMS 消息可以是事务性的，就像使用消息一样。这些事务可以通过 XA-transactions 与数据库事务同步，它尽最大努力尽可能接近精确一次交付，但是是相当笨重的机器。

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

于 2015-04-10T21:31:28.573 回答