Комментарии 10
Чё-т я не очень сильно понимаю, в чём прикол создания кучи очередей таким образом, если можно сделать единую структуру данных в какой-либо БД и оттуда все сервисы будут брать данные?
И добавлять данные, и изменять данные, и устраивать взаимные блокировки и вычитывать всю базу за получением данных и не забывать блокировать данные для своей consumer-группы…
Очереди не для решения проблемы шаринга данных
БД - единая точка отказа, если запросов будет слишком много то база будет bottle neck'ом - снижается производительность, постоянный опрос БД тоже снижает её. Ну и масштабировать БД намного сложнее, нужно будет решать проблемы балансирования задач если нужно несколько инстансов сервиса
Раббит точно такая же единая точка отказа. Особенно если нужно решать проблемы с кворумами или зеркалами. Он точно так же может упереться в сетевой стек. Причём учтите, Раббит он не сам по себе, он работает в виртуалке эрланга. Хотя я сторонник использования раббит как шину для обмена сообщениями между сервисами хотя бы потому, что он на такой обмен заточен. Отправитель кинул сообщение, получатель или получатели тут же его поймали, без необходимости опрашивать базу о новых событиях. Плюс плюшки в виде контроля трафика и политик очередей и по мелочи.
Подскажите, имеет ли смысл отправлять сообщения через интернет? Насколько это безопасно если рабит будет торчать своими портами в мир? Или обязательно его прятать в впн?
В большинстве случаев лучше спрятать его от внешнего мира, по тем же причинам, что и БД прячут.
Если все-таки надо RabbitMQ сделать доступным снаружи, то необходимо коннектиться через ssl ради безопасности, но это добавит приседаний с сертификатами и их обновлением, а также снизит скорость передачи данных
Я бы рекомендовал в комьюнити задать вопрос как правильно сделать https://t.me/rabbitmq_ru, но порты в мир это не вариант, у вас же порты баз данных не торчат наружу (надеюсь).
Как компании используют RabbitMQ