В чем разница между Kinesis и SQS?

Question

Я знаю, что в Интернете есть много материалов по этому вопросу, однако я не нашел ни одного, который мог бы достаточно ясно объяснить этот вопрос новичку, как я ... Ценю это, если кто-нибудь поможет мне понять ключевые различия между этими вопросами. две службы и варианты использования с примерами из реальной жизни. Спасибо!

Answer 1

Amazon SQS - очередь. Базовый процесс:

• Сообщения отправляются в очередь . Они остаются там до 14 дней.
• Рабочие программы могут запросить сообщение (или до 10 сообщений) из очереди.
• При получении сообщения изочередь:
  • Она остается в очереди, но помечена как невидимая
  • Когда работник завершил обработку сообщения, он сообщает SQS: удалить сообщение из очереди
  • Если работник не удаляет сообщение в течение периода ожидания невидимости очереди , то сообщение появляется в очереди для обработки другим работником
  • Работник может, при желании, периодически сообщать SQS держать сообщение невидимым , поскольку оно все еще обрабатывается

Таким образом, после обработки сообщения оно удаляется.

В Amazon Kinesis сообщение отправляется в поток . Поток делится на осколков (думайте о них как о мини-потоках). При получении сообщения Kinesis сохраняет сообщение в последовательном порядке . Затем работники могут запросить сообщение с начала потока или из определенного места в потоке. Например, если он уже обработал 5 сообщений, он может запросить 6-е сообщение. Сообщения хранятся в потоке в течение некоторого времени (например, 24 часа).

Мне нравится думать об этом как о кинопленке - каждый кадр в фильме сохраняется в порядке,Вы можете воспроизвести фильм с самого начала, или вы можете быстро перейти к середине и начать играть оттуда. Кроме того, вы можете перемотать на более раннюю часть и посмотреть его. То же самое верно для потока Kinesis, и несколько потребителей могут одновременно читать из различных частей потока.

Итак, какой выбрать?

• Если сообщение используется один раз, а затем отбрасывается, вероятно, лучшим выбором будет очередь .
• Если сохранение порядка сообщений важно и / илисообщения будут использоваться более одного раза, тогда stream , вероятно, лучше.

Answer 2

Я пытаюсь дать простой ответ, исходя из моего практического опыта:

1. Рассматривать SQS как службу временного хранения. Варианты использования:

   • управление данными с различными приоритетами очереди
   • хранение данных в течение ограниченного периода времени
   • Лямбда DLQ
   • уменьшить затраты с помощью длинного опроса
   • создать FIFO

2. Рассмотрим Kinesis как сборщик большого потока данных в реальном времени. Примеры использования:

   • очень очень большой поток данных из разных источников
   • резервное копирование данных, просто включив Firehose (вы получаете данныеОзеро бесплатно)
   • получить статистику сразу на этапе сбора, интегрируя Kinesis Analytics
   • имеет контрольных точек для отслеживания в DynamoDB обработанных записей /ошибка

Примечание: учтите, что обе службы могут быть легко интегрированы с лямбда-функциями, поэтому существует множество вариантов использования, которые могут быть решены как с помощью SQS, так и Kinesis. Во всяком случае, я попытался перечислить некоторые случаи использования, когда я обнаружил, что один из двух работает лучше, чем другой. Надеюсь, это может быть полезно:)

Answer 3

Эта статья довольно красиво подводит итог, imo:

https://sookocheff.com/post/aws/comparing-kinesis-and-sqs/

, но в основном, если вы не знаете, какой вам нужен, начинайте с SQS, пока не сможетеделай что хочешь. SQS чрезвычайно прост в настройке и использовании, и для его правильного использования практически не требуется опыта.

Kinesis требует гораздо больше времени и опыта для настройки, поэтому, если вам это не нужно, не беспокойтесь -хотя может использоваться для многих из тех же вещей, что и SQS.

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

В связанной статье это объясняется лучше меня.