Многопоточная доставка сообщений Amazon SQS

Я понимаю, что для обеспечения огромной масштабируемости и надежности SQS проводит обширную распараллеливание ресурсов. Он использует избыточные серверы даже для небольших очередей, и даже сообщения, отправленные в очереди, резервируются избыточно в виде нескольких копий. Это факторы, которые мешают ему точно-раз доставки, как в RabbitMQ. Я видел даже удаленные сообщения.

Последствия для разработчиков заключаются в том, что они должны быть готовы к многократной доставке сообщений. Amazon утверждает, что это не проблема, но это так, то разработчик должен использовать некоторую конструкцию синхронизации, такую как блокировка транзакции базы данных или условная запись dynamo-db. обе из них уменьшают масштабируемость.

Вопрос:

В свете проблемы с дублирующейся доставкой, как работает функция сообщение-невидимый период? Сообщение не может быть невидимым. Если разработчик должен самостоятельно организовать синхронизацию, какая польза от периода невидимости. Я видел сообщения, переданные повторно, даже когда они должны были быть невидимыми.

Изменить

здесь я включаю некоторые ссылки

Ответ 1

Невидимая сообщения решает другую проблему, гарантирующую одну и только доставку. Рассмотрим длительную операцию над элементом в очереди. Если процессор держится во время операции, вы не хотите удалять сообщение, вы хотите, чтобы оно снова появилось и снова обрабатывалось другим процессором.

Итак, шаблон...

Запись (push) item в очередь
Элемент View (peek) в очереди
Отметить объект невидимым
Выполнить процесс по элементу
Написать результаты
Удалить (поп) элемент из очереди

Итак, независимо от того, получаете ли вы двойную доставку или нет, вам все равно нужно убедиться, что вы обрабатываете элемент в очереди. Если вы удалите его, вытащив его из очереди, а затем ваш сервер умрет, вы можете потерять это сообщение навсегда. Он позволяет проводить агрессивное масштабирование с использованием экземпляров пятна - и гарантирует (используя вышеприведенный шаблон), что вы не потеряете сообщение.

Но - он не гарантирует один раз и только один раз доставки. Но я не думаю, что он был разработан для этой проблемы. Я также не считаю это непреодолимой проблемой. В нашем случае (и я вижу, почему я никогда не замечал проблем раньше) - мы пишем результаты S3. Это не имеет большого значения, если он перезаписывает один и тот же файл с теми же данными. Конечно, если это дебетовая транзакция, поступающая в банк a/c, вам, вероятно, понадобится какой-то идентификатор корреляции... и большинство систем уже есть там. Поэтому, если вы получаете дублирующее значение корреляции, вы генерируете исключение и перемещаетесь.

Хороший вопрос. Подчеркнула кое-что для меня.