Die Warteschlangen von Rabbit befinden sich im Speicher und sind daher viel schneller als die Implementierung in einer Datenbank. Eine (gute) dedizierte Nachrichtenwarteschlange sollte auch wesentliche Warteschlangenfunktionen wie Drosselung/Flusskontrolle und die Möglichkeit bieten, verschiedene Routing-Algorithmen auszuwählen, um nur einige zu nennen (Rabbit bietet diese und mehr). Abhängig von der Größe Ihres Projekts möchten Sie möglicherweise auch, dass die Message-Passing-Komponente von Ihrer Datenbank getrennt wird, damit bei einer starken Belastung einer Komponente der Betrieb der anderen nicht behindert werden muss.
Zu den von Ihnen erwähnten Problemen:
-
Polling hält die Datenbank ausgelastet und leistungsschwach :Mit Rabbitmq können Produzenten pushen Aktualisierungen an Verbraucher, was weitaus leistungsfähiger ist als Abfragen. Daten werden einfach bei Bedarf an den Verbraucher gesendet, wodurch unnötige Prüfungen entfallen.
-
Sperren der Tabelle -> wieder leistungsschwach: Es gibt keine zu sperrende Tabelle :P
-
Millionen Zeilen von Tasks -> Polling ist wieder leistungsschwach: Wie oben erwähnt, arbeitet Rabbitmq schneller, da es sich im RAM befindet, und bietet Flusskontrolle. Bei Bedarf kann es auch die Festplatte verwenden, um Nachrichten vorübergehend zu speichern, wenn der RAM ausgeht. Nach 2.0 hat Rabbit seine RAM-Nutzung erheblich verbessert. Clustering-Optionen sind ebenfalls verfügbar.
In Bezug auf AMQP würde ich sagen, dass ein wirklich cooles Feature der "Austausch" ist und die Möglichkeit, ihn an andere Börsen weiterzuleiten. Dies gibt Ihnen mehr Flexibilität und ermöglicht es Ihnen, eine Vielzahl von ausgefeilten Routing-Typologien zu erstellen, die sich beim Skalieren als sehr nützlich erweisen können. Ein gutes Beispiel finden Sie unter:
(Quelle:springsource.com)
und:http://blog.springsource.org/2011/04/01/routing-topologies-for-performance-and-scalability-with-rabbitmq/
Schließlich, in Bezug auf Redis, ja, es kann als Nachrichtenbroker verwendet werden und kann gut abschneiden. Rabbitmq verfügt jedoch über mehr Nachrichtenwarteschlangenfunktionen als Redis, da rabbitmq von Grund auf als voll funktionsfähige dedizierte Nachrichtenwarteschlange auf Unternehmensebene entwickelt wurde. Redis hingegen wurde in erster Linie als In-Memory-Key-Value-Store entwickelt (obwohl es jetzt viel mehr als das tut; es wird sogar als Schweizer Taschenmesser bezeichnet). Trotzdem habe ich viele Leute gelesen/gehört, die mit Redis für kleinere Projekte gute Ergebnisse erzielt haben, aber ich habe nicht viel darüber in größeren Anwendungen gehört.
Hier ist ein Beispiel für die Verwendung von Redis in einer Long-Polling-Chat-Implementierung:http://eflorenzano.com/blog/2011/02/16/technology-behind-convore/
