2009-05-17 6 views
3

1秒あたり40,000メッセージを処理できるシステムを構築する必要があります。 ソフトウェアまたはハードウェアに障害が発生した場合にメッセージが失われることはありません。1秒あたり40,000メッセージを処理できるシステムのパターンと技術

各メッセージのサイズは約2-4KBです。

メッセージの処理は、メッセージの検証、単純な算術計算、結果のデータベースへの保存、および(時には)他のシステムへの通知の送信で構成されます。

好ましいソフトウェア技術は.Netです。

このようなタスクには、どのようなソフトウェアおよびハードウェアパターンが最適ですか?

どのくらいのハードウェアが必要ですか?

+0

2〜4kbの40.000メッセージは安定したパターンまたはバーストですか? –

+0

約40分のメッセージ/秒のピークは約30分続きます。メッセージの量はかなり少なくなりますが、処理はリアルタイムで実行する必要があります。 –

答えて

9
  1. メッセージキューイング。プロセスフローは、その主要なターゲットのように聞こえます。
  2. クラスタリング/負荷分散。
  3. 私がやるだろう

あなたのコードを合理まず最初は、通知をキューです。次に、値を返す必要のないすべてのデータベース書き込みをキューに入れます。それからスケールアウトを見てみましょう。

その他の考慮点: *必要以上に多くの場面で動作するような大きなフレームワークは避けてください。 *可能な限り、キャッシュ変数と静的変数を使用してください。

40,000メッセージ/秒が可能ですが、IOをミックスに追加すると、メモリが大量にある超高速ハードウェアでも予測できなくなります。可能な限り帯域外処理を行うようにしてください。それが失敗するところでは、(マルチコアまたはマルチプロセスマシン上で)複数のスレッドを実行し、必要に応じてクラスタ内の複数のサーバを調べることができるかどうかを確認してください。

編集:

私はこのようなシナリオでは、負荷テストのメリットを十分に強調することはできません。簡単なプロトタイプと負荷テストを行います。希望の結果が得られるまでプロトタイプを再調整してください。プロトタイプに基づいて最終的なソリューションを設計します。望ましいパフォーマンスレベルをテストするまでは、ソリューションを推測しています。

2

最初に行うことは、要件が意味するものを正確に見つけようとすることです。 「ソフトウェアやハードウェアに障害が発生してもメッセージは失われません」は不可能です。 5,000の異なる場所にある5000種類のディスクにメッセージを書き込むとします。 これらのディスクのすべてに同時に障害が発生すると、必然的にデータが失われます。

同様に、の場合は、にはどこかにバグがあり、データが失われる可能性があります。システム内のどこにでもバグがあっても常に動作するソリューションを設計できるという考えは不可能です。

本当に必要な冗長性と信頼性のレベルを決めたら、より手軽に対応できます。また、そのレベルの信頼性を達成したという自信を持っている方が簡単になります。

3

4k * 40.000/s = 160MB/sはかなりの帯域幅です。

メッセージなし損失の要件は、すべての通信相手が双方向の送受信を行うため、おそらく両方向でその帯域幅を持つ必要があります。

この数字を、ネットワークカードの平均スループットまたはハードディスクの書き込み速度で除算すると、これは高度に並列かつ冗長なシステムになることがわかります。

必要なハードウェアの見積もりを得るには、DB操作と各メッセージの計算にベンチマークを行い、40.000(または1日に35億)を乗算する必要もあります。

私は.NETの要件があなたの問題の中で最も少なくなると思います。

2

Microsoftスタックを使用している場合、MSMQ(Microsoft Message Queuing)を使用する必要があります。信頼性やパフォーマンスのために構成できるオプションがたくさんあります。 MSMQ FAQをご覧ください。

ボトルネックは処理ではなくディスクI/Oです。できるだけ多くのRAMを持って、できるだけ多くのことを行う。

MSMQはメモリ内のキューを管理しますが、ハードウェアが故障するとメモリ内のすべてが失われます。メッセージを回復可能とマークすると、ディスクに書き込まれますが、簡単にボトルネックに陥る可能性があります。

1

私の助言は、すでに似たようなシステムを構築している人を雇うことです。彼らはアーキテクチャと開発ツールを選択しましょう。このような高い取引レートを扱うには、専門家のハードウェアおよびソフトウェアの知識が必要であり、そのような知識を得る最も安価な方法は、そのためにお金を払うことです。

2

MSMQを使用してメッセージを回復可能なものとしてマークする場合は、確実にメッセージをキューから取り出してください。可能であれば、フェールセーフであることを確認してください。何か問題が発生した場合、メッセージが急速に蓄積され、ドライブが1秒未満でいっぱいになり、システムがクラッシュする可能性があります。その後、すべての受信メッセージが失われます。私が知っていることを私に尋ねる

MSMQにメッセージをC:以外のドライブに保存する方法を決して考えなかったのですが、それが必要になります。少なくともそのシステムは、問題があるとあなたに伝えることができます。

上記のように、ディスクとデータベースはボトルネックになります。私はMSMQがそのボリュームを扱うことができると思います、特にトリガーなどを避けるならば。

IBMのMQがおそらくタスクに適しています。

関連する問題