Comments 27
Не хватает хотя бы минимального сравнения с другими решениями. Зачем, например, тащить RabbitMQ для фоновой отправки почты, если можно взять что-то попроще для pub/sub, типа Redis
Спасибо, было в планах отдельную статью по вариантам использования и кейсам сделать.
В самом деле "тащить" мне кажется очень громко сказано, ресурсов в минимальной инсталяции в докере реббит кушает немного. Мы отдельные реббиты иногда ради одной очереди делаем чтобы разделять нагрузку продовую от "мусорной"
Я бы для отправки почты также взял реббит - потому что он умеет хранить и может перенести рестарт и смерть всех сервисов. Редис если честно не впечатлил
Не надо, пожалуйста, хватит использовать редис как брокер сообщений. Стоит ему дать по голове/упасть по оому/ребутнуть сервер с ним, и вы потеряете часть сообщений. Не столько кролик ест ресурсов, чтобы на нем экономить.
...Или тупо запустить код асинхронно. Мне тоже очень интересен ответ на этот вопрос.
По мне так единственная суперспособности очереди заключается в том, чтобы понемногу капать задачами в воронки скрвисов, чтобы последние не перегрелись. Ну и ускорение общения между сервисами за счёт использования не HTTP.
Вот тут не совсем понятно:
Если сломается брокер, в худшем случае вы потеряете часть сообщений, но ядро сервиса всё ещё будет работать, так как берет информацию из базы данных. Сообщения будут накапливаться, и когда сервер вернётся, то быстро прочитает и обработает образовавшийся долг.
Если сломался брокер то все встало колом, поскольку сервисы без шины обмена слепы и глухи. В этом случае сервис-публикатор должен будет заботиться о том, что бы сохранить данные в какой-то базе, но ни как не сам отвалившийся брокер.
Речь видимо шла о том что сам сервис продолжит работу в формате - интерфейс открывается, данные на момент до падения брокера - отображаются.
Но да, если речь о отказоустойчивой инфраструктуре надо мало того что делать кластер, но еще и резервировать потоки в другие ДЦ и реализовывать внутренние очереди сервисов-паблишеров. Например можно рядом с паблишером сайдкаром поднимать реббит с шовелом в прод кластер.
Сервисы не становятся слепы или глухи, в них просто перестают происходить события.
Если вы готовите брокер правильно, то его полное отсутствие сродни стоп-кадру в компьютерной игре, когда вы по-прежнему можете бродить по миру, но на вас не нападают злобные враги и не даются новые задания. Печально, но никак не тянет на катастрофу.
С учётом того, что у среднего веб-приложения большинство запросов это Get, падение брокера вызовет шок и трепет далеко не у всех пользователей.
Крайне приятно встретить в сети конспект по своему видео на Youtube трехлетней давности.
WhatsApp вроде тоже на кролике изначально базировался?
То, что он написан на Erlang, это преимущество?
А чем кролик лучше того же ActiveMQ? Тоже open-source MQ брокер.
Вот неплохой материал есть https://hevodata.com/learn/rabbitmq-vs-activemq/#Understanding-the-Key-Differences. По сути там как говорится про кластеризацию, то о чём мы и писали, что RabbitMQ хорош для сложных сценариев обмена.
Если доберутся руки писать о кейсах, когда лучше применим RabbitMQ, постараемся не забыть про разницу методов обмена сообщениями. P2P. PUB-SUB в ActiveMQ вполне может делать этот инструмент более полезным в каких-то частных кейсах.
Интересно было бы рассказать о развертывании отказоустойчивого (из 3-х) серверов брокера Раббит в Кубернетесе
Как раз есть задача вынести все ресурсоемкие действия системы во внешнюю обработку.
Вопрос в чем удобство кролика по сравнению с самодельной реализацией, которая будет смотреть на рабочую БД.
Т.е. ИС вместо выполнения действия создаётся как бы задачу в виде некой записи в БД. Самописное приложение периодически туда заглядывает и выполняет что велено. В случае с кроликом так же придётся помещать сообщение в очередь сообщений, а приложению исполнителю читать эти сообщения. Принципиально преимущества не очевидны. Другими словами, зачем на кузнец? :)
Когда и зачем нужен RabbitMQ