Publication et Abonnement

Éditeur

Code source complet : github.com/ThreeDotsLabs/watermill/message/pubsub.go

// ...
type Éditeur interface {
	// Publish publie les messages fournis sur le sujet donné.
	//
	// La publication peut être synchrone ou asynchrone - cela dépend de l'implémentation.
	//
	// La plupart des implémentations d'éditeur ne prennent pas en charge la publication atomique de messages.
	// Cela signifie que si la publication de l'un des messages échoue, le suivant ne sera pas publié.
	//
	// Publish doit être thread-safe.
	Publish(sujet string, messages ...*Message) error
	// Si l'éditeur est asynchrone, Close doit vider les messages non envoyés.
	Close() error
}
// ...

Publication de plusieurs messages

La plupart des implémentations d'éditeurs ne prennent pas en charge la publication atomique de messages. Cela signifie que si la publication de l'un des messages échoue, le suivant ne sera pas publié.

Publication asynchrone

La publication peut être synchrone ou asynchrone - cela dépend de l'implémentation.

Fermer()

Si l'éditeur est asynchrone, Fermer devrait vider les messages non envoyés. N'oubliez pas de fermer les abonnés. Sinon, vous pourriez perdre des messages.

Abonné

Code source complet : github.com/ThreeDotsLabs/watermill/message/pubsub.go

// ...
type Abonné interface {
	// Subscribe renvoie un canal de sortie avec des messages du sujet fourni.
	// Le canal se fermera lorsque `Fermer()` est appelé sur l'abonné.
	//
	// Pour recevoir le prochain message, `Ack()` doit être appelé sur le message reçu.
	// Si le traitement du message échoue et que le message doit être renvoyé, `Nack()` doit être appelé.
	//
	// Lorsque le ctx fourni est annulé, l'abonné fermera l'abonnement et le canal de sortie.
	// Le ctx fourni est défini pour tous les messages générés.
	// Lorsque Ack ou Nack est appelé sur le message, le contexte du message sera annulé.
	Subscribe(ctx context.Context, sujet string) (
}

Mécanisme Ack/Nack

Les abonnés sont responsables de gérer Ack et Nack à partir des messages. Une implémentation adéquate devrait attendre Ack ou Nack avant de consommer le message suivant.

Conseil d'implémentation important pour l'abonné : Il est crucial d'envoyer Ack/décalage au stockage/agente du message après l'Ack du message Watermill. Sinon, si le processus s'interrompt avant le traitement du message, il y a un risque de perte du message.

Fermer()

Fermer fermera tous les abonnements et leurs canaux de sortie, et videra les décalages si nécessaire.

Livraison au moins une fois

Watermill est construit en utilisant une sémantique de livraison au moins une fois. Cela signifie que si une erreur se produit lors du traitement d'un message et qu'il n'est pas possible d'envoyer Ack, le message sera renvoyé.

Vous devez garder cela à l'esprit et concevoir votre application pour un traitement idempotent ou implémenter un mécanisme de réessai.

Malheureusement, la création d'un middleware de réessai générique n'est pas possible, nous vous encourageons donc à construire votre propre implémentation.

Test générique

Chaque Pub/Sub est similaire à bien des égards. Pour éviter d'écrire des tests séparés pour chaque implémentation de Pub/Sub, nous avons créé une suite de tests que tout Pub/Sub doit réussir.

Ces tests peuvent être trouvés dans pubsub/tests/test_pubsub.go.

Implémentation intégrée

Pour vérifier les implémentations de Pub/Sub disponibles, veuillez vous référer au Pub/Sub supporté.

Implémentation personnalisée de Pub/Sub

Pour des instructions sur l'introduction du support d'un nouveau Pub/Sub, veuillez vous référer à "Implémentation personnalisée de Pub/Sub".