it-swarm.com.de

Entwerfen einer skalierbaren Nachrichtenwarteschlangenarchitektur

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

Bisher wird mein ursprüngliches Design auf einem Threaded-Socket-Listener ausgeführt. Um jedoch zu verhindern, dass dieselbe Nachricht zweimal von zwei separaten Verarbeitungsknoten heruntergeladen wird, wird das Indexregister für die Nachrichtenwarteschlange beim Einleiten eines Lesevorgangs gesperrt und nach dem Registrieren des Registers entsperrt 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.

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

Der letzte Weg, den ich mir vorstellen kann, um dieses Problem zu umgehen, besteht darin, dass jeder Nachrichtenwarteschlangenserver (und jeder Thread auf jedem Server) einen bestimmten Versatz hat, wo in der Warteschlange er sucht, aber das könnte Probleme haben, die auf dem Problem basieren Art der Anwendung, insbesondere wenn die Verarbeitung in einer bestimmten Reihenfolge erfolgen muss.

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

24
topherg

Zusamenfassend:

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

Viele Technologien lösen die Nachrichtenwarteschlangenschicht. Sie beinhalten

Ich denke, es liegt außerhalb meines Rahmens, die Nachteile der einzelnen zu diskutieren, nicht zuletzt, weil ich nicht das Fachwissen beanspruche, um dies gut zu machen Husten Verwenden Sie kein Kaninchen Husten .

Lesen Sie die Dokumentation, auch wenn Sie keine dieser Technologien verwenden möchten.

Auf diese Weise lernen Sie Entwurfsmuster kennen, die über ein System möglich sind. Das Lesen von ZeroMQs Dokumentation informiert Sie über viele klassische Architekturen für die Nachrichtenwarteschlange, die sie freundlicherweise implementiert haben. Selbst wenn Sie ZeroMQ nicht verwenden, hilft Ihnen die Kenntnis dieser Muster bei der Bewertung anderer Warteschlangentechnologien, indem Sie fragen, ob Sie dieses Muster dort implementieren können.

Erfahren Sie mehr über das Exchange-Queue-Modell von RabbitMQ/AMQP. Das Routing könnte für Sie in Frage kommen - dies wird von Redis PUBSUB unterstützt, aber ich kann mich nicht erinnern, von ZeroMQ unterstützt worden zu sein - und Fanouts werden von meinem Shop seit einiger Zeit verwendet, obwohl sie in einer Memcached-Umfrage (yuck!) 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 mit geringem Datenverlust schnell wiederherstellen können. Wir mussten nicht darüber nachdenken Skalierungsprobleme wie bei Twitter oder Tumblr sind aufgetreten, sodass wir nicht über das Durchsatzvolumen nachdenken mussten. Wenn Sie jedoch ein SLA ähnlich meinem implementieren), werden Ihnen folgende Überlegungen in den Sinn kommen:

  • funktionieren die Client-Bibliotheken -? 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-Handelsladen arbeiten, sind dies natürlich Ihre geringeren Bedenken. Sie sind eher bereit, Entwicklungszeit in eine clientseitige Bibliothek zu investieren, um am Ende einen höheren Durchsatz zu erzielen. Aber ich schreibe dies mehr, um Sie zu warnen, dass diese Technologien aufgrund ihrer Leistung und nicht aufgrund ihrer sofort einsatzbereiten Funktionalität auf den Markt kommen. Wenn Sie ein Web-Startup sind, interessieren Sie sich weit mehr für Letzteres als für Ersteres und dementsprechend für etwas wie Redis, das für eine einfache Bedienung bei guter Leistung optimiert ist als das Schwierigkeit der Verwendung bei großer Leistung, ist wahrscheinlich eine bessere Wahl als RabbitMQ. (Ich mag RabbitMQ nicht).

15
djechlin