RabbitMQ auf EC2 - Herausforderungen bei der Leistung

Question

Welche Leistung kann RabbitMQ auf EC2 erwarten? Ich würde es begrüßen, wenn Sie Ihre Erfahrungen mit uns teilen würden.

Ich versuche, einige Leistungstest von RabbitMQ auf aws EC2 zu tun. Ich habe 3 separate EC2-Instanz für RabbitMQ, Publisher und Verbraucher/Arbeiter laufen.

Das Szenario, das ich habe, ist, dass Publisher JSON-String (ca. 165-200 Byte) an Austausch-Typ direkt mit dauerhaften Satz auf true und binden Warteschlange mit dauerhaften Satz auf true (d.h. beide im persistenten Modus) schiebt. Verbraucher/Arbeiter läuft auf separaten Box - hält ziehen Nachrichten. (Es wird erwartet, dass diese Nachrichten beim Worker in MongoDB persistiert werden und der Publisher durch einen Restful-Service mit REST easy ersetzt wird)

Der Einfachheit halber habe ich dieses Szenario mit dem Multicast-Beispielcode simuliert. Ich habe den Multicast-Code in zwei separate Java-Dateien aufgeteilt, nämlich "Producer" und "Worker", die jeweils auf einer separaten Box laufen. Ich habe "c1.mediam" EC2 mit Ubuntu Server v11.4 32 bit für die Ausführung von Producer und Consumer und "m1.large" mit Ubuntu Server v11.4 64 bit für RabbitMQ verwendet.

Ich bin in der Lage, einen Durchsatz von 3-5k Nachrichten pro Sekunde zu erreichen, d.h. die Push-Rate der Studiennachrichten auf 5K zu beschränken (dies stimmt überein mit http://www.rabbitmq.com/faq.html#performance-latency )

Wenn ich die Push-Rate auf 10-12k Nachrichten pro Sekunde erhöhe. Die Fähigkeit des Verbrauchers, Nachrichten zu konsumieren, sinkt auf 1-2k Nachrichten pro Sekunde und es entsteht ein Rückstau (oft geht es auch unter 800 Nachrichten pro Sekunde).

In Bezug auf das obige Szenario habe ich folgende Fragen und würde mich über Gedanken/Vorschläge zur Verbesserung des Durchsatzes der Verbraucher freuen. (HINWEIS: Alle Nachrichten in meinem Szenario sind voraussichtlich von ähnlichem Typ, so dass keine Möglichkeit besteht, sie für das Routing zu gruppieren, so dass eine Art Lastausgleich erforderlich ist)

1) Diese Leistung wird mit einem rabbitMQ Server, einem Exchange und einer Queue beobachtet. Alles weitere kann konfiguriert und fein abgestimmt werden, um den Durchsatz auf mehr als 5k im persistenten Modus zu verbessern.

2) Ich verstehe, dass das Clustering eine weitere Option sein könnte. Allerdings muss ich den Cluster auf der Grundlage der eingehenden Last festlegen, und ich kann keine Nachrichtengruppierung/Identität erhalten, um das Routing zu definieren (da erwartet wird, dass die Nachrichten nur eine Protokollbeschreibung sind). Kann ich Clustering nach der Lastausgleichsoption für Worker/Consumer haben?

3) Von mir wird erwartet, dass ich mehrere hunderttausend Anfragen pro Sekunde bearbeite. Ich würde es begrüßen, wenn Sie Ihre Erfahrungen und Ihren Ansatz zur Erreichung dieses Ziels mit mir teilen würden.

Answer 1

Welche Art von Speicher verwenden Sie für die EC2-Instanzen? EBS-Speicher ist zuverlässiger, aber manchmal hat er sehr geringer Durchsatz (insbesondere bei kleinen EBS-Volumes, d.h. <100 GB). Der Instance-Speicher hingegen hat eine viel bessere IO-Leistung (zumindest unserer Erfahrung nach), kann aber nur so lange "leben", wie die Instanz in Betrieb ist. Ein großer Unterschied ist auch der Instance-Typ, den Sie verwenden. m1.small und c1.medium haben beide eine moderate IO-Leistung (http://aws.amazon.com/ec2/instance-types/).

Wir betreiben RabbitMQ in EC2 mit Persistenz für alle Nachrichten. Wir verwenden nur m1.large-Instanzen (64bit mit hoher IO-Leistung). Wir begannen mit EBS-Storage und wechselten dann zu Instance-Store, um zu sehen, ob es eine Verbesserung gibt. Und Instance-Store-Instanzen sind in Bezug auf den IO-Durchsatz schneller. Der Nachteil ist jedoch, dass alle persistierten Nachrichten zusammen mit der Beendigung/dem Ausfall der Instanz verloren gehen (obwohl wir bis jetzt noch nie einen Ausfall erlebt haben). In unserem Szenario brauchen wir keinen so großen Durchsatz, aber es ist uns sehr wichtig, dass unsere Nachrichten verloren gehen :-)

Abschließend könnten Sie versuchen, zu einer Instanzspeichereinrichtung zu wechseln, um zu sehen, wie das funktioniert und ob es eine Verbesserung gibt. Und wenn das viel besser funktioniert, dann denke ich http://www.rabbitmq.com/pacemaker.html ist eine Lösung zur Überwindung des Scheiterns. Zumindest ist das die Richtung, in die wir uns bewegen.

Prost

Answer 2

Haben Sie erwogen, mehrere Verbraucher hinzuzufügen? Dies ist einer der Hauptvorteile einer lose gekoppelten Bus-/Nachrichtenarchitektur im Vergleich zu einer streng gekoppelten Architektur. Es könnte auch helfen, die Notwendigkeit des Nachrichtenvolumens zu verstehen. Handelt es sich um einen Benchmark, um zu sehen, was Sie tun können, oder ist dies an einen tatsächlichen Anwendungsbedarf gebunden?

Answer 3

Hunderte von kHz ist sehr, sehr hoch: Wenn RabbitMQ das überhaupt kann, dann geht es um die Partitionierung über geclusterte Knoten. Diese Schriftsteller stellte fest, dass ihre EC2-Instanzen höchstens 100K Pakete/Sekunde verarbeiten können, so dass ein höherer Nachrichtendurchsatz über eine einzelne Instanz nicht möglich ist.

Sie könnten nachforschen Kafka , das von LinkedIn für ein ähnliches Modell mit einem riesigen Feuerschlauch geschrieben wurde. Es verlagert einen Teil der Komplexität auf die Verbraucher, um eine echte Dezentralisierung und einen geringeren Nachrichten-Overhead zu ermöglichen.