3

ツイストを使用して、インターネットに接続されたセンサーからメッセージを取得し、データベースに保存しています。
これらのプロセスに干渉することなくこれらのメッセージをチェックしたいのは、すべてのメッセージをdbのいくつかの基本値と比較する必要があるためです。一致するものがある場合は、これに対するアラートをトリガーする必要があります。アイデアはプロセスをブロックしません...

私のアイデアは、チェックしてアラートを出す新しいプロセスを作成することですが、最初のプロセスがメッセージを保存した後、必要に応じてチェックしてアラートを出すために、メッセージを新しいプロセスに送信する必要があります。

これにはIPCが必要で、ZeroMQを使用することを考えていましたが、IPCを使用するアプローチもあります。ZeroMQを使用すると思いますが、おそらくそれは自滅するでしょう...

私のアプローチについてどう思いますか？多分私は完全に間違っていますか？

アドバイスは大歓迎です。ありがとう

PD：このプロセスは専用サーバーで実行され、1時間あたり6000メッセージ/時間の負荷が予想されます。

4

2 に答える 2

3

これらのアプローチはすべて可能です。あなたのアプリケーションの正確な輪郭がわからないので、私は抽象的にしか話すことができません。

すでに動作しているアプリケーションがあるが、スローするメッセージの数を処理するのに十分な速度ではない場合は、ボトルネックを特定します。ホールドアップの2つの考えられる原因は、DBアクセスまたはアラートトリガーです。これらのいずれかがおそらく同期IO操作であるためです。

これにどのように対処するかは、ワークロードによって異なります。

  1. メッセージレートが高く一定である場合は、データベースがこのレートを処理できることを確認する必要があります。DBがそれを処理できない場合、ノンブロッキングメッセージパッシングの量は役に立ちません！この順序で：
    1. データベースを調整してみてください。
    2. より多くのメモリを備えたより大きなコンプにデータベースを配置してみてください。
    3. データベースを複数のマシンにシャーディングして、ワークロードを分散してみてください。dbがメッセージレートを処理できることがわかったら、他の形式の並列処理を使用して他のボトルネックに対処できます。
  2. メッセージレートがバースト性の場合は、キューイングを使用してバーストを処理できます。この順序で：
    1. メッセージプロセッサのクラスタの前にロードバランサを配置します。このバランサーが行う必要があるのは、チェックアンドアラート処理のためにセンサーメッセージをさまざまなマシンに再配布することだけです。このアプローチの利点は、既存のアプリケーションを変更する必要がなく、より多くのマシンで実行するだけで済むことです。これは、ロードバランサーが応答を待つ必要がなく、メッセージを転送するだけの場合に最適に機能します。
    2. 通信ニーズがより複雑または双方向である場合は、メッセージプロセッサ、アラート送信者、およびデータベースチェッカー間の通信層としてメッセージバス（ZeroMQなど）を使用できます。アイデアは、バスを介して非ブロッキング通信を発生させ、バス上の各ノードに1つのことだけを実行させることによって、並列処理を増やすことです。次に、メッセージ処理の各段階にかかる時間に応じて、ノードタイプの比率を変更できます。（つまり、メッセージ処理プロセス全体でキューの深さを等しくします。）
于 2013-02-08T00:15:00.913 に答える
1

メッセージを受け取ったら、次の2つのことを行います。

  • アラートをトリガーする必要があるかどうかを確認します（おそらく、必要に応じてアラートを送信します）
  • データベースに挿入します

メッセージキュー、複数のプロセス、IPC、またはそれらのいずれも必要ありません。例えば：

def messageReceived(self, message):
    self.checkForAlerts(message).addCallbacks(self.maybeAlert, log.err)
    self.saveMessageToDatabase(message).addErrback(log.err)
于 2013-02-07T22:51:28.587 に答える