RabbitMQ mit EventMachine und Rails

Question

Wir planen derzeit eine Rails 3.2.2 Anwendung, bei der wir RabbitMQ verwenden. Wir möchten verschiedene Arten von Workern (und mehrere Instanzen eines Workers) laufen lassen, um Nachrichten aus verschiedenen Warteschlangen zu verarbeiten. Die Worker sind in Ruby geschrieben und befinden sich im lib-Verzeichnis der Rails-App.

Einige der Worker benötigen das Rails-Framework (aktiver Datensatz, aktives Modell...) und einige nicht. Der erste Worker sollte jede Minute aufgerufen werden, um zu prüfen, ob Aktualisierungen verfügbar sind. Die anderen Worker sollten die Nachrichten aus ihren Warteschlangen verarbeiten, wenn Nachrichten (die vom ersten Worker gesendet werden) vorhanden sind und einige (zeitaufwändige) Dinge damit tun.

So weit, so gut. Mein Problem ist, dass ich nur wenig Erfahrung mit Messaging-Systemen wie RabbitMQ habe und keine Erfahrungen mit der Interaktion von Schienen zwischen ihnen. Also frage ich mich, was die besten Praktiken sind, um die beiden miteinander spielen zu lassen. Hier sind noch einmal meine Anforderungen:

• Rails 3.2.2 Anwendung
• RabbitMQ
• Verschiedene Arten von Arbeitnehmern
• Mehrere Instanzen eines Arbeitnehmers
• Kontrolle der Anzahl der Arbeiter außerhalb der Schienen
• Arbeiter erledigen zeitaufwändige Aufgaben, daher müssen sie asynchron sein
• Nur wenige Arbeitnehmer benötigen den Schienenrahmen. Die anderen sind nur Ruby-Dateien mit einigen Abhängigkeiten wie Net oder File

Ich habe nach einer Lösung gesucht und bin dabei auf zwei Möglichkeiten gestoßen:

Verwendung von amqp mit EventMachine in einem neuen Thema

Natürlich möchte ich nicht, dass meine Rails-App blockiert wird, wenn ein neuer Worker erstellt wird. Der Worker sollte in einem anderen Thread laufen und seine Arbeit asynchron erledigen. Außerdem sollte er keine neue Instanz meiner Rails-Anwendung starten. Sie sollte nur die Dinge anfordern, die der Worker braucht.

In einigen Artikeln heißt es jedoch, dass es einige Probleme mit Passenger gibt. Und eine weitere Tatsache, die mir nicht gefällt, ist, dass wir Webbrick für die Entwicklung verwenden und wir sollten auch dafür Workarounds anbieten. Es wäre möglich, auf einen anderen Webserver wie Thin zu wechseln, aber auch damit habe ich keine Erfahrung.

Verwendung einer Art von Daemonisierung

Vielleicht ist es möglich, Worker als Daemon laufen zu lassen, aber ich weiß nicht, wie viel Overhead das mit sich bringen würde, oder wie ich die Anzahl der Worker kontrollieren kann.

Ich hoffe, jemand kann mir eine gute Lösung dafür empfehlen (und ich hoffe, ich habe mich klar ausgedrückt ;)

Answer 1

Es scheint mir, dass AMQP ein großer Schuss ist, um Ihr Problem zu lösen. Haben Sie versucht, Resque zu verwenden? Die Redis-Datenbank hat einige nette Funktionen (wie Publish/Subscribe und Blocking List Pop), die sie als Message Queue sehr interessant machen, und Resque ist sehr einfach in jeder Rails-App zu verwenden.

Die Worker sind daemonisiert, und Sie entscheiden, welcher Worker Ihres Pools welche Warteschlange abhört, so dass Sie jeden Auftragstyp nach Bedarf skalieren können.

Die Verwendung von EM Reactor innerhalb eines Anfrage/Antwort-Zyklus wird nicht empfohlen, da es zu Konflikten mit einer bestehenden Ereignisschleife kommen kann (z.B. wenn Ihre Anwendung von Thin bedient wird), in jedem Fall müssen Sie ihn speziell für Ihren Webserver konfigurieren, OTOS kann es interessant sein, einen ereignisgesteuerten Warteschlangenkonsumenten zu haben, wenn Ihre Jobs blockierende IO haben und nicht prozessorgebunden sind.

Wenn Sie es trotzdem mit AMQP machen wollen, siehe Starten der Ereignisschleife und Verbindung in Webanwendungen und für Ihren Webserver entsprechend konfigurieren. Oder verwenden Sie Hase zum synchronen Schieben in die Warteschlange (und jeden beliebigen Auftragsverbraucher, den Sie für nützlich halten, wie z. B. Workling)

Answer 2

Wir arbeiten mit einem etwas anderen, aber ähnlichen Technologie-Stack.

Daemon-Kit wird für die Eventmachine-Seite des Systems verwendet... keine Schienen, aber gemeinsame Modelle (mongomapper & mongodb). EM zieht Nachrichten aus den Warteschlangen, und tun, was Logik erforderlich ist (wir haben ruleby in der Mischung, aber wenn-dann-else funktioniert auch).

mulesoft ESB ist unser nach außen gerichteter Nachrichtenempfänger und -sender, der uns beim Umgang mit der HL7/MLLP-Welt hilft. In der Version 1 der Anwendung haben wir jedoch Java-Code in ActiveMQ verwendet, um HL7-Nachrichten zu verwalten.

Die Rails-App zeigt dem Benutzer dann nur noch die Inhalte an, die er sehen kann - wiederum unter Verwendung der gemeinsamen Modelle.