Наверх ▲

Scaling Web Apps With RabbitMQ

Альваро Видела (Alvaro Videla) Альваро Видела (Alvaro Videla) Разработчик ПО в Cloud Foundry at VMware в Швейцарии.

Alvaro Videla: Здравствуйте! Меня зовут Альваро Видела. Я разработчик компании “Liip AG” в Швейцарии. В этом году я работал в Китае в компании, которая создавала веб-сайт знакомств. В этом проекте я использовал RabbitMQ. Сегодня мы будем говорить о масштабировании с помощью RabbitMQ.

У меня есть свой блог и аккаунт в Twitter. Я пишу книгу, которая называется «RabbitMQ в действии». Если почувствуете, что ничего не понятно, задавайте вопросы.

Сегодня мы будем говорить о масштабировании приложений с RabbitMQ. Я поясню, что значит «масштабирование». Мы часто говорим о масштабируемости. При этом миллион пользователей "разогревает" ваш сервер, что поделать. Да, конечно, RabbitMQ может вам помочь и в этом. Но я также считаю, что RabbitMQ может помочь в том, чтобы, не останавливая систему, добавлять новые функции, чтобы работать с большим количеством людей. Обычно когда  трудно управлять всей системой, RabbitMQ нам поможет во всех отношениях.

Какой тут был вопрос? Сервер сообщений и их передача - зачем нам нужен RabbitMQ?

Зачем вообще нужны сообщения? Скажем, мы хотим создать фотогалерею для владельца сайта и обогащения контента веб-сайта. Для нас это работа на полчаса. Но появляются новые требования и проблемы с нагрузкой.

Владелец продукта спрашивает: «Можно уведомлять друзей пользователя, когда он выгружает новое изображение? Это надо сделать завтра».

Гуру социального медиа, может быть, вы мне объясните, что это такое. Я сам толком не понимаю.

Допустим, человек хочет выдавать пользователям бэйджики за каждую выгруженную картинку. Что-то вроде «ты такой замечательный человек». За каждую выгруженную картинку -  значки. Он хочет это использовать в Twitter, т.к. Twitter – самая популярная социальная сеть.

Перейдем к вопросу об администраторе системы.

Администратор обращается к нам: «Глупые люди! Вы отправляете полноразмерное изображение на сайт. Пропускная способность этого не позволяет. Нагрузка на канал возрастает в 3 раза». 

Разработчики в другой команде общаются друг с другом, хотя и нечасто.

Один из них хочет обратиться к сотрудникам PHP, но через Python.

Не стоит забывать о существовании пользователей. Что им не нравится?

Они не хотят ждать, когда приложение изменит размер картинки. «Я пользователь и не хочу ждать, пока твое приложение произведет конверсию изображения. Я хочу просто загрузить картинку сразу. Меня не волнуют ваши проблемы. Я не плачу за ваши личные проблемы», – говорит пользователь.

Мы - разработчики FML. Не знаете, что это значит? Это наш ответ на все проблемы.

Как у нас пишется код?

Скажем, есть обработчик изображений, пишем "ок". Дальше - новое требование: "Изменить размер изображения". Опять через обработчик обращаемся к изображению и меняем размер. После этого мы уведомляем друзей на основе информации пользователя, которая размещена у нас. Позже надо добавлять очки пользователям и сообщать, что есть новое изображение.

Вопрос: наш код масштабируем согласно новым потребностям? А если надо ускорить конверсию изображения? Как масштабировать код? Как делать конверсию изображения параллельно? Как уведомлять по электронной почте, если мы перестаем "твиттить" по поводу новых изображений? Может быть, использовать не Twitter, а Google для этих целей? Изменение размеров для разных форматов и так далее. 

Может ли код, который я вам показывал, масштабироваться? Можем ли мы там изменить что-то коренным образом? Есть ли возможность усовершенствовать проекты? Да, используя сообщения. 

Скажем, если использовать Subscribe Pattern в сообщениях, это значит, что уведомление может размещаться в системе сообщений, куда они поступают. Есть подписчики Subscribe. Они получают уведомления о том, что какое-то событие произошло. 

А если я должен уведомлять пользователя только в случае конвертации картинки? Это более сложный сценарий. Идея такова: если мы создаем сообщение, распространяем уведомления и у нас эта система уже есть, то есть новый подписчик, который знает, как конвертировать изображение в jpeg и другие форматы. Я буду приводить конкретные примеры в ходе своей презентации, чтобы помочь нам в вопросах масштабируемости для адаптации к новым требованиям.

Что касается реализации, то сначала осуществляем выгрузку изображения. Далее получаем информацию о нем, создаем новое сообщение с информацией пользователя и информацией об изображении и публикуем сообщение. После рассылаем уведомление друзьям, что появилось новое изображение. Менеджер, который присуждает очки, добавляет "звездочки" пользователю за использование изображений. 

Дальше – изменение размера изображения, добавление различных элементов.

Во время первой реализации могут меняться подписчики. Контроллер не переустанавливается. В некоторых случаях это неважно, а для некоторых приложений очень важно, когда не надо все переустанавливать.

RabbitMQ и AMQP. Объясню, как работает AMQP, поскольку их хорошо использовать вместе. Можно использовать и специальные библиотеки. Вам надо знать, как с этим работать, если хотите получить преимущества при работе с RabbitMQ.

Как расшифровывается аббревиатура AMQP? Advanced Message Queuing Protocol. Он интероперабельный. В Америке тратили миллионы долларов в год, чтобы обеспечить совместную работу различных систем. Но системы плохо взаимодействовали друг с другом. Надо было все делать вручную. Поэтому был создан  полностью интероперабельный продукт.

Кроме того, AMQP - открытый продукт. Протокол - бинарный. Нет всех дополнительных нагрузок, например, XMPP. Состоит из двух частей: AMQP Model и AMQP Wire Format. В AMQP Model описаны все элементы, которые включены в AMQP. Например, очереди в обмене, комплектация сообщений и так далее. 

 

Модель AMQP. Это обмен, очередность обмена.

Wire Protocol действует на функциональном и транспортном уровне.

Как двигается сообщение в AMQP? В AMQP и RabbitMQ сообщения напрямую в очередь никогда не отправляются. Они всегда поступают сначала в брокер, потом - в обмен и далее - в Exchange. Там проверяются таблицы маршрутизации. Если получаются совпадения, тогда сообщение попадает в очередь. После этого либо мы от него отказываемся, либо оно направляется в Publisher и так далее.

Сообщение может попадать в одну или много очередей. Получатель сообщения может быть один. Адресатов также могут быть сотни.

Существует три типа обмена. Fanout – расширение. Direct – прямое. Topic – тематическое.

Также имеется разветвленный обмен - публикация подписчика, сценарий. Одно сообщение расходится в различные очереди, которые управляются обменом. В данном случае мы не используем ключ маршрутизации.

Что касается прямого обмена, то единственная разница с Fanout заключается в том, что в данном случае мы используем ключ маршрутизации. Из точки - в точку. MSN или подобное ему приложение. Ты знаешь адрес человека, которому отправляешь сообщение и используешь ключ.

Тематический обмен - наиболее продуманная функция. При данном виде обмена сообщения распределяются по темам («США.Новости», «США.Погода», «Европа.Новости» и так далее). Происходит распределение по группам. Определяются требуемые совпадения. Может существовать очередь людей, которых интересуют новости в Европе или США. Дальше – очереди, которые получают информацию только о погоде и Европе и т.д.

Что любопытно? Если завтра вас это больше не интересует, то целую очередь легко убрать. Этим занимается брокер. Если вдруг вам надо узнать что-то новое (например, про Россию), то можно подключить очереди «Россия.Новости», «Россия.Погода», чтобы в дальшейшем отслеживать интересующие новости.

Может быть, это кажется слишком простым. Но если у вас есть приложения, 20-30 серверов и вам нужно всю информацию содержать в одном месте, потом ее фильтровать, в случае ошибки находить нужный хост и т.д, тогда можно использовать данный тип обмена. Около года назад в RabbitMQ появилась возможность быстрой реализации тематического обмена. Сначала было непросто, но сейчас обмен производится очень быстро. Мы рекомендуем его использовать.

Из чего состоит сценарий использования?

Первое – это пакетная обработка, второе – распределенное логирование. Если вы хотите использовать RabbitMQ, осуществлять пакетную обработку, то нам надо знать, как это делать. Нам приходилось делать нечто подобное и в фоновом режиме обрабатывать информацию от пользователей. В реальном времени процесс протекал слишком медленно. Далее я расскажу о распределенном логировании.

При пакетной обработке возникают некоторые требования. Упомянутый ранее пример в данном контексте тоже уместен. 

Всякий раз, когда появляется новая картинка, то генерируется XML и распределяется на кластер для ускорения обработки сообщений.

Также необходима эластичность. Соответственно, добавляем или удаляем новых работников.

При этом мы можем обрабатывать сотни видеоматериалов. Это, кстати, очень важно, потому что когда речь идет о масштабировании. Когда у вас тысяча пользователей, то они все могут зайти на сайт в течение небольшого промежутка времени. Как раз в этот момент и необходимо производить масштабирование. В остальное время можно уменьшать масштаб, чтобы экономить ресурсы.

Что касается дизайна, то он очень простой. Сначала надо сформулировать задание по созданию очереди, за которой следует генерация XML, задается имя обмена и очередь, которая называется “video-description queue”. Все достаточно просто.

В случае с RabbitMQ он посылает сообщения потребителям. Если потребитель падает, он получает сообщение обратно и опять ставит его в очередь. Далее потребителю направляется новое сообщение. Если у вас один или четыре потребителя, то RabbitMQ продолжает взаимодействовать с работниками. Больше ничего делать не надо. 

Однажды мне довелось работать с сайтом в Уругвае, где нам приходилось обрабатывать много изображений. Это был сайт для взрослых. В общем, там надо было конвертировать много картинок. У нас был собственный сервер. Процесс конвертации проходил достаточно болезненно. Если бы мы пользовались RabbitMQ, то делать было бы практически нечего.

Подключаете RabbitMQ, вводите пароль, виртуальный хост. Один пользователь не может получать доступ. По сути, это элемент безопасности. Насколько я знаю, вероятность взлома практически исключена. Когда имя обмена, очереди или другого ресурса в RabbitMQ меняется, надо знать, что все они содержат имя хоста. Таким образом, доступ к информации получить нельзя. 

Всякий раз, когда есть соединение, канал, мультиплекс, который в PHP почти бесполезен, конечно, но с другими языками это возможно. Здесь возможно использование различных каналов как для издателей, так и для потребителей. 

 

Таким образом, по каналу вы объявляете обмен. В PHP код выглядит следующим образом: имя, параметр или запись (англ. record). Соответственно, далее происходит прямой обмен. Вы сообщаете RabbitMQ, что хотите создать коммутатор и чтобы обмен не удалялся, когда запускается сервер.

Конфигурация позволяет сообщить, что «если сервер или потребитель "падает", то я хочу убрать все его ресурсы из очереди». В силу этого на сервере мусор лежать не будет.

Таким образом, создается сообщение и некоторые свойства, например, способ доставки. Последнее очень важно. Здесь указывается тип. Если ставить всего один, то он будет сброшен. Поэтому его нужно ставить в последовательном режиме.

Может быть, у вас есть разные долговременные обмены, коммутаторы. Так что значений тут должно быть два.

Передаете сообщения, говорите, какое сообщение отправлять, ставите параметр RabbitQ и потом закрываете подключение.

На канале открывается соединение. 

Что нужно сделать в RabbitMQ? Вы объявляете все, т.к. объявить – это не то же самое, что создать. Есть определенные причины. На сервере задается вопрос, есть ли обмен. Если нет, тогда его нужно создать.

Но в AMQP используется queue_declare. Сколько у вас потребителей - неважно. Ничего с ними плохого не произойдет.

Мы создаем обмен, очередь и осуществляем пакетирование. Мы обеспечиваем попадание сообщения в требуемую очередь. Если этого не сделать, то сообщения будут потеряны. 

Таким образом, как только у вас готов пакет и определены основные потребители, то вы отдаете тег потребителю. RabbitMQ знает, кто отменяет в случае отмены. Callback – $consumer, последний параметр. Начинаете проводить операции с сообщениями. 

Затем переходим к пакетированию. Что делаем здесь? Если RabbitMQ-сервер не с повышенной нагрузкой и есть кластер (несколько инстанций RabbitMQ), но при этом имеется очередь на одном сервере, то он будет находиться под давлением, когда на него будет направлено много сообщений. Если вы окажетесь в подобной ситуации, то вы можете поставить новую очередь на новый сервер RabbitMQ. Сообщения будут приходить и в старую очередь, и в новую. Там можно "распакетировать" перегруженный сервер, сбросить очередь и вернуть ее обратно. BindMQ подобную гибкость при высоких нагрузках не гарантирует.

Следующий сценарий – распределенное логирование. Среди требований - наличие нескольких веб-серверов. Логика распределена по модулям или действиям. Кроме того, существует несколько уровней логов: информация, предупреждение и ошибка.

 

Можно по желанию добавлять или удалять слушателей логов. Например, если проблема возникла на сервере 20, и вы подключаетесь к этому серверу, начинаете получать оттуда информацию. Когда проблема решена, можно многое удалить, однако нет необходимости удалять все очереди. Не нужно смотреть, что используется больше или что удалено. В данном случае это одна из целей дизайна.

Да, мы не хотим менять код постоянно. Допустим, к нам поступает сообщение лога. Затем в логе будет прописан ключ Rabbit, где находится модуль действия. Далее следует сама информация: какое событие вы хотите заносить в лог? В зависимости от ключей, сообщение поступит в ту или иную очередь.

Если я отправлю сообщение с ключом server1.home.index.info и так далее (то есть событие на первом сервере), то в модуле "home" индекс действия был "info". Соответственно, первый слушатель получает все логи, которые поступают по нескольким .sharp. Какой модуль - неважно.

С другой стороны, если отправить сообщение server2.index.error (т.к. он просматривает каждое сообщение об ошибке, которое поступает с любого сервера, где был создан лог), то первый из них сообщение не получил. 

Сообщение может направляться в разные очереди. Возможно использование нескольких ключей. Например, Profile.info.

Знак "sharp" соответствует одному или нескольким значениям. «Звездочка» – это одно слово, используемое не как в обычных выражениях. Это меня запутало, когда мы начинали заниматься EPN. В общем, пользовательский профиль тоже не имеет значения, потому что там содержатся ошибки, и информация продолжает поступать, что бы в модуле ни происходило. У вас есть это приложение, и вы хотите знать, получает ли новая функция (например, выгрузка сообщений) хиты. Тогда у вас может быть временный лог с требуемой информацией. Вы вживую сможете видеть, что происходит на сайте. Когда вы устали, можно оставить консоль. RabbitMQ позаботится о том, чтобы удалить все, что там было.

 

Наконец, последний случай - когда мы посылаем сообщение об ошибке. В данном случае пользователь не равен администратору.

Код издателя практически такой же. Мы получаем подключение и канал, объявляем коммутатор и обмен.

В server1.user.profile.info- последняя строка не открыта.

 

Соответственно, если вы хотите получать сообщения хоста, то объявляете обмен, очередь и далее пакетируете данные.

Что мы хотим сказать RabbitMQ? Как только я закрываю подключение и потребитель ушел, удалите данную очередь, "сбрасывайте" пакет.

 

Мы предоставляем схему с тегом "server1.profile" и так далее. Можно использовать "звездочку" или "решетку". Вы называете сообщение "sharp error". 

Настройка для RabbitMQ или дерепликации - одна. Выпуск произошел один или два месяца назад. Есть несколько способов добиться более высокой готовности RabbitMQ в плане вариантов использования. В большинстве случаев, если вы читаете лист меню, то говорите: «Я никаких сообщений терять не хочу». А вдруг у вас загорелся дата-центр, что будете делать?

В данном случае можно использовать следующие настройки. Если порядок сообщений вас не особенно беспокоит, можно обрабатывать информацию пакетами на сервере. В результате восстанавливается баланс и все "рабочие" подключены. Но есть машины потребителей. С ней вы идете в RabbitMQ A, а другой "рабочий" потребляет ту же информацию с RabbitMQ B. 

Так как издатель не знает, куда будет направлено сообщение сервер RabbitMQ будет выбираться случайным образом, поэтому вы не будете знать, откуда получать информацию. У вас два "рабочих" - на каждую очередь. Им нужно настраивать ту же самую информацию для серверов RabbitMQ. Когда вы размещаете новый RabbitMQ C, то если у вас есть скрипт или потребитель, он объявляет все это и настроит ту же среду или RabbitMQ B.

Какие преимущества приобретает система? Когда мы переходили на RabbitMQ, у нас был RabbitMQ с нижнего баланса. Он дренировал весь сервер, сбрасывал все сообщения с Rabbit, не получая новых публикаций. Как только на сервере не оставалось сообщений, устанавливалась новая система и проводилась модернизация. Далее мы опять настраивался баланс и обработка происходила уже на втором сервере и т.д.

В RabbitMQ можно также осуществлять кластеризацию. Кластеры по умолчанию обычно создаются для того, чтобы осуществлять масштабирование по логам, которые поступают с сервера, не увеличивая нагрузки. В этом случае RabbitMQ использует нишевую базу данных (компоненты, сконструированные в Rabbit). 

Для кластеризации RabbitMQ использует ниши для распределения сообщений. Возможно, ваш системный администратор захочет ознакомиться с документацией по конфигурации. Ранние версии RabbitMQ создавали определенные неудобства, но к сегодняшнему дню ситуация, конечно, изменилась к лучшему. Что можно было делать с cookies, когда в те времена приходили скрипты с сообщениями об ошибках? Сейчас, конечно, проблема решена. 

Если вы знаете язык, то администрировать данные легче. Распределению должна подвергаться вся информация - так проще. Но в RabbitMQ при кластеризации сервера очередь будет оставлять только первый сервер, на котором она была объявлена. Например, у вас падает RabbitMQ B. Если у него была своя очередь, то все, до свидания. Никакой репликации нет.

Теперь у нас есть зеркальные очереди, родной и зеркальный кластеры. Конечно, все работает в зависимости от поведения пользователей. Если надо добиться максимальной скорости, а информацию потерять не боитесь, тогда, наверное, не стоит использовать кластеризацию. Она оказывает влияние на то, как доставляются сообщения. Если для вас очень важно быстродействие, можно использовать режим "acknowledgement". Каждый раз, когда у вас появляется сообщение, отправляете его на сервер, обрабатываете и переправляете напрямую из сервера.

Если работать в другом режиме, то существует много иных возможностей для ускорения процесса. Как только сервер получает сообщение, а сервер видит пользователя, которому надо направить его отправить (эти пользователи или потребители не должны подтверждать получение), тогда сообщение будет направляться не в очередь, а напрямую к пользователю.

Может быть, в тех случаях, когда вас не очень волнует, теряете вы сообщения или нет, RabbitMQ не будет тратить время на то, чтобы направлять сообщение в очередь. Он передаст его непосредственно пользователю. Конечно, имеется очередность, формируемая в памяти, которую также можно использовать в наших целях. 

Что нужно прояснить? В большинстве случаев конфигурируется не RabbitMQ, а запускается сервер. Существуют настройки по умолчанию. Например, RabbitMQ 1 берет один процесс Erlang, один канал, одного пользователя и так далее. По умолчанию RabbitMQ реализует около миллиона процессов Erlang. Но данную характеристику можно изменить. То же самое касается и памяти.

Конфигурация может касаться с том числе пользователей. 

Что касается производительности, то RabbitMQ работает более эффективно с большим количеством очередей сообщений. Не стоит использовать их, например, с базами данных. Если начинаешь заполнять RabbitMQ множеством сообщений, то начнут возникать проблемы, но мы меняем ситуацию к лучшему.

Что можно получить, используя RabbitMQ или другие решения по работе с сообщениями?

Во-первых, гибкость в архитектуре и возможность дополнительного использования новых ресурсов. Как только количество сообщений доходит до критической отметки, начинают возникать сложности. RabbitMQ в этом вам, конечно, может помочь.

Во-вторых, хорошая масштабируемость. Русурсы можно перераспределять без проблем для публикации. Сообщения могут направляться в одну или множество очередей. Но далее у нас может приходится по одному или сотне пользователей на каждую очередь. Надо помнить, что сначала сообщения попадают в очередь, а после этого – к пользователю. Здесь масштабируемость играет важную роль: конфигурацию можно настраивать. Например, установить максимум на обработку 40 или 50 сообщений. Тогда RabbitMQ будет действовать соответствующим образом. Поскольку имеется архивация сообщений, то все сообщения можно обрабатывать одновременно (сразу 50). 

В-третьих, интероперабельность. PHP используется часто. Но, может быть, некоторые из вас используют Java из соображений быстродействия. Необходимо только располагать библиотекой, соответствующей используемому языку.

В-четвертых, сокращаются эксплуатационные расходы. У меня был SQL-сервер, которым было сложно управлять. Мы создали пользователя, что облегчило и удешевило процесс. 

Спасибо за внимание!

Вопросы и ответы

Вопрос из зала: Из приведенного примера следовало, что сообщения поступают в очередь. Их лучше реже отправлять напрямую. Вопрос: что вы скажете насчет размера сообщений и как лучше управляться с ними?

Alvaro Videla: Я считаю, что метаинформацию надо рассылать по изображению, а не отправлять само изображение. Следует направлять идею об изображении в базу данных, а не пересылать все сообщение целиком. Некоторые специалисты используют RabbitMQ подобным образом, но я не считаю, что это оптимально.

Вопрос из зала: Какая разница между использованием RabbitMQ и ActiveMQ?

Alvaro Videla: Они используют разные протоколы. В ActiveMQ - это Stomp, очень базовый протокол. Он не предусматривает концепции очередей, обмена и пр. Можно создать требуемые функции в отдельном порядке, но это не очень удобно. Также возникали проблемы с клиентами PHP. 

Может быть, у меня были не совсем точные настройки в ActiveMQ, компьютеру приходилось тяжело. RabbitMQ – около 12 тысяч сообщений в секунду без проблем. Кроме того, нам надо было реализовать приложение Erlang. Мы оценивали возможности работы в реальных условиях. По моему опыту работы в Китае, RabbitMQ работал очень хорошо.

Вопрос из зала: Для C# есть клиентская библиотека?

Alvaro Videla: Да, там много клиентов RabbitMQ. Официально это C# 1 и еще одна - для Java. Когда выходит новый релиз RabbitMQ, они дополняют новым клиентом. Erlang сделан для RabbitMQ, но пока официально не поддерживается. Библиотека Ruby тоже сейчас официально уже поддерживается (и в России эта библиотека тоже уже работает). Есть еще другие проекты по другим библиотекам.

Вопрос из зала: Можно ли сравнить RabbitMQ и ZeroMQ c C++ API?

Alvaro Videla: Насчёт C++ я не владею информацией. Есть библиотека "Cи", которая сделана для RabbitMQ, но официально не поддерживается. Не знаю, как будет работать с C++. Вопросы есть, но ответов на них пока нет. 

Можно ли сравнить ZeroMQ и RabbitMQ? Там 0 в начале, нет очереди. В том смысле, что используется брокер, как в RabbitMQ. В RabbitMQ есть библиотека, которая работает с сокетами, различными соединениями. Там легче структурировать вещи нижнего уровня, если хочешь подключить приложение к разным серверам. Можно обеспечить коммуникацию между различными процессами. Кроме того, есть схемы передачи сообщений (то, что делается в RabbitMQ). ZeroMQ тоже это делает. 

Я считаю, что ZeroMQ – это нижний уровень. Он работает быстрее, поскольку создан специально для этого. Но он не дает требуемых гарантий. Если происходит сбой, то сообщения теряются. 

Кроме того, все сообщения в RabbitMQ проходят через маршрутизатор. В ZeroMQ такого разрыва нет, как нет и проблем со связью. Все зависит от того, что какую задачу требуется выполнять. Можно переходить от одного сервера к другому, к RabbitMQ. Соответствующие команды работают вместе - это открытые проекты. 

Если у вас есть приложения, которые по каким-либо причинам (непример, из-за энергопотребления) вас не устраивают, можно использовать ZeroMQ или мост, который связал бы его с RabbitMQ. При необходимости их можно использовать вместе. 

Вопрос из зала: Как управлять памятью в ситуации, когда все клиенты неожиданно "падают", а публикации продолжаются? В RabbitMQ это может отнять всю память системы. Как в такой ситуации следует поступать?

Alvaro Videla: Как вы используете RabbitMQ? Текущая версия RabbitMQ не должна "съесть" всю память. В предыдущих версиях (год-полтора назад) имелась ошибка, но мы ее исправили. Ошибка была связан с ситуацией, когда требовалось все больше и больше памяти. Использование Erlang позволяет решить данную проблему. 

Новой версии RabbitMQ уже больше года. Все сообщения отправляются на жесткий диск. Если очень много потребителей, конечно, они накапливаются и память будет "съедаться". Подобное случалось в прошлом, но сейчас – нет. На данный момент существует регулируемая граница объемов памяти сервера, которая используется под упомянутые нужды. Когда лимит исчерпан, ты получаешь предупреждение от RabbitMQ и принимаешь решение, что делать дальше. 

Да, потребители "падают". Но, по крайней мере, ты получаешь заблаговременное предупреждение. Можно предпринимать различные меры, например, перенаправить трафик на другой RabbitMQ. Конкретных рекомендаций я не дам.

Комментарии

Нет ни одного комментария

Только пользователи могут оставлять комментарии

Возможно, вам будет интересно:

Сэнди Гупта (Sandy Gupta)

Сэнди Гупта (Sandy Gupta)

Главный руководитель Open Solutions Group (OSG) в Microsoft.

Сэнди Гупта (Microsoft) расскажет о стратегии Microsoft по упрощению разработки "облаков" и по созданию возможностей для ПО с открытым исходным кодом.

Ярослав Ворожко

Ярослав Ворожко

CEO & Founder of IndexDen в IndexDen.

Ярослав Ворожко (Ivinco) делится опытом работы с Real Time индексами.

Андрей Ситник

Андрей Ситник

Ведущий фронтендер в Злых марсианах. Автор Автопрефиксера и PostCSS.

Андрей Ситник (Evil Martians) о том, что анимация и 3D - это не только промо, но и юзабилити.