1

データ ストリームがあります。基本的には、毎分 30 ～ 50 のレコードが追加される SQL テーブルです。リアルタイムに近い速度で処理する必要があります（レコードがデータベースに表示されてから約 10 分で処理されるはずです）。ここでは、ワークフローのようなソリューションを使用して、すべてのレコードを簡単に処理できるようにしたいと考えています。高可用性を実現するには、このソリューションが必要です。システムは別のハードウェア ノードで動作し、ノードの 1 つがダウンした場合にフォールト トレラントである必要があります。基本的に何が起こるかは次のとおりです。

  • 新しいレコードがデータベースに追加されます
  • ワークフローはそれを処理し始めます
  • その処理の結果としていくつかの処理を行います (電子メールの送信、データベースへの挿入など)。
  • フレームワークは、レコードが処理されたことを記憶する必要があります

もう 1 つの要件は、レコードの 1 つの処理中にエラーが発生した場合、フレームワークが他のレコードの処理を停止してはならないということです。この特定のレコードには再処理が必要であることを覚えておく必要があります。

twitter-storm がこれと似たようなことをすると聞いたことがありますが、ここで使用するのはやり過ぎではありませんか? 私が理解しているように、その主な目的は、ここではまったく必要のない膨大な量のデータを同時に処理することです。

4

2 に答える 2

1

Storm は永続化を行わないことに注意してください。したがって、データをストリームとして処理し、その最後 (または途中、最初など) で永続化を行います。基本的に、トポロジのどこかでボルトがそれを書き出します)。

Storm は、フォールト トレランスと処理の保証に関する問題を解決します。しかし、30 ～ 50 のタプル (Storm データの抽象化) では、実際に使用するのは「やり過ぎ」になる可能性があります。しかし、問題は、Storm が持っているデータ処理の保証がまだある独自のシステムをいかに簡単に作成できるかということです(たとえば、システム内のノードがダウンしたが、一部のデータを処理している最中だった場合、どうなるかということです)。そのデータ？）トポロジーのセットアップと実行は非常に簡単です。Storm が使用する抽象化 (ストリーム、タプル、ボルト、およびスパウト) を扱うのはまったく難しくありません。まだご覧になっていない場合は、この技術講演をご覧になることをお勧めします: http://www.youtube.com/watch?v=biKMS3HILJ4

于 2013-01-15T20:33:09.807 に答える
1

Apache Camelと を使用して、完璧にスケーラブルなソリューションを構築できますActiveMQ。障害のあるノードは例外をスローし、未処理のメッセージをキューに送り返してAMQ後で処理することができます (おそらく他のノードで)。

于 2013-01-15T13:56:26.900 に答える