Очередь мертвых писем Amazon SQS: действительно ли это мертвая буква или яд?
Я пытаюсь получить разъяснение о том, что именно делает очередь мертвых писем Amazon SQS.
согласно http://aws.typepad.com/aws/2014/01/amazon-sqs-new-dead-letter-queue.html
Очередь Мертвых Писем - ARN (имя ресурса Amazon) очереди SQS, которая будет получать сообщения, которые не были успешно обработаны после максимального числа получает потребители.
не это больше похоже на очередь Poision? Ключевое различие заключается в том, что потребители получили сообщение. Мертвое письмо будет, когда сообщение потенциально нормально, но не может быть доставлено, вероятно, из-за сбоя в работе службы. http://www.eaipatterns.com/DeadLetterChannel.html
где, как это звучит, сообщение успешно принимается несколько раз, но обработка сообщения не удается, что я понимаю, как значение очереди ядовитых сообщений.
автобус сообщений против очереди
имеет ли шаблон мертвой буквы другое значение в контексте простой старой очереди? Поскольку SQS - это просто очередь, а не шина сообщений, она не отвечает за доставку сообщений. Вместо этого он ждет сообщений, которые будут подобраны (запрошены). Таким образом, традиционный шаблон мертвой буквы на самом деле не применяется, поскольку нет шины сообщений, пытающейся доставить сообщение и не способной найти получателя.
может ли SQS вести себя как шина сообщений?
есть ли способ через SQS настроить каналы и прослушиватели вместо явного опроса сообщений из очереди?
3 ответов
хороший вопрос.
на основе определения из канонический источник, который вы процитировали (цитаты удалены для ясности):
конкретный способ работы канала мертвых писем зависит от реализации конкретной системы обмена сообщениями, если она предоставляет его вообще. Канал можно назвать "мертвой очередью сообщений" или "мертвой очередью писем"."Как правило, каждая машина, на которой установлена система обмена сообщениями, имеет свой собственный локальный канал мертвой буквы, чтобы на какой бы машине сообщение не умирало, его можно перемещать из одной локальной очереди в другую без каких-либо сетевых неопределенностей. Это также записывает, на какой машине сообщение умерло. Когда система обмена сообщениями перемещает сообщение, она также может записывать исходный канал, по которому сообщение должно было быть доставлено.
...неясно, действительно ли есть разница. Я понимаю, что вы подразумеваете под "ядовитой очередью", и Ваше понимание того, как работает SQS, звучит. Семантически, разница между DLQ и PQ - "undeliverable" в стиле электронной почты против "poison" - мне не ясна. Возможно, PQ-это аромат DLQ.
чистки рядов, политика повторной доставки ActiveMQ использует то же определение DLQ -- a hybrid DLQ / PQ--, что и SQS.
может ли SQS вести себя как шина сообщений?
SQS не может, но есть аналогичные продукты, которые могут.
-
SNS (Simple Notification Service)-это обобщенная система тем публикации и подписки. SNS позволяет создавать темы, а затем регистрировать подписчиков, которые получают push-уведомления. В настоящее время push-уведомления могут приходить в виде HTTP/S, электронной почты, SMS, SQS и push-уведомлений для мобильных устройств.
SNS имеет довольно здравомыслящий повтор политика для HTTP/ S, но не поддерживает DLQ или PQ АФАИК.
-
IronMQ-это еще одна полноценная служба очереди сообщений, которая немного более полнофункциональна, чем SQS. (Истинный порядок сообщений FIFO, более длительные задержки и т. д., Но, к сожалению, меньшие размеры сообщений.) Push-очереди позволяют настроить push - "подписчики", которые затем получают HTTP-сообщение каждый раз, когда новое сообщение помещается в очередь.
Если IronMQ не удается доставить сообщение -- время ожидания HTTP POST, или ваша конечная точка возвращает что-либо, кроме
2xx-- тогда он повторит попытку доставки. Если у него закончатся повторные попытки, он поместит сообщение в очередь ошибок - комбинацию DLQ и PQ в этом случае.Это, вероятно, так близко, как вы собираетесь добраться до истинного "ESB" в управляемой службе.
конечно, тогда есть истинные рамки ESBs и SOA с открытым исходным кодом -- мул, ServiceMix и так далее ... но я не знаю почти достаточно о том, что вы пытаетесь сделать, чтобы сделать какую-либо рекомендацию. :)
Я не уверен, что в большинстве случаев, что различие между DLQ и PQ необходимо. На самом деле я нахожу это определение будет довольно условным. Для большинства реализаций транзакционных сообщений, если сообщение не было успешно уничтожено из очереди в течение указанного числа попыток, оно переходит в DLQ. Наличие отдельной очереди для искаженных сообщений означает, что теперь у вас есть только два места для поиска сообщений, которые не обрабатываются успешно, два исключения очереди для мониторинга или операционных соображений и некоторый процент сообщений, которые, похоже, могут принадлежать к любой очереди(сценарии пакетной обработки приходят на ум).
нет, он не будет вести себя как активный ESB. Простая служба очередей проста по определению. Существует гарантия доставки" по крайней мере один раз", но помимо этого она дает очень мало обещаний.
Он предназначен только для опроса / длинного опроса. У вас может быть несколько очередей, каждая из которых служит разным целям, но одна очередь очень проста и не предназначена для обслуживания нескольких функций или предоставления расширенной логики. SWF может предоставить то, что вы хотите, но, скорее всего, вам нужно будет реализовать шина ESB.