Verleger
Vollständiger Quellcode: github.com/ThreeDotsLabs/watermill/message/pubsub.go
// ...
type Verleger interface {
// Publish veröffentlicht die bereitgestellten Nachrichten zum angegebenen Thema.
//
// Die Veröffentlichung kann synchron oder asynchron sein - es kommt auf die Implementierung an.
//
// Die meisten Verleger-Implementierungen unterstützen keine atomare Nachrichtenveröffentlichung.
// Das bedeutet, dass, wenn die Veröffentlichung einer der Nachrichten fehlschlägt, die nächste nicht veröffentlicht wird.
//
// Publish muss thread-sicher sein.
Publish(thema string, nachrichten ...*Nachricht) error
// Wenn der Verleger asynchron ist, sollte Close nicht gesendete Nachrichten abwickeln.
Close() error
}
// ...
Veröffentlichung mehrerer Nachrichten
Die meisten Verleger-Implementierungen unterstützen keine atomare Nachrichtenveröffentlichung. Das bedeutet, dass, wenn die Veröffentlichung einer der Nachrichten fehlschlägt, die nächste nicht veröffentlicht wird.
Asynchrone Veröffentlichung
Die Veröffentlichung kann synchron oder asynchron sein - es kommt auf die Implementierung an.
Close()
Wenn der Verleger asynchron ist, sollte Close
nicht gesendete Nachrichten abwickeln. Vergessen Sie nicht, die Abonnenten zu schließen. Andernfalls könnten einige Nachrichten verloren gehen.
Abonnent
Vollständiger Quellcode: github.com/ThreeDotsLabs/watermill/message/pubsub.go
// ...
type Abonnent interface {
// Subscribe gibt einen Ausgabekanal mit Nachrichten aus dem angegebenen Thema zurück.
// Der Kanal wird geschlossen, wenn Close() auf dem Abonnenten aufgerufen wird.
//
// Um die nächste Nachricht zu empfangen, muss `Ack()` auf der empfangenen Nachricht aufgerufen werden.
// Wenn die Nachrichtenverarbeitung fehlschlägt und die Nachricht erneut geliefert werden soll, sollte `Nack()` aufgerufen werden.
//
// Wenn der bereitgestellte ctx abgebrochen wird, wird der Abonnent das Abonnement schließen und den Ausgabekanal schließen.
// Der bereitgestellte ctx wird an alle generierten Nachrichten übergeben.
// Wenn Ack oder Nack aufgerufen wird, wird der Kontext der Nachricht abgebrochen.
Abonnieren(ctx context.Context, thema string) (
}
Ack/Nack-Mechanismus
Abonnenten sind dafür verantwortlich, Ack
und Nack
von Nachrichten zu behandeln. Eine ordnungsgemäße Implementierung sollte auf Ack
oder Nack
warten, bevor die nächste Nachricht verarbeitet wird.
Wichtiger Hinweis zur Implementierung von Abonnenten: Es ist entscheidend, Ack/Offset an den Speicher/Agenten der Nachricht zu senden, nachdem Ack von Watermill-Nachricht empfangen wurde. Andernfalls besteht die Möglichkeit, die Nachricht zu verlieren, wenn der Prozess vor der Verarbeitung der Nachricht abstürzt.
Close()
Close
schließt alle Abonnements und deren Ausgabekanäle und wickelt gegebenenfalls Offset ab.
Mindestens einmalige Auslieferung
Watermill basiert auf mindestens einmaliger Auslieferungssemantik. Das bedeutet, dass bei einem Fehler bei der Verarbeitung einer Nachricht und es nicht möglich ist, Ack
zu senden, die Nachricht erneut geliefert wird.
Sie müssen dies beachten und Ihre Anwendung für idempotente Verarbeitung erstellen oder einen Wiederholungsmechanismus implementieren.
Leider ist es nicht möglich, eine generische Retry-Middleware zu erstellen, daher ermutigen wir Sie, Ihre eigene Implementierung zu erstellen.
Generische Tests
Jedes Pub/Sub ist in den meisten Aspekten ähnlich. Um separate Tests für jede Pub/Sub-Implementierung zu vermeiden, haben wir eine Test-Suite erstellt, die von jedem Pub/Sub bestanden werden sollte.
Diese Tests finden Sie in pubsub/tests/test_pubsub.go
.
Eingebaute Implementierung
Um die verfügbaren Pub/Sub-Implementierungen zu überprüfen, verweisen Sie bitte auf die unterstützten Pub/Sub.
Anpassen des Pub/Sub
Für Anweisungen zur Einführung der Unterstützung für ein neues Pub/Sub verweisen Sie bitte auf "Anpassen des Pub/Sub".