RabbitMQ
- Derzeit auf Version 3.8.19.
- 16 Lazy-Mirror-Warteschlangen.
- Spezielle DLQs für alle.
[*]Derzeit auf Version 3.3.1.
[*]4 App-Server im Cluster.
[*]Verwendung eines Prefetch-Werts von 250 (Standard).
[*]minConsumer sind 2 und maxConsumer sind 50 und sind vom Typ Simple.
< /ul>
Also das Problem, das wir haben Dies geschieht während einer kleinen großen Menge (2000–3000) von Nachrichten an RabbitMQ, wobei die Spring-Boot-App ihre Verbraucher an maxConsumer weiterleitet, während die restlichen drei nur mit dem minConsumer chillen. Wir sehen das in der RabbitMQ-Verwaltungskonsole, da wir beim Spring Boot für RabbitMQ eine benutzerdefinierte Tag-Strategiekonfiguration haben. Danach sitzt die App mit all diesen Verbrauchern mit diesen Nachrichten als UNACK da und benötigt >30 Minuten, um sie zu verarbeiten und an RabbitMQ zurückzusenden, was normalerweise nur wenige Millisekunden dauert. Wir haben die Protokolle überprüft und keine Fehler oder gar eine Verlangsamung unserer externen Dienste (Datenbank, APIs usw.) festgestellt. Ich bin mir nicht sicher, ob das Problem das sein könnte, aber wir haben seit Jahren die gleichen App- und Rabbit-Konfigurationen und das passierte plötzlich. Wir würden uns über jede Hilfe zur Lösung dieses Problems freuen.