Кафка или SNS или что-то еще?

Извините, если это вопрос новичков. Но я пытаюсь понять, что я должен использовать. Насколько я понимаю, Кафка:

Apache Kafka - это распределенная система обмена сообщениями с подпиской.

И SNS также является паб/подсистемой.

Моя цель состоит в том, чтобы использовать некоторую систему сообщений очереди на AWS с приложением, которое будет распространяться на нескольких серверах. Кстати (основным языком является Python). И поскольку это на amazon, моя первая мысль заключалась в использовании SNS и SQS. Но чем я видел много людей, использующих Кафку на AWS. Каковы преимущества один над другим?

Ответ 1

Варианты использования Kafka и Amazon SQS/Amazon SNS совершенно разные.

Кафка, как вы писали, является распределенной системой публикации-подписки. Он рассчитан на очень высокую пропускную способность, обрабатывая тысячи сообщений в секунду. Конечно, вам нужно настроить и сгруппировать его для себя. Он поддерживает несколько считывателей, которые могут "догнать" поток сообщений в любой точке (ну, пока сообщения все еще находятся на диске). Вы можете использовать его как в очереди (используя группы потребителей), так и в качестве темы.

Важной характеристикой является то, что вы не можете выборочно воспринимать сообщения как "обработанные"; единственный вариант - подтверждение всех сообщений до определенного смещения.

SQS/SNS, с другой стороны:

нет настроек/без обслуживания
либо очередь (SQS), либо тема (SNS)
различные ограничения (по размеру, длительности сообщения и т.д.)
ограниченная пропускная способность: вы можете выполнять пакетные и параллельные запросы, но при этом достижение высокой пропускной способности будет дорогостоящим.
Я не уверен, что реплицируются сообщения; однако, по крайней мере, как только гарантия доставки в SQS предложит так
SNS имеет уведомления для электронной почты, SMS, SQS, встроенного HTTP. С Kafka вам, вероятно, придется самому закодировать его.
нет концепции потока сообщений

В целом я бы сказал, что SQS/SNS хорошо подходят для более простых задач и рабочих нагрузок с меньшим объемом сообщений.

Ответ 2

Это классический компромисс:

Инструменты AWS (SQS, SNS)

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

Апач Кафка

Здесь вы используете очень популярную (не модную) распределенную (это важно, если вы думаете, что будете масштабировать) модель PUB/SUB. В настоящее время эта модель представляется наиболее предпочтительной, поскольку аналитика данных, проходящих по каналам, очень распространена, и, как правило, с архитектурой SOA вы можете иметь множество небольших сервисов, которые принимают сообщения и выполняют свои функции, не имея данных. быть удаленным из очереди. Вы также получаете множество опций конфигурации, поэтому в зависимости от варианта использования вы можете точно настроить его под свои нужды. Это означает больше работы, но более оптимизированный сервис в будущем.

Резюме

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

Персональный совет

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

Ответ 3

kafka имеет коэффициент репликации для репликации. Почему вы говорите, что сообщения не копируются в kafka? Проверьте "default.replication.factor" на http://kafka.apache.org/08/configuration.html.