#amazon-web-services #amazon-sqs #aws-java-sdk
#amazon-web-services #amazon-sqs #aws-java-sdk
Вопрос:
Я пытаюсь разработать пользовательский интерфейс для команды контроля качества, где они могут проверять сообщения в очереди без входа в AWS.
Я просто отображаю первые десять сообщений очереди в этом пользовательском интерфейсе, чтобы снизить затраты, но что, если специалисту по контролю качества потребуется получить дополнительные записи после просмотра сообщений очереди?
Как я могу получить следующие 10 сообщений из очереди, не используя параметр тайм-аута видимости?
Ответ №1:
Похоже, вам может потребоваться временно одновременно записывать свои сообщения SQS в базу данных, а вместо этого команда контроля качества просматривает сообщения в базе данных. В SQS нет понятия подкачки или «следующих 10» — когда вы читаете сообщения из очереди, вы должны их обработать и удалить, а затем запросить дополнительные. Просмотр записей базы данных может быть лучше для целей контроля качества.
Комментарии:
1. Да, это хорошая идея .. Любыми способами я использовал «10 сообщений», потому что максимальный размер пакета для извлечения сообщений из очереди равен 10… Спасибо E.J
Ответ №2:
Если вам нужно больше сообщений, просто попросите SQS предоставить больше сообщений.
SQS знает, что кто-то уже получил первые 10, но понятия не имеет, что это были вы. Если вы попросите больше, вы получите больше.
Пока не истечет таймер видимости, который по умолчанию равен 30 секундам, для полученных вами сообщений, вы можете повторно запрашивать, спрашивать и спрашивать, и вы больше не увидите те же сообщения. Сообщения находятся «в полете» — это означает, что SQS ожидает, пока кто-нибудь их удалит, изменит их видимость или истечет время ожидания. По истечении таймера вы снова начнете их видеть.
Каждая очередь SQS позволяет получать до 120 000 сообщений без подтверждения, удаления или изменения видимости. Удачи в достижении этого предела.
я не могу использовать время ожидания видимости, поскольку продукт находится в производстве, и мои инструменты не должны блокировать фактическую службу от использования сообщений очереди
Я не совсем уверен, что это значит. Если вы говорите, что время ожидания видимости вашей очереди по умолчанию равно 0, то настоящая проблема здесь в том, что вы с самого начала делаете это неправильно. Тайм-аут видимости по умолчанию, равный 0, приведет к повторной доставке сообщений, если у вас более одного потребителя.
Ознакомьтесь с документацией для определения времени ожидания видимости. Тайм-аут видимости — это время, в течение которого потребителю разрешено удерживать сообщение без его удаления или изменения времени ожидания видимости, прежде чем оно будет доставлено другому потребителю. Это не задерживает доступность сообщений, которые еще не были использованы, или сообщений, которые были использованы и время ожидания которых истекло или было сброшено.
Если вы хотите проверять сообщения, не блокируя приложение, извлекайте их из очереди, отправляя столько запросов, сколько вам нужно (делая более одного запроса, если их больше 10), а затем немедленно отправляйте запрос API, чтобы установить время ожидания видимости для этих сообщений равным 0. Это немедленно освободит их для повторного использования приложением (или этим инструментом, если приложение, конечно, загружено).
Альтернатива: для действительно независимого пути анализа сообщений очереди я использую другой подход: разветвление SNS.
Вместо того, чтобы производитель сообщений отправлял сообщения в SQS напрямую, я отправляю их в раздел SNS. Основная очередь и вторичная очередь являются подписчиками этого раздела. Приложение использует данные из первичной очереди, а вторичная очередь просто сидит там, собирая вторую копию каждого сообщения. Когда срок действия сообщений из вторичной очереди истекает, они просто исчезают (по умолчанию = 4 дня). Это дает мне очень полезный инструмент для устранения неполадок, а также для обработки любых катастрофических ситуаций в приложении-потребителе, которые приводят к неправильной обработке сообщений, когда сообщения, полученные от SQS, впоследствии теряются из-за непредвиденных или необработанных условий.
Комментарии:
1. Спасибо Майклу за ваш ответ. но я не могу использовать тайм-аут видимости, поскольку продукт находится в производстве, и мои инструменты не должны блокировать фактическую службу от использования сообщений очереди.
Ответ №3:
Вам придется удалить первые 10 сообщений, иначе они будут продолжать возвращаться. Возможно, что даже удаленное сообщение может быть возвращено, поэтому важно, чтобы ваша система могла обрабатывать повторяющиеся сообщения.