1

結果を受け取ってRabbitMQメッセージキューに投稿するセロリタスクがたくさんあります。投稿される結果は非常に大きくなる可能性があります (最大で数メガ)。RabbitMQ メッセージに大量のデータを入れることが良いアイデアかどうかについては意見が分かれていますが、私は他の状況でこの作業を見てきました.メモリが制御されている限り、うまくいくようです.

しかし、私の現在の一連のタスクでは、うさぎは大きすぎると思われるメッセージをドロップしているようです。私はそれをかなり単純なテストケースに減らしました：

#!/usr/bin/env python
import string
import random
import pika
import os
qname='examplequeue'
connection = pika.BlockingConnection(pika.ConnectionParameters(
            host='mq.example.com'))
channel = connection.channel()

channel.queue_declare(queue=qname,durable=True)

N=100000
body = ''.join(random.choice(string.ascii_uppercase) for x in range(N))

promise = channel.basic_publish(exchange='', routing_key=qname, body=body, mandatory=0, immediate=0, properties=pika.BasicProperties(content_type="text/plain",delivery_mode=2))

print " [x] Sent 'Hello World!'"
connection.close()

3 ノードの RabbitMQ クラスターと、mq.example.com各ノードへのラウンド ロビンがあります。クライアントは Ubuntu 12.04 で Pika 0.9.5 を使用しており、RabbitMQ クラスターは Erlang R14B04 で RabbitMQ 2.8.7 を実行しています。

このスクリプトを実行すると、print ステートメントが出力され、例外が発生することなく終了します。このメッセージは RabbitMQ には表示されません。

に変更Nする10000と、期待どおりに動作します。

なんで？

4

2 に答える 2

2

RabbitMq の tcp-backpressure メカニズムに問題があると思います。http://www.rabbitmq.com/memory.htmlについて読むことができます。この問題を解決するには、次の 2 つの方法があります。

  1. tcp-callback を追加し、rabbit からのすべての tcp-call を再接続させます
  2. ウサギに送信する前にメッセージを圧縮してください。ウサギへのプッシュが容易になります。
def compress(s):
     return binascii.hexlify(zlib.compress(s))

def decompress(s):
    return zlib.decompress(binascii.unhexlify(s))
于 2012-11-17T11:04:28.420 に答える