> Что происходит при передаче данных между сервисами с брокером сообщений если сервис недоступен (Go)

При передаче данных через брокер сообщений (например, RabbitMQ, Kafka, NATS) в случае недоступности сервиса-получателя поведение зависит от настроек брокера и логики отправителя. В Go это часто реализуется следующим образом:

1. Брокер сохраняет сообщение в очереди/топике. Если сервис-получатель временно недоступен, сообщение остаётся в очереди до тех пор, пока получатель не подключится и не подтвердит его обработку (ack). Это обеспечивает надёжность доставки (at-least-once delivery).

2. Таймауты и ретраи. Отправитель (продюсер) может настроить таймаут на публикацию. Если брокер недоступен, Go-клиент (например, github.com/streadway/amqp для RabbitMQ) вернёт ошибку. В этом случае применяются механизмы повторных попыток (retry) с экспоненциальной задержкой, часто реализуемые через паттерн circuit breaker или backoff.

3. Dead Letter Queue (DLQ). Если сообщение не может быть доставлено после нескольких попыток (например, из-за ошибки обработки или превышения TTL), оно перемещается в очередь мёртвых писем для последующего анализа.

4. Асинхронность и idempotency. В Go важно проектировать обработчики идемпотентными, так как при повторных доставках (из-за сбоев) сообщение может быть обработано дважды. Используйте уникальные идентификаторы сообщений (например, UUID) и проверку дубликатов в БД.

Пример кода на Go для обработки сбоя при публикации:

GO
err := ch.Publish("exchange", "routing_key", false, false, msg)
if err != nil {
    log.Printf("Failed to publish: %v, retrying...", err)
    time.Sleep(backoffDuration)
    // retry logic
}

Таким образом, при недоступности сервиса брокер обеспечивает буферизацию, а Go-приложение - корректную обработку ошибок и повторные попытки.