Entwerfen einer skalierbaren Nachrichtenwarteschlangenarchitektur

Ich habe vor kurzem angefangen, die Nuancen der skalierbaren und Enterprise-Computerarchitektur zu erlernen, und eine der zentralen Komponenten ist eine Messaging-Warteschlange. Um so viel wie möglich von jedem Programmierparadigma zu lernen, versuche ich, eine eigene Version eines Messaging-Warteschlangendienstes zu implementieren.

Bisher läuft mein anfängliches Design auf einem Threaded-Socket-Listener, aber um zu verhindern, dass dieselbe Nachricht zweimal von zwei separaten Verarbeitungsknoten heruntergeladen wird, wird das Indexregister der Nachrichtenwarteschlange gesperrt, wenn ein Lesevorgang eingeleitet wird, und entsperrt, nachdem das Register freigegeben wurde aktualisiert. Dies macht ein Threading überflüssig und bedeutet, dass es eine Obergrenze für die Größe eines skalierbaren Systems gibt, die auf der Verarbeitungsgeschwindigkeit des Servers basiert, auf dem der Messaging-Warteschlangendienst ausgeführt wird.

Die Möglichkeit, dies zu umgehen, besteht darin, den Nachrichtenwarteschlangendienst auf mehreren Servern auszuführen. Dies erhöht jedoch die Wahrscheinlichkeit, dass dieselbe Nachricht zweimal heruntergeladen wird. Die einzige Möglichkeit, solche Probleme zu vermeiden, besteht darin, einen Widerrufsrückruf einzuschließen, der (nachdem die Server oder sogar die Threads auf einem einzelnen Server ihre Informationen synchronisiert und eine solche Neuausgabe festgestellt haben) den Verarbeitungsknoten anweist, seine Ausführung zu stoppen aktuellen Job und fragen Sie die Nachrichtenwarteschlange erneut nach der nächsten Nachricht ab. Es würde jedoch eine Obergrenze geben, an der der größte Teil des gesendeten Datenverkehrs aus Synchronisierungen und Widerrufsrückrufen besteht. Dies führt zu einem Engpass und verlangsamt die Verarbeitung von Informationen, sodass a Viele der Verarbeitungsknoten würden Nulloperationen ausführen und Zeit verschwenden.

Die letzte Möglichkeit, um dieses Problem zu umgehen, besteht darin, dass jeder Message Queue-Server (und jeder Thread auf jedem Server) einen bestimmten Versatz hat, um festzustellen, wo in der Warteschlange er sich befindet Art der Anwendung, insbesondere wenn die Verarbeitung in einer bestimmten Reihenfolge erfolgen muss.

Gibt es also Entwürfe für Nachrichtenwarteschlangenarchitekturen, die mir zeigen könnten, wie vorhandene Nachrichtenwarteschlangendienste für Unternehmen diese Probleme vermeiden?

Zusamenfassend:

Das ist ein schweres Problem. Das Rad nicht neu erfinden.

Es gibt viele Technologien, die die Nachrichtenwarteschlangenschicht lösen. Sie beinhalten

• ZeroMQ
• RabbitMQ
• Apache Kafka
• Redis, mit BLPOP oder PUBSUB (ich habe hier gefragt, wie das geht ).
• Andere AMQP-Implementierungen neben RabbitMQ

Ich denke, es liegt nicht im Rahmen meiner Möglichkeiten, die Nachteile jedes einzelnen zu diskutieren, nicht zuletzt, weil ich nicht wirklich das Fachwissen beanspruche, um diesen Husten gut zu machen nicht Kaninchen verwenden Husten .

Auch wenn Sie keine dieser Technologien verwenden möchten, lesen Sie deren Dokumentationen.

Auf diese Weise lernen Sie Entwurfsmuster kennen, die über ein System möglich sind. Wenn Sie die Dokumentation zu ZeroMQ lesen, werden Sie über viele klassische Message Queuing-Architekturen unterrichtet, die sie liebevoll implementiert haben. Selbst wenn Sie ZeroMQ nicht verwenden, können Sie anhand dieser Muster andere Warteschlangentechnologien bewerten, indem Sie fragen, ob Sie dieses Muster dort implementieren können.

Erfahren Sie mehr über das Exchange-Queue-Modell von RabbitMQ / AMQP. Routing könnte für Sie in Frage kommen - dies wird von Redis PUBSUB unterstützt, aber ich kann mich nicht daran erinnern, dass es von ZeroMQ unterstützt wird - und Fanouts werden von meinem Shop verwendet, obwohl sie über eine Memcached-Umfrage (yuck!) Seit einiger Zeit schlecht implementiert wurden .

Wie wähle ich eine aus?

Ich arbeite bei einem Startup, dessen SLA typisch für eine Web-App ist - einige Ausfälle sind in Ordnung, solange wir den Dienst ohne Datenverlust schnell wiederherstellen können. Wir mussten nicht über Skalierungsprobleme nachdenken, wie dies bei Twitter oder Tumblr der Fall ist, und mussten daher auch nicht über das Durchsatzvolumen nachdenken. Wenn Sie jedoch eine SLA ähnlich der meinen implementieren, werden Ihnen folgende Überlegungen in den Sinn kommen:

• Sie die Client - Bibliotheken tatsächlich funktionieren ? Ist es einfach, eine Verbindung in ihnen aufrechtzuerhalten? (ZeroMQ, Redis: ja. RabbitMQ: nein).
• ist die Überwachung und Verwaltung von einer Serverkonsole aus einfach? (Redis: ja, RabbitMQ: ja, ZeroMQ: nicht, dass ich mich erinnere, aber wir haben es nicht so lange benutzt)
• Unterstützen Clients interne Warteschlangen, sodass bei kurzen Ausfällen nur ein geringer Datenverlust auftritt? (ZeroMQ, Redis: ja. RabbitMQ: nein.)

Wenn Sie beispielsweise für einen Hochfrequenz-Trading-Shop arbeiten, sind dies natürlich Ihre weniger wichtigen Anliegen. Sie sind eher bereit, Entwicklungszeit in eine clientseitige Bibliothek zu investieren, um letztendlich einen höheren Durchsatz zu erzielen. Aber ich schreibe dies eher, um Sie zu warnen, dass diese Technologien aufgrund ihrer Leistung und nicht aufgrund ihrer sofort einsatzbereiten Funktionalität zur Vermarktung neigen. Wenn Sie ein Web-Startup sind , interessieren Sie sich viel mehr für Letzteres als für Ersteres, und dementsprechend ist etwas wie Redis, das für Benutzerfreundlichkeit bei guter Leistung als Schwierigkeit bei guter Leistung optimiert ist, wahrscheinlich ein bessere Wahl als RabbitMQ. (Ich mag RabbitMQ wirklich nicht).