Комментарии 30
Только не НЛП, а NLP.
Это такие же разные вещи как SEO и СЕО
Это такие же разные вещи как SEO и СЕО
Оффтоп: замечательно, что вы выкладываете презентации с HL++. Но не могли бы вы наконец-то выложить видео с РИТа этого года? В канале в слаке вас все очень ждут :)
Выложим, уже вторая итерация проверки подходит к концу. Мы слишком придирчивый заказчик :)
Ага.
Оффтоп: ах этот Century Schoolbook на слайдах с его уродливой «з» без верхней засечки.
Не знал про ограничения пропускной способности по типам настроек, надо будет взять на заметку. Очень полезная статья для программиста, на которого свалилась часть задач архитектора…
Единственное, чем расстраивает Rabbit — порой отъедает 60% CPU в состоянии неактивности.
Точно наблюдается под Windows.
Говорят, читает свои логи…
Точно наблюдается под Windows.
Говорят, читает свои логи…
Это все хорошо, но кролик не умеет апгрейдиться без остановки сервиса. А занчит надо городить обходные пути уровнем выше. А после всего этого понимаешь что zmq ложится в систему гораздо лучше.
zmq вроде не обеспечивал надежности, все только в памяти. Что то поменялось?
Думаю что нет. Но кролик тоже ничего вам не обеспечивает.
Ну лично мне обеспечивает, может у Вас с ним другие отношения ) https://www.rabbitmq.com/persistence-conf.html
1) Сталкивались с тем, что в определенный момент, когда начинается сброс на диск, запись остается на уровне 20к/s
чтение замедляется очень сильно — 1к/s. (характеристики машины сейчас не приведу, добиться на приведенной выше конфигурации будет несколько сложнее)
2) Надо использовать Consumer, basicGet — не лучший выбор.
Есть еще тонкость когда Consumer stateless, но обработка входного потока должна быть гарантированно упорядочена, точнее выходной поток должен иметь порядок входного,
с одной стороны какой же тут stateless?! А такой… явного состояния в обработчике нет, и в persistent к которому обращается обработчик тоже. В этом случае при использовании несколько consumer на очередь, порядок мы не гарантируем.
Если же мы разносим сообщения по разным очередям, придется использовать только один consumer, либо упорядочивать
сообщения где-то после этого шага в конвеере)
чтение замедляется очень сильно — 1к/s. (характеристики машины сейчас не приведу, добиться на приведенной выше конфигурации будет несколько сложнее)
2) Надо использовать Consumer, basicGet — не лучший выбор.
Есть еще тонкость когда Consumer stateless, но обработка входного потока должна быть гарантированно упорядочена, точнее выходной поток должен иметь порядок входного,
с одной стороны какой же тут stateless?! А такой… явного состояния в обработчике нет, и в persistent к которому обращается обработчик тоже. В этом случае при использовании несколько consumer на очередь, порядок мы не гарантируем.
Если же мы разносим сообщения по разным очередям, придется использовать только один consumer, либо упорядочивать
сообщения где-то после этого шага в конвеере)
Меня всегда удивляло когда люди после осознания того, что им мало условных 35к сообщений в секунду с RabbitMq начинают городить огороды оптимизаций конфигурации и шардинг, вместо того, чтобы просто взять ZeroMQ, у которой бенчмарки выдыют миллионы сообщений в секунду. Из аргументации в статье — «ну мы же не сможем там залезть в середину». А чего туда лезть, если оно со старта работает в 50 раз быстрее вашего RabbitMQ?
Вам нужна гарантированная доставка сообщений. Каким образом вы обеспечите такую возможность с помощью ZeroMQ?
Вы так говорите, как-будто ZeroMQ это какая-то студенческая поделка на UDP-сокетах, а не решение промышленного уровня, которым на всяких там андронных коллайдерах терабайты данных ежедневно гоняют.
ZeroMQ вполне себе гарантирует и целостность каждого сообщения, и порядок их доставки. И работает нормально, пока работает железо. С момента отказа сети\памяти\диска\процессора действительно можно не рассчитывать на гарантированность доставки, но кто скажет, что с RabbitMQ у вас в этих обстоятельствах всё будет 100% в порядке — пусть первый бросит в меня камень.
ZeroMQ вполне себе гарантирует и целостность каждого сообщения, и порядок их доставки. И работает нормально, пока работает железо. С момента отказа сети\памяти\диска\процессора действительно можно не рассчитывать на гарантированность доставки, но кто скажет, что с RabbitMQ у вас в этих обстоятельствах всё будет 100% в порядке — пусть первый бросит в меня камень.
Совсем нет, я говорю, что это немного разные вещи.
Основной кейс очередей — отправить в нее сообщение и недеятся, что какой-либо воркер его обработает (возможно не быстро), когда освободится, а если произошла ошибка — вернуть сообщение обратно в очередь.
ZeroMQ это просто высокоуровневые сокеты и как можно ими сделать то, что умеет Rabbit я не представляю. Если объясните, то спасибо.
Основной кейс очередей — отправить в нее сообщение и недеятся, что какой-либо воркер его обработает (возможно не быстро), когда освободится, а если произошла ошибка — вернуть сообщение обратно в очередь.
ZeroMQ это просто высокоуровневые сокеты и как можно ими сделать то, что умеет Rabbit я не представляю. Если объясните, то спасибо.
Высокоуровневые сокеты не совсем верное название, более правильное — набор примитив для передачи сообщений. Нужна гарантированная доставка — реализуй на этих примитивах свой протокол, this is how it works. Btw, в обычном AMQP 0.9 даже подтверждений доставки нет. У RabbitMQ свое расширение — https://www.rabbitmq.com/confirms.html.
Очень не хватает статьи со сравнением всех этих, как верно отмечено, многочисленных Message broker-ов.
У Apache их вообще два!
У Apache их вообще два!
Уже как минимум три — Qpid, ActiveMQ, Artemis (бывший HornetQ). Если kafka и прочих не-AMQP'шных не считать.
А, ещё про Apollo забыл, который емнип забросили в пользу Artemis.
Вообще на самом деле сравнивать особо нечего — ActiveMQ медленный из за синхронной архитектуры (они вроде скрещиваются с Artemis чтобы это побороть, но кажется что там в ближайшие N лет вряд ли будет что-то production-ready, проще HornetQ взять, хотя могу ошибаться), Qpid юзабелен скорее как набор библиотек а не готовый брокер. Остается мейнстрим — RabbitMQ, и кажется что других вариантов с AMQP нет.
Если интересны альтернативы — http://queues.io/.
Вообще на самом деле сравнивать особо нечего — ActiveMQ медленный из за синхронной архитектуры (они вроде скрещиваются с Artemis чтобы это побороть, но кажется что там в ближайшие N лет вряд ли будет что-то production-ready, проще HornetQ взять, хотя могу ошибаться), Qpid юзабелен скорее как набор библиотек а не готовый брокер. Остается мейнстрим — RabbitMQ, и кажется что других вариантов с AMQP нет.
Если интересны альтернативы — http://queues.io/.
Верно подмечено. Этих брокеров много и сложно понять, какие же когда лучше следует использовать, особенно человеку, только погружающемуся в эту тематику. Где бы что почитать на эту обзорную тему?
Хотелось бы добавить, что также можно использовать приоритезацию в очередях, а еще исходя из опыта лучше не держать очереди только в памяти, а писать на диск, так как есть риски их потерять, в конце концов можно использовать SSD, чтобы не проигрывать сильно во времени при передаче запросов.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
101 способ приготовления RabbitMQ и немного о pipeline архитектуре