|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
Вот "клетчатый" что-то вещает по теме. Интересно. Добавил в заметку Tarantool, NATS. [spoiler] ... |
|||
:
Нравится:
Не нравится:
|
|||
05.10.2021, 23:06 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
mayton Пускай вадя поднимет отдельную тему про "свои сокеты". Я думаю это будет справедливо. т.е. это простой канал связи, а что по нему передается и как используется переданное - это уже дело фантазии и опыта прогера. единственное отличие - трафик. Но это не главное в данном случае. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.10.2021, 05:25 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
Все эти доклады в основном преследуют одну цель - улучшить имидж компании или конкретного человека. Никто не будет делиться с вами реально ценными решениями, ибо незачем плодить конкурентов. На примере тех брокеров - решение из коробки во многих случаях плохо работает, если его не допилить и не обвешать своими костылями. А.вот как это сделать, вам как раз не расскажут в деталях - а это самая ценная информация. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.10.2021, 12:00 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
Roman Osipov, В данном случае целью докладчика явно была реклама Tarantul от mail. Не упоминалось те же Hazelcast и Ignite, которые явно не хуже, а может и получше Tarantul в качестве брокеров будут работать. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.10.2021, 12:12 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
Roman Osipov Roman Osipov, В данном случае целью докладчика явно была реклама Tarantul от mail. Не упоминалось те же Hazelcast и Ignite, которые явно не хуже, а может и получше Tarantul в качестве брокеров будут работать. Дружище. Ты с Ignite совсем промахнулся. Я работал с Ignite. Это key-value распределенное хранилище с богатыми возможностями распределенных вычислений. Оно не позиционируется как брокер очередей. Насчет Hazelcast - не знаю. Но тоже сомнительно. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.10.2021, 13:06 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
mayton, хороший такой подход к сравнению: "возьмём что-то изкаробки, потом возьмём тарантул, кастомизируем его под задачу и вуаля, будет быстрее и надёжнее" :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
06.10.2021, 13:25 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
Я вот смотрю щас на сайт тарантула. Его юз-кейсы. Или паттерны, как там пишут. Надо в самый низ проскроллить. https://www.tarantool.io/en/patterns/ Persistent Queues Вот. Значит этот инструмент - не только key-value система но и также является брокером. Это заявлено. Что он где хранит. Какой API предоставляет. Можно ли интегрироваться с ним "извне" - это отдельные вопросы. Но главное что фича заявлена. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.10.2021, 13:36 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
mayton, https://ignite.apache.org/docs/latest/data-structures/queue-and-set Изучай на здоровье. А Hazelcast у нас очень много где и очень долго стабильно как брокер в продакшене работает. Распределенный, отказоустойчивый, горизонтально масштабируемый и очень быстрый. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.10.2021, 13:37 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
Roman Osipov, https://ignite.apache.org/features/messaging.html В догонку. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.10.2021, 13:41 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
Roman Osipov mayton, https://ignite.apache.org/docs/latest/data-structures/queue-and-set Изучай на здоровье. А Hazelcast у нас очень много где и очень долго стабильно как брокер в продакшене работает. Распределенный, отказоустойчивый, горизонтально масштабируемый и очень быстрый. Хм... ну. Может быть. Как-жеж они ее персистят? Только на memory надеются? На избыточность? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.10.2021, 13:41 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
mayton, Да, надежность обеспечивается репликацией очередей по нодам. В случае полного отказа есть заперсистенные статусы доставки сообщений, по которым выполняется восстановление состояния брокера. Потерь не будет, максимум получим дубли. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.10.2021, 13:48 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
Да как-то дороговато выходит. Я понимаю роль Ignite в кешировании например базы крупного банка. А ты смотрел лекцию "клетчатого" выше по ссылке? По его мнению идеальная метрика любой очереди в кластере - это пустая очередь. Я с ним согласен. Это - цель к которой нужно двигаться. Но Ignite в этом use-case выглядит фурой в которую положили 1 мешочек картошки. Или очередь в данном сценарии является просто не главной ролью Ignite Cluster а просто чем-то вспомогательным. Тоесть мы долгжны перевести все вычисления в Ignite Cluster и только после этого эта фича (бантик сбоку) как говорил мой коллега вдруг станет рациональным. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.10.2021, 13:53 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
mayton, Это только по его субъективному мнению. Но жизнь такая, что иногда не все консьюмеры всегда онлайн и в состоянии выгрести очередь. Выходит очень даже дешево - аналогичные по скорости и надежности решения обычно требуют гораздо большего железа, я знаю о чем говорю, видел разные варианты. Фишка Ignite и Hazelcast в том, то на паре нод можно отказоустойчиво обрабатывать сотни тысяч очередей. Тот же RabbitMQ сдохнет примерно на 5000 очередей. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.10.2021, 14:02 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
Roman Osipov Фишка Ignite и Hazelcast в том, то на паре нод можно отказоустойчиво обрабатывать сотни тысяч очередей. Тот же RabbitMQ сдохнет примерно на 5000 очередей. А мы рассматриваем одинаковые конфигурации железа? Мне просто сомнительно такое сравнение. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.10.2021, 14:05 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
mayton, Да, именно одинаковые конфигурации. Дело в том, что у RabbitMQ на каждую очередь работает отдельный программный тред. И когда их становится много, то переключения контекстов начинают жутко тормозить. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.10.2021, 14:08 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
Roman Osipov mayton, Да, именно одинаковые конфигурации. Дело в том, что у RabbitMQ на каждую очередь работает отдельный программный тред. И когда их становится много, то переключения контекстов начинают жутко тормозить. Хорошо. Давайте отложим этот разговор. Я просто принимаю как должное от вас тот факт что RabbitMQ может лопнуть от 5000 очередей. Хотя мне это кажется странным ибо Erlang... ну ладно. Когда доберусь до кролика я проверю этот забавный факт. Кроме того любая программная конфигурация при 5000 * 2 открытых сокетов уже ведет себя плохо. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.10.2021, 14:20 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
mad_nazgul mayton Привет коллеги. Является ли это хайпом или технолгическим витком? Чта?! Хайп MQ? Мне казалось, что хайп на MQ прошел лет 10 назад. Щас хайп это GraphQL и gRPC. Щас у нас на проекте активно избавляются от REST и переходят на GraphQL для фронта. А микросервисы между собой общаются по gRPC. Только где-то в уголке притаилась Kafka. <:o) кафка осталась в паре моментов - например что то выгрузить нам в систему,в остальном есть варианты лучше ... |
|||
:
Нравится:
Не нравится:
|
|||
06.10.2021, 20:35 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
Roman Osipov, > Дело в том, что у RabbitMQ на каждую очередь работает отдельный программный тред Можешь ткунуть в доку? Всегда считал что thread per client channel. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.10.2021, 22:33 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
kolchanov, Вот https://github.com/rabbitmq/internals/blob/master/queues_and_message_store.md Each queue is a gen_server2 Erlang process. The usual pattern of the API and implementation being in one file is not applied; rabbit_amqqueue is the API (a module) and rabbit_amqqueue_process is the implementation (a gen_server2). И вот https://www.cloudamqp.com/blog/part1-rabbitmq-best-practice.html Number of queues Queues are single-threaded in RabbitMQ, and one queue can handle up to about 50 thousand messages. You will achieve better throughput on a multi-core system if you have multiple queues and consumers and if you have as many queues as cores on the underlying node(s). ... |
|||
:
Нравится:
Не нравится:
|
|||
06.10.2021, 23:13 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
Roman Osipov, >Each queue is a gen_server2 Erlang process. Мне всегда казалось, что erlang процесс это не thread. В све время, когда писал на erlang, запусал на моей рабочей машине несколько десятков тысяч процессов, без каких то проблем с производительностью. В интернетах тоже пишут: Erlang processes are not OS processes. They are implemented by the Erlang VM using a lightweight cooperative threading model (preemptive at the Erlang level, but under the control of a cooperatively scheduled runtime). This means that it is much cheaper to switch context, because they only switch at known, controlled points and therefore don't have to save the entire CPU state (normal, SSE and FPU registers, address space mapping, etc.). >Queues are single-threaded in RabbitMQ, and one queue can handle up to about 50 thousand messages. You will achieve better throughput on a multi-core system if you have multiple queues and consumers and if you have as many queues as cores on the underlying node(s). Тут написано, что одна очередь обрабатывается одним потоком, но не то что на каждую очередь создается отдельный поток. Т.е. ИМХО фраза "Дело в том, что у RabbitMQ на каждую очередь работает отдельный программный тред" некорректна ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2021, 07:22 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
kolchanov, В общем согласен, что выразился неточно. Но сути особо это не меняет. Да, программные процессы erlang более легковесны чем программные потоки ОС, но когда их становится много, то переключения контекстов начинает сильно сказывается на производительность. Чем больше очередей, тем медленнее работает. И зависимость производительности от количества очередей не линейная. Я ставил опыты на машине с 4 процессорами и 16ГБ RAM. Примерно на 5000 очередей и наступал этот самый момент сильной деградации. Ну и поток потоку рознь, может быть в RabbitMQ в реализации есть узкие места и что-то тормозит из-за этого. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2021, 10:15 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
Roman Osipov, И если сравнивать Rabbitmq с тем же Hazelcast, то грубо говоря у последнего нет такого неприятного свойства, как зависимость производительности от количества очередей. Понятно что для Hazelcast если исчерпается память то будет краш, но это надо предусмотреть. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2021, 10:24 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
Roman Osipov то переключения контекстов начинает сильно сказывается на производительность. Тоже по идее такого не должно быть. Эрланг проектировался в далекие 80-е когда мультизадачность была основана не на потоках а на более примитивных сущностях. Прерывания ввода-вывода. Корутины. В идеале если на вход сетевого интерфейса ничего не поступает то и Erlang-потоки должны потреблять абсолютный ноль мегафлопов. Вобщем надо смотреть условия эксперимента. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2021, 10:28 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
Roman Osipov, Ну дак минус в тормозах покрывается другими 30 - тью характеристиками. Надо же комплексно. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2021, 10:37 |
|
|
start [/forum/topic.php?fid=59&msg=40102305&tid=2120331]: |
0ms |
get settings: |
28ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
57ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
536ms |
get tp. blocked users: |
1ms |
others: | 374ms |
total: | 1027ms |
0 / 0 |