VA
ну пусть удалённая нода пушнет ответ в топик. не вижу проблемы.
Так и делают)
Size: a a a
2019 November 14
VP
и вообще, очередь сообщений - сердце системы. его плотно мониторят, зеркалируют или как-то иначе резервируют. если кто-то что-то не читает и сообщения копятся, то мониторинг сразу станет пищать (а у MQ обязан быть мониторинг).
VA
там персистенс есть для такого. ну и да, кролика не запускают на серверах с 1 Гб ОЗУ.
Я слышал от товарищей, что при высокой нагрузке порой кролик не выдерживает и у него зависают очереди.
Е
а если между двумя нодами происходит интесивный RPC, то чем мне поможет rmq?
Е
Valdemar Astakhoff
Я слышал от товарищей, что при высокой нагрузке порой кролик не выдерживает и у него зависают очереди.
мы не обсуждаем высокую нагрузку. две ноды
VA
а если между двумя нодами происходит интесивный RPC, то чем мне поможет rmq?
Ничем, mq не для этого
VP
Valdemar Astakhoff
Я слышал от товарищей, что при высокой нагрузке порой кролик не выдерживает и у него зависают очереди.
на хайлоаде пару лет назад был хороший доклад, как правильно готовить кролика. там у докладчика всё хорошо работало, да так, что они в сетевой интерфейс по скорости упёрлись.
так что надо смотреть что там товарищи делают.
так что надо смотреть что там товарищи делают.
VP
а если между двумя нодами происходит интесивный RPC, то чем мне поможет rmq?
тут MQ вообще не нужен. любой RPC-over-чтото подойдёт.
VP
рекомендую всё-таки прочитать, зачем нужен MQ.
VA
рекомендую всё-таки прочитать, зачем нужен MQ.
+
Е
Valdemar Astakhoff
Ничем, mq не для этого
наконец-то кто-то это сказал, rmq - это решение для определенных сценариев, а не панацея от всех распределенных проблем.
Е
рекомендую всё-таки прочитать, зачем нужен MQ.
почитайте начало дискуссии, там речь совсем не о том для чего нужен MQ
AK
почитайте начало дискуссии, там речь совсем не о том для чего нужен MQ
Суть дискуссии в том что ты хочешь кластеризацию без mq. Что несколько бессмысленно
Е
лично у меня ситуация такова, что в случае падения одной ноды, система не может штатно продолжать работу. Пока нода лежит, остальные должны приостановить свою деятельность и тупо ждать пока она поднимется. Нахуя мне тут MQ?
AK
Тогда тебе и кластер не нужен.
И давай без матов, ок?
И давай без матов, ок?
VP
ЕМНИП у Эрланга есть механизм failover/takeover, когда одна нода с приложениями пашет, а вторая висит в горячем стендбае, и если первая не отвечает на хертбиты, вторая начинает работать вместо первой. Как первая очнулась, вторая снова уходит в стендбай. Работает внутри обычного эрлангового кластера. Детально механизм не помню, лучше почитать оф.доку.
a
Simon Khaskelberg
Как по мне, так не хватает хороших примеров distributed elixir. Что-то что выходит за рамки банальных Node.connect и Task.async, которые почти в каждом туториале по distributed elixir фигурируют
Вы же, надеюсь, помните, что Elixir работает поверх Erlang, а потому практики из второго _полностью_ применимы в первом?
Е
Тогда тебе и кластер не нужен.
И давай без матов, ок?
И давай без матов, ок?
я не знаю, может быть ты в слово "кластер" вкладываешь какой-то особый смысл. Если маты тебя напрягают, то ок буду без матов, хотя здесь вроде частенько матерятся все.
a
Стоит просто вспомнить об относительно недавно вышедшей книге от Чезарини, которая, между прочим имеет это в названии
https://www.amazon.com/Designing-Scalability-Erlang-OTP-Fault-Tolerant/dp/1449320732/ref=mp_s_a_1_3?keywords=distributed+erlang&qid=1573712811&sr=8-3
https://www.amazon.com/Designing-Scalability-Erlang-OTP-Fault-Tolerant/dp/1449320732/ref=mp_s_a_1_3?keywords=distributed+erlang&qid=1573712811&sr=8-3
VA
на хайлоаде пару лет назад был хороший доклад, как правильно готовить кролика. там у докладчика всё хорошо работало, да так, что они в сетевой интерфейс по скорости упёрлись.
так что надо смотреть что там товарищи делают.
так что надо смотреть что там товарищи делают.
А долго ли кролик может безотказно работать в таком режиме?