Queen MQ stellt ACID-Nachrichtenbroker mit Queue pro Entität und starker Konsistenz vor

Der GitHub-Nutzer queen-mq hat Queen veröffentlicht, einen Open-Source-Nachrichtenbroker, der darauf ausgelegt ist, ACID-Garantien (Atomizität, Konsistenz, Isolation, Dauerhaftigkeit) für verteiltes Messaging bereitzustellen. Veröffentlicht am 10. November 2026, zielt dieses auf Rust basierende System darauf ab, die Backend-Architektur zu vereinfachen, indem jeder Kunde, jede Bestellung oder jedes Gespräch als eigene Queue behandelt wird. So wird sichergestellt, dass Zustandsänderungen und Nachrichtenbestätigungen gemeinsam als eine einzige Transaktion committet werden.

Was passiert ist

Die Veröffentlichung führt einen Broker ein, der sich von den traditionellen Modellen der eventual consistency löst, die häufig in Hochdurchsatzsystemen zu finden sind. Anstatt sich auf separate Mechanismen für das Sperren, Planen oder Wiederholen fehlgeschlagener Nachrichten zu verlassen, integriert Queen diese Funktionen direkt in seinen transaktionalen Kern. Die Projektdokumentation hebt hervor, dass jeder Schritt in einem Workflow – einschließlich Bestätigung, Versand der nächsten Nachricht, Aktualisierung des Zustands und Einstellung von Timern – als eine atomare Einheit committet wird. Dieser Ansatz beseitigt die Komplexität bei der Verwaltung von Redis-Sperren, Cron-Jobs oder dedizierten Wiederholungstabellen.

Queen unterstützt mehrere Programmiersprachen, darunter JavaScript, Python, Go und Rust, und bietet Funktionen wie Stream Processing mit tumbling, sliding und session windows. Es umfasst auch Unterstützung für conflating consumer groups, die nur die neueste Nachricht für Partitionen liefern, bei denen nur der aktuelle Wert relevant ist. Für Request-Reply-Muster stellt der Broker ephemere In-Memory-Queues bereit, die schnell sind, aber bei Abstürzen absichtlich verloren gehen, was sie von persistenten Logs unterscheidet. Das System ist so konzipiert, dass es komplexe Zustandsverwaltung handhabt, und bietet Key-Value-Speicher, verteilte Sperren und geplante Timer innerhalb derselben transaktionalen Grenze wie die Nachrichtenverarbeitung.

Wichtige Details

• ACID-Transaktionen: Jede Nachrichtenoperation, einschließlich Acknowledgments, Zustandsänderungen und Timer, wird atomar committet, sodass keine partiellen Updates auftreten.
• Hohe Leistungs-Benchmarks: Auf drei GCP-Knoten mit lokalem NVMe erreichte Queen 3 Millionen Nachrichten pro Sekunde mit einer p99-Latenz von 15–25 ms über bis zu 10 Millionen Partitionen.
• Schnelle Wiederherstellung: Ein Knoten, der nach fünf Minuten Ausfallzeit wieder dem Cluster beitrat, synchronisierte nur ein Delta von 1,1 GB in 28 Sekunden, deutlich schneller als in früheren Versionen.
• Sprachunabhängig: Unterstützt Clients in JavaScript, Python, Go und Rust und ermöglicht es unveränderten Kafka-Produzenten und -Konsumenten, sich über einen Kafka-kompatiblen Port zu verbinden.
• Integrierter Speicher: Der Broker kann Queues direkt in PostgreSQL-Tabellen oder S3-Buckets im JSONL- oder Parquet-Format schreiben, ohne externe Prozesse zu erfordern.
• Bewiesene Zuverlässigkeit: Die Software bestand 226 Jepsen-Tests in Version 2.7, was bestätigt, dass keine bestätigten Nachrichten verloren gingen und keine Leases doppelt gehalten wurden.

Hintergrund

Nachrichtenbroker sind wesentliche Komponenten in der modernen Softwarearchitektur und fungieren als Vermittler, die verschiedene Teile eines Systems asynchron kommunizieren lassen. Traditionelle Broker wie Kafka oder RabbitMQ priorisieren oft Durchsatz und Verfügbarkeit, manchmal auf Kosten der sofortigen Konsistenz. Entwickler müssen häufig zusätzliche Infrastruktur erstellen, wie datenbankgestützte Wiederholungs-Queues oder verteilte Sperrmanager, um sicherzustellen, dass die Geschäftslogik konsistent bleibt, wenn Nachrichten fehlschlagen oder in falscher Reihenfolge eintreffen.

ACID-Eigenschaften, die typischerweise mit relationalen Datenbanken assoziiert werden, stellen sicher, dass Transaktionen zuverlässig verarbeitet werden. Atomizität bedeutet, dass alle Teile einer Transaktion entweder erfolgreich abgeschlossen oder vollständig verworfen werden. Konsistenz stellt sicher, dass die Datenbank in einem gültigen Zustand bleibt. Isolation verhindert, dass gleichzeitige Transaktionen sich gegenseitig stören, und Dauerhaftigkeit garantiert, dass committete Daten Systemausfälle überleben. Indem Queen diese Garantien auf das Message Brokering bringt, versucht es, die operative Belastung für Engineering-Teams zu reduzieren, die zuvor mehrere Tools zusammenfügen mussten, um ähnliche Zuverlässigkeit zu erreichen.

Warum es wichtig ist

Für Teams, die ihre eigene Software betreiben, kann das Versprechen von ACID-Konformität in einem Nachrichtenbroker die architektonische Komplexität erheblich reduzieren. Derzeit erfordern viele selbst gehostete Anwendungen eine Kombination aus einer Nachrichten-Queue, einer relationalen Datenbank für den Zustand und einem separaten Store für verteilte Sperren. Die Verwaltung der Konsistenz zwischen diesen drei Systemen ist eine häufige Quelle für Fehler und operativen Overhead. Wenn Queen seine Ansprüche erfüllt, könnten Entwickler diese Triade durch eine einzelne Komponente ersetzen, was Bereitstellung, Monitoring und Debugging vereinfacht.

Die Leistungs-Benchmarks deuten darauf hin, dass diese Einfachheit nicht zu Lasten des Durchsatzes geht. Die Verarbeitung von 3 Millionen Nachrichten pro Sekunde mit niedriger Latenz ist konkurrenzfähig mit etablierten Playern wie Redpanda und Pulsar, insbesondere bei hohen Partitionszahlen. Für mittelständische Unternehmen, die ihre Infrastruktur skalieren, kann die Fähigkeit, 100 GB Rückstand in 32 Sekunden abzuarbeiten und Knoten schnell wiederherzustellen, den Unterschied zwischen einem kleinen Problem und einem längeren Ausfall während des Spitzenverkehrs bedeuten.

Allerdings birgt die Einführung einer neuen Kerninfrastrukturkomponente Risiken. Während die Jepsen-Tests Vertrauen in das Konsistenzmodell geben, variieren reale Produktionsanwendungsfälle stark. Teams müssen bewerten, ob spezifische Funktionen wie Queues pro Entität und integriertes S3-Dumping mit ihren Anforderungen an Datenaufbewahrung und -verarbeitung übereinstimmen. Die Apache-2.0-Lizenz erlaubt kommerzielle Nutzung und Modifikation, was für Unternehmen attraktiv ist, die Vendor Lock-in vermeiden möchten, während sie die Kontrolle über ihren Quellcode behalten.

Was Sie tun können

• Dokumentation prüfen: Laden Sie das PDF "The little book of QueenMQ" herunter, um Architektur, Speichermodell und API-Garantien zu verstehen, bevor Sie eine Adoption in Betracht ziehen.
• Benchmark-Tests durchführen: Replizieren Sie die bereitgestellten Benchmarks mit Ihrer eigenen Hardware oder Cloud-Umgebung, um zu überprüfen, ob die behaupteten Durchsatz- und Latenzwerte Ihre Anwendungsanforderungen erfüllen.
• Migrationspfade evaluieren: Wenn Sie derzeit Kafka verwenden, testen Sie den Kafka-kompatiblen Port, um zu sehen, ob bestehende Produzenten und Konsumenten ohne Codeänderungen verbinden können.
• Anforderungen an die Zustandsverwaltung bewerten: Ermitteln Sie, ob Ihre Anwendungslogik davon profitieren würde, KV-Speicher, Sperren und Timer direkt in den Nachrichten-Transaktionsfluss zu integrieren.
• Fehler-Szenarien testen: Nutzen Sie die Standby-Cluster-Funktion und die Knoten-Wiederherstellungsmechanismen in einer Staging-Umgebung, um die 28-sekündige Beitrittszeit und die Datenintegrität zu validieren.
• Sprachunterstützung prüfen: Stellen Sie sicher, dass die Client-Bibliotheken für Ihre primären Entwicklungssprachen (JS, Python, Go, Rust) reif genug für Ihre Produktionsstandards sind.