2

私はRabbitMQとPikaを使用するのが初めてなので、答えが明らかな場合はすみません...

いくつかのデータをフィードし、その結果を rabbitmq メッセージ キューに渡します。キューは、elasticsearch にデータを書き込むプロセスによって消費されています。

データは、エラスティック検索にフィードするよりも速く生成されているため、キューが大きくなり、縮小することはほとんどありません。

pika を使用していて、警告が表示されます。

UserWarning: Pika: Write buffer exceeded warning threshold at X bytes and an estimated X frames behind.

これは、Pika が奇妙なエラー メッセージで単純にクラッシュするまで、しばらく続きます。

NameError: global name 'log' is not defined

Pika BlockingConnection オブジェクト (http://pika.github.com/connecting.html#blockingconnection) を使用しています。

これを修正する私の計画は、add_backpressure_callback 関数を使用して、背圧time.sleep(0.5)を適用する必要があるたびに呼び出す関数を作成することです。しかし、これは解決策が単純すぎるように思われ、このような問題を処理するためのより適切な方法が必要です。

キューが消費されるよりも速く入力されるというのは、よくある状況だと思います。キューを遅くする最善の方法について、例やアドバイスを探しています。

ありがとう！

4

1 に答える 1

1

興味深い問題です。ご指摘のとおり、これはおそらく非常に一般的です。スタックオーバーフローに関する別の関連する質問といくつかのポインターを見ました

Pika: 書き込みバッファ超過警告

さらに、elasticsearch のスケールアップを検討したい場合、これはおそらく修正したい根本的なボトルネックです。elasticsearch.org Web サイトをざっと見てみると、

「分散

Elastic Search の主な機能の 1 つは、その分散性です。インデックスはシャードに分割され、各シャードには 0 個以上のレプリカがあります。クラスター内の各データ ノードは 1 つ以上のシャードをホストし、操作を適切なシャードに委任するコーディネーターとして機能します。リバランスとルーティングは自動的にバックグラウンドで行われます。"

（...挿入も分散され、スケーラブルかどうかはわかりませんが）

結局、RabbitMQ はキューを無限に拡大することは想定されていません。また、RabbitMQ 構成でキューごとのプロセスなどを使用するなど、RabbitMQ 自体のスケールアップを検討することもできます。

乾杯！

于 2012-08-17T08:43:34.070 に答える