4

ETL ツールを使用してデータのバッチを取得するシステムの設計に取り組んでいます。つまり、1 つまたは複数のテーブルの挿入/更新/削除を行い、後で複数のクライアントによって処理されるようにそれらを JMS トピックに配置します。現在、トピックの各メッセージは単一のレコード I/U/D を表し、バッチの終わりを区切る特別なメッセージがあります。単一のトランザクションでバッチを処理することが重要であるため、特別なトランザクションで区切られた一連のメッセージを持つことは理想的ではありません。メッセージを発行するセッションと受信するセッションの両方が、複数のメッセージ用に設計されている必要があります。バッチ区切りメッセージは厄介な解決策であり (メッセージを受信するたびに、それが最後かどうかを確認する必要があります)、非常にエラーが発生しやすくなります。システムのデバッグと保守が困難です。トピックに関するメッセージの数はすぐに膨大になります (最大で数百万)。

さて、アーキテクチャを改善するための次の自然なステップは、すべてのレコードを単一の JMS メッセージにパックすることだと思います。これにより、メッセージが受信されたときに単一のトランザクションが含まれ、障害を簡単に検出でき、「孤児」がなくなります。トピックに関する記録など。そうすることには利点しかありません。ここに私の質問があります：

  • このような詰め込まれたメッセージを作成する最良の方法は何ですか? 私の選択肢はStreamMessage、ByteMessageまたはObjectMessageです。テキスト メッセージとマップ メッセージは除外しました。最初のメッセージではテキストの解析が必要になり、パフォーマンスが低下するためです。StreamMessageカスタムシリアライゼーションコードを書くには多くの作業が必要になりますが（ByteMessageの場合はさらに悪い）、非常にコンパクトに見えるので、私はちょっと傾いています。ObjectMessage についてよくわかりませんが、どのように機能しますか? これに対するすぐに使えるソリューションはありますか?
  • メッセージごとに許可される最大サイズは? 数百 KB または数 MB のオーダーでしょうか?

考えてくれてありがとう！

ジョバンニ

4

2 に答える 2

2

1 つの大きなメッセージを使用する代わりに、2 つ (またはそれ以上) のキュー、相関 ID、およびメッセージ セレクターを使用できます。

キューイング:

  1. 通知メッセージを「通知キュー」に投稿して、処理を開始する必要があることを示します
  2. 相関 ID を通知メッセージ メッセージ ID に設定して、コマンド メッセージを「コマンド キュー」にポストします (キューの深さが大きくなりすぎる場合は、複数のコマンド キューを使用できます)。
  3. トランザクションをコミットする

処理：

  1. 「通知キュー」から通知メッセージを受信します (例: メッセージ駆動型 Bean を使用)
  2. メッセージセレクターを使用して、「コマンドキュー」から関連するすべてのメッセージを受信して​​処理します
  3. トランザクションをコミットする
于 2013-03-28T08:26:03.520 に答える
1

バイト (ByteMessage など) を使用すると、メモリの使用量が少なくなる可能性があります。

Java オブジェクトを操作する場合、Kryoのような高速でバイト効率の高いシリアライゼーション/デシリアライゼーション ライブラリを使用できます

私たちは喜んでメッセージング システムの本番環境で Kryo を使用していますが、人気のあるGoogle Protocol Buffersなどの代替手段がたくさんあります。

于 2013-03-28T05:41:05.837 に答える