2

私は、データ変換パイプラインのアーキテクチャを開発する任務を負っています。基本的に、データは一方の端で受信され、宛先に到達する前にさまざまな形式を取得するさまざまな内部システムを経由してルーティングされます。

主な目的は -

  • 耐障害性。中間システムの 1 つがダウンした場合、メッセージは回復可能である必要があります。
  • 再生/再シーケンス - メッセージはどのステージからでも再生でき、べき等な方法でイベントを再作成できる必要があります。

対処すべきカスタム ソリューションがいくつかあります

  • 各チェックポイントの入口と出口の両方でメッセージをログに記録できるチェックポイント システムを実装して、どこで障害が発生したかを把握します。
  • ログに記録されたストレージ (データベース、ログ ファイルなど) に移動し、プログラムでイベントを再構築できる回復メカニズムを実装します。

しかし、これはよく定義された解決策を持つかなり標準的な問題だと感じています。

したがって、適切なアーキテクチャ、参照するツール/パッケージ/パターンなどについての考えを歓迎します.

ありがとう

4

2 に答える 2

1

Akkaは当然の選択です。もちろん、Scala バージョンの方が強力ですが、Java バインディングでも多くのことを実現できます。

CQRS のアプローチに従って、 Akka Persistenceモジュールを使用できると思います。この場合、常に永続的なジャーナルがあるため、イベントのシーケンスを簡単に再生できます。

通常、Actor Model は、 Supervisorを使用してフォールト トレランスを提供します。

Akka Clusteringは、必要なスケーラビリティを提供します。

Akka Persistence と Cassandra で Akka Clustering を使用する本当に素晴らしい例 - https://github.com/boldradius/akka-dddd-template (残念ながら Scala のみ)。

于 2015-04-10T03:55:27.627 に答える
0

一般的なソリューションの 1 つがJMSで、中央コンポーネント (JMS ブローカ) が保留中のメッセージのトランザクション ストアを保持します。それ以外のことは何もしないため、アップタイムが長くなる可能性があります (フェイルオーバー クラスターを使用すると、アップタイムがさらに増加する可能性があります。その場合、永続ストアもフェイルオーバー クラスターになる可能性があります)。

メッセージの消費と同様に、JMS メッセージの送信をトランザクション対応にすることができます。これらのトランザクションは、XA トランザクションを介してデータベース トランザクションと同期できます。XA トランザクションは、可能な限り正確に 1 回の配信に近づけますが、かなり重い機械です。

多くの場合 (冪等受信者)、少なくとも 1 回の配信で十分です。これは、同期トランザクションを使用してメッセージを送信し (つまり、送信者は、ブローカーがメッセージの受信を確認した場合にのみ成功します)、メッセージが処理された後にのみメッセージを消費することによって実現できます。

于 2015-04-10T21:31:28.573 に答える