Я пытаюсь разработать пользовательский интерфейс для команды QA, где они могут проверять сообщения очереди без входа в AWS.
Чтобы сделать этот пользовательский интерфейс менее затратным, я показываю только первые десять сообщений очереди, что теперь, если специалист по контролю качества захочет получить больше записей после анализа сообщений очереди.
Как я могу получить следующие 10 сообщений из очереди без использования параметра тайм-аута видимости?
Похоже, вы можете захотеть одновременно временно записать свои сообщения SQS в базу данных и вместо этого заставить команду QA просматривать сообщения в базе данных. В SQS нет концепции пейджинга или «следующих 10» — когда вы читаете сообщения из очереди, вы должны обработать и удалить их, а затем запросить еще. Просмотр записей базы данных может быть лучше для целей контроля качества.
Если вы хотите больше сообщений, просто попросите SQS предоставить больше сообщений.
SQS знает, что кто-то уже получил первые 10, но понятия не имеет, что это были вы. Если вы попросите больше, вы получите больше.
Пока таймер видимости, который по умолчанию составляет 30 секунд, не истечет для полученных вами сообщений, вы можете многократно спрашивать, спрашивать и спрашивать, и вы больше не увидите одни и те же сообщения. Сообщения находятся «в полете» — это означает, что SQS ожидает, пока кто-то удалит их, изменит их видимость или истечет время таймера. Как только таймер истечет, вы снова начнете их видеть.
Каждая очередь SQS позволяет извлекать до 120 000 сообщений без подтверждения, удаления или изменения видимости. Удачи в достижении этого предела.
я не могу использовать время ожидания видимости, так как продукт находится в производстве, и мои инструменты не должны блокировать фактическую службу от использования сообщений очереди
Я точно не знаю, что это значит. Если вы говорите, что ваша очередь имеет тайм-аут видимости по умолчанию, равный 0, то реальная проблема заключается в том, что вы делаете это неправильно с самого начала. Тайм-аут видимости по умолчанию, равный 0, приведет к дублированию доставки сообщений, если у вас есть более одного потребителя.
Ознакомьтесь с документацией по тайм-ауту видимости. Тайм-аут видимости — это время, в течение которого потребитель может удерживать сообщение, не удаляя его или не изменяя тайм-аут видимости, прежде чем оно будет доставлено другому потребителю. Это не задерживает доступность сообщений, которые еще не были обработаны, или сообщений, которые были обработаны и время ожидания которых истекло или было сброшено.
Если вы хотите проверить сообщения, не блокируя приложение, извлеките их из очереди, отправив столько запросов, сколько вам нужно (сделав более одного запроса, если их больше 10), а затем сразу же отправьте запрос API, чтобы установить время ожидания видимости равным 0. для этих сообщений. Это немедленно освободит их для повторного использования приложением (или этим инструментом, если приложение находится в режиме ожидания, конечно).
Альтернатива: для действительно независимого пути анализа сообщений очереди я использую другой подход: SNS Fanout.
Вместо того, чтобы производитель сообщений отправлял сообщения в SQS напрямую, я отправляю их в тему SNS. Первичная и вторичная очереди являются подписчиками этого раздела. Приложение получает данные из первичной очереди, а вторичная очередь просто сидит там, собирая вторую копию каждого сообщения. Когда сообщения из вторичной очереди истекают, они просто исчезают (по умолчанию = 4 дня). Это дает мне очень полезный инструмент для устранения неполадок, а также для обработки каких-либо катастроф в приложении-потребителе, которые приводят к неправильной обработке сообщений, когда сообщения, полученные от SQS, впоследствии теряются из-за непредвиденных или необработанных условий.
Вам придется удалить первые 10 сообщений, иначе они будут возвращаться. Возможно, что даже удаленное сообщение может быть возвращено, поэтому важно, чтобы ваша система могла обрабатывать повторяющиеся сообщения.
