Подтверждение RabbitMQ
gosolivs opened this issue · comments
Может стоит добавить пример подтверждение обработки сообщений? Возможно и Nack.
https://github.com/evrone/go-service-template/blob/46ae5d6ed690206e6d1b8d13b1bb6e52c2cf76bb/pkg/rabbitmq/rmq_rpc/server/server.go#L74
https://github.com/evrone/go-service-template/blob/46ae5d6ed690206e6d1b8d13b1bb6e52c2cf76bb/pkg/rabbitmq/rmq_rpc/client/client.go#L170
Здесь я не совсем уверен что поступил правильно, но моя логика была следующей:
Я использую Кролик исключительно как транспорт. Вся бизнес-логика на стороне приложения. В RPC паттерне важен сам факт того что сообщение доставлено до сервера, если клиент не получит ответ более 2 секунд (по дефолту), запрос закончится ошибкой timeout и что дальше с этим делать решает бизнес-логика на стороне клиента.
Ack в этом случае - это просто подтверждение того что сервер жив и начал обрабатывать запрос. Если всё ок, сервер отправит ответ. Если что то пошло не так, клиент получит ошибку таймаута.
Ack и Nack хорошо подходят для асинхронного взаимодействия, но на мой взгляд не очень применимы при синхронном (в RPC паттерне). Я могу ошибаться.
@akirill0v @FedotovMaxim, что думайте?
На acknowledge базируется работа с RabbitMQ и без этого с сообщениями будет происходить беда. Лучше использовать механизм подтверждения доставки чтобы они не дублировались, не оставались в "Кролике" и не уходили в другие консьюмеры.
Так и есть, он используется. Тут вопрос скорее в том что Nack не используется)
Также можно autoAck в channel.Consume в true поставить. Чтобы вообще не писать Ack, раз он не нужен в этом месте.
Также можно
autoAckвchannel.Consumeвtrueпоставить. Чтобы вообще не писатьAck, раз он не нужен в этом месте.
Да, в текущий реализации это по сути autoAck, я его оставил явным на случай если захочется сделать свою более сложную логику.