А теперь по поводу выбора RabbitMQ или Kafka.
👁 395↗ 2💬 9
Банально говорить, что важно учитывать все факторы, как производительность, масштабируемость, надежность, гарантии доставки и архитектурные различия. Рекомендуется тщательно оценить оба варианта и их соответствующие функции, чтобы принять решение.
Выбор между RabbitMQ и Apache Kafka зависит от конкретного варианта использования и требований.
Если ваш вариант использования включает организацию очередей сообщений меньшего масштаба с меньшей пропускной способностью и традиционные сценарии запроса-ответа, RabbitMQ может быть хорошим выбором.
С другой стороны, если вам требуется решение для потоковой передачи данных в реальном времени с высокой пропускной способностью, лучше подойдет Apache Kafka.
Главную мысль, которую я хотел донести, что вопрос “что лучше?” - некорректный. Нужно выбирать исходя из ваших задач и требований бизнеса.
Любое архитектурное решение - это принятие компромиссов. Лучшего варианта нет, есть допустимый вариант недостатки которого вы осознаете и принимаете. !💪
PS: Мне говорят, что в этом канале в основном боты, так как мало пишут комментариев и ставят мало эмоций, давайте опровергнем это !🙂
16431
Комментарии · 9
- @DarkhanKashЯ не бот! Спасибо за краткий обзор брокеров!
- анонимСкоро буду проводить тест Тьюринга для вступления в канал !😂
- @superadmin0777По поводу отличий в сложности установки, настройки и эксплуатации стоит упомянуть
- @na4ynСпасибо за сравнение Р и Кафки. Вопрос, который мне задали на собеседовании: Представим 2 события. Вначале отправляю ЗАБЛОКИРОВАТЬ ПОЛЬЗОВАТЕЛЬЯ потом СНЯТЬ СО СЧЕТА ДЕНЬГИ По необычным причинам первый эвент пришел с опозданием, сначала Снялись деньги, а только потом заблокировали счёт. (Привело к тому что с заблокированного счета списали деньги) как решить вопрос Порядка обработки событий на Ребите и Кафке, возможно ли это?
- @NadyaDekasЭто из вопросов про race condition похоже. Возможно клиент взял в обработку одновременно два сообщения из брокера
- @superadmin0777у rmq есть priority queue implementation, а у Кафки нет. Блокировку можно с выскоким приоритетом слать, а списание с низким
- @superadmin0777хотя на Кафке видимо это можно разрулить через ordered streams
- @dios13Не так часто сталкивался с такими проблемами, но как выше описали, то смотрел бы в сторону приоритетов и одной или разных очередей. Хотя мне кажется и приоритеты не гарантируют порядок этих действий. Ведь если задать высокий приоритет для блокировки, то он может быть обработан раньше снятия денег, даже если снятие денег было раньше вызвано. Тут наверное ещё стоит оперировать бизнес -требованиями. Из решений, которые пришли в голову, это номеровать сообщения и проверять их наличие, т.е. если обрабатывается сообщение 10, то сообщение 9 должно было быть получено. Но так как сообщения все равно могут приходить в разном порядке из разных очередей, то такой вариант не подойдёт. Другой вариант, это логирование сообщений. Все отправляемые сообщения должны логироваться в единой системе, там у них будет статус доставки или выполнения. Перед выполнением какой-то операции необходимо проверять выполнение/наличие других связанных операций в журнале. Если они завершены, то продолжать работу. Если кто-то знает реальное решение, то рад буду узнать его.
- @shaurgonПобуду ещё одним не-ботом в канале 😉