Editor
Código fuente completo: github.com/ThreeDotsLabs/watermill/message/pubsub.go
// ...
type Publisher interface {
// Publish publica los mensajes proporcionados en el tema dado.
//
// La publicación puede ser síncrona o asíncrona, dependiendo de la implementación.
//
// La mayoría de las implementaciones de publicadores no admiten la publicación atómica de mensajes.
// Esto significa que si la publicación de uno de los mensajes falla, el siguiente no se publicará.
//
// Publish debe ser segura para subprocesos.
Publish(topic string, messages ...*Message) error
// Si el publicador es asíncrono, Close debe vaciar los mensajes no enviados.
Close() error
}
// ...
Publicación de Múltiples Mensajes
La mayoría de las implementaciones de publicadores no admiten la publicación atómica de mensajes. Esto significa que si la publicación de uno de los mensajes falla, el siguiente no se publicará.
Publicación Asíncrona
La publicación puede ser síncrona o asíncrona, dependiendo de la implementación.
Close()
Si el publicador es asíncrono, Close debe vaciar los mensajes no enviados. No olvides cerrar los suscriptores. De lo contrario, podrías perder algunos mensajes.
Suscriptor
Código fuente completo: github.com/ThreeDotsLabs/watermill/message/pubsub.go
// ...
type Subscriber interface {
// Subscribe devuelve un canal de salida con mensajes del tema proporcionado.
// El canal se cerrará cuando se llame a Close() en el suscriptor.
//
// Para recibir el próximo mensaje, se debe llamar a `Ack()` en el mensaje recibido.
// Si el procesamiento del mensaje falla y se debe volver a enviar, se debe llamar a `Nack()`.
//
// Cuando se cancela el ctx proporcionado, el suscriptor cerrará la suscripción y cerrará el canal de salida.
// El ctx proporcionado se establece en todos los mensajes generados.
// Cuando se llama a Ack o Nack en el mensaje, se cancelará el contexto del mensaje.
Subscribe(ctx context.Context, topic string) (
}
Mecanismo Ack/Nack
Los suscriptores son responsables de manejar Ack y Nack de los mensajes. Una implementación adecuada debe esperar Ack o Nack antes de consumir el siguiente mensaje.
Consejo de implementación del suscriptor importante: Es crucial enviar Ack/offset al almacenamiento/agente del mensaje después de Ack de Watermill. De lo contrario, si el proceso muere antes de procesar el mensaje, existe la posibilidad de perderlo.
Close()
Close cerrará todas las suscripciones y sus canales de salida, y vaciará los offsets si es necesario.
Entrega al Menos Una Vez
Watermill está construido utilizando la semántica de entrega al menos una vez. Esto significa que si ocurre un error al procesar un mensaje y no es posible enviar Ack, el mensaje se volverá a enviar.
Debes tener esto en cuenta y diseñar tu aplicación para un procesamiento idempotente o implementar un mecanismo de reintento.
Lamentablemente, no es posible crear un middleware de reintento genérico, por lo que te animamos a construir tu propia implementación.
Pruebas Genéricas
Cada Pub/Sub es similar en la mayoría de los aspectos. Para evitar escribir pruebas separadas para cada implementación de Pub/Sub, hemos creado un conjunto de pruebas que cualquier Pub/Sub debe superar.
Estas pruebas se pueden encontrar en pubsub/tests/test_pubsub.go.
Implementación Incorporada
Para verificar las implementaciones disponibles de Pub/Sub, consulta los Pub/Sub admitidos.
Implementación de Pub/Sub Personalizado
Para obtener instrucciones sobre cómo introducir soporte para un nuevo Pub/Sub, consulta "Implementación de Pub/Sub Personalizado".