Вскрываем «кролика»: внутренняя архитектура RabbitMQ

«Вскрываем «кролика»: внутренняя архитектура RabbitMQ» от нашего постоянного докладчика Alvaro Videla.

RabbitMQ — сервер сообщений и очередей, реализованный на Erlang. В этом выступлении рассмотрено, как RabbitMQ использует Erlang и open telecom platform (OTP) для построения высоконадежного брокера сообщений.

Мы представим обзор следующих областей:

Система загрузки RabbitMQ: как происходит загрузка брокера до готовности к приёму сообщений. День из жизни сообщения: путь сообщения при прохождении через RabbitMQ. Собственное хранилище сообщений RabbitMQ: постоянные сообщения, переходные сообщения и кэш в памяти для быстрой доставки. Деревья супервизора, поведение RabbitMQ, и многое другое. Если вам интересно, что находится внутри устойчивого Erlang-приложения, вам стоит посетить это выступление.

Другой наш постоянный докладчик — James Golick представит доклад «Проблемы с выделением памяти» (не забываем — он хакер).

Является ли выделение памяти «узким местом» вашего приложения? Если это так, известно ли вам об этом? Если вам это известно, знаете ли вы, как это исправить?

Хотя malloc API относительно небольшой, современные распределители памяти должны решать множество проблем. Производительность, фрагментация и масштабируемость часто являются противоположными целями, и выигрыш в одном может привести к потере в другом. Более того, изменение, улучшающее производительность распределителя памяти, иногда может ухудшать производительность приложения, которое выделяет память.

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

Надеюсь, что к концу моего выступления вы сможете ответить «да» на вопросы, которые были приведены в начале тезисов моего доклада.

И ещё один наш постоянный докладчик — Joe Domato раскроет совершенно новую для нас тему — «Масштабирование скомпилированных приложений».

Когда мы слышим слово «масштабирование», мы обычно думаем о сервисах back-end, базах данных и даже о центрах обработки данных. Но что происходит, когда вам приходится масштабировать скомпилированное приложение в гетерогенной среде с тысячами узлов, которые невозможно контролировать? Как отладить приложение, запущенное на машине, к которой у вас нет доступа, и использующее различные версии библиотек с кастомными патчами, которых у вас нет?

Возможно, вы будете удивлены, узнав, что ошибки в libpcap мешают вам эффективно перехватывать пакеты из сетевого интерфейса, но это ещё не всё. В драйверах NIC тоже полно ошибок, которые исчезают и вновь появляются в различных версиях ядра в рамках одного и того же релиза крупной операционной системы. Объединение Ethernet-каналов (Ethernet bonding) также имеет собственный «набор» багов при использовании NIC с поддержкой аппаратного VLAN-тегирования.

Я сталкивался с интересными проблемами везде: начиная от компиляторов, ядер, компоновщиков и загрузчиков и заканчивая багами в автоматизированных инструментах, системах автоматизации и даже «острыми углами» в самих упаковочных системах.

У инженеров есть чётко определенный набор инструментов, которыми они могут воспользоваться при построении и масштабировании сервисов. Цель моего выступления — определить такой набор инструментов для масштабирования скомпилированных приложений, предложить передовой опыт, предупредить о том, чего стоит остерегаться, и выработать стратегии работы в случае неудачи.

Зарегистрироваться!