Контроль потока в Аэроне

Один из моих последних проектов привел меня к участию в
Аэрон проект. Если вы не знаете об Aeron, то идите к
Сайт Github и проверьте его. По своей сути это надежная система обмена сообщениями, которая работает через UDP, Multicast UDP и IPC. Он также содержит функцию архивации для записи и воспроизведения и (все еще в активной разработке) реализацию протокола Raft для кластеризации. Я уже говорил, что это было быстро .

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

Что такое управление потоком?

В распределенной системе цель управления потоком состоит в том, чтобы ограничить скорость отправителя, чтобы он не превышал связанный с ним получатель. UDP не поставляется с какой-либо формой управления потоком, поэтому легко создать отправителя, который будет опережать получателя, что приведет к потере сообщения. Есть несколько различных форм управления потоком , но я собираюсь сосредоточиться на
протокол управления потоком в скользящем окне, используемый TCP и Aeron. Протокол скользящего окна требует, чтобы отправитель поддерживал буфер данных (называемый окном). Размер этого окна обычно передается от получателя к отправителю как часть протокола. С помощью двунаправленного протокола, такого как TCP, размер окна сообщается в каждом заголовке сегмента TCP. Это объем данных, который отправитель может передать получателю, прежде чем ждать, пока не будет получено подтверждение. Если поток приложения на стороне получателя занят и не читает данные из сокета, а отправитель продолжает передачу, значение размера окна будет уменьшаться до тех пор, пока не достигнет 0, после чего отправитель должен остановиться и ждать подтверждения с ненулевой размер окна перед отправкой снова. Существует гораздо больше теории сетей, определяющих размер окна управления потоком, чтобы полностью использовать сеть. Но я оставлю это как упражнение для читателя.

В случае одноадресной передачи Aeron и UDP он очень похож на TCP, однако Aeron — это однонаправленный протокол, в котором получатели отправляют сообщения о состоянии, чтобы указать отправителю, что он готов принять данные и сколько. Сообщение о состоянии указывает, где подписчик использует идентификатор потребления и смещение срока потребления для определенной тройки канала / потока / сеанса. Значение окна получателя — это объем данных, который можно отправить из этой позиции, прежде чем отправителю потребуется остановиться и дождаться нового сообщения о состоянии, указывающего, что получатель может использовать больше данных. Размер окна получателя составляет не более ¼ от размера термина и не менее размера MTU (максимальной единицы передачи).

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

На самом деле Aeron — это единственный инструмент, который поддерживает многоадресные сообщения UDP с динамическим управлением потоком (что нам известно).

Контроль максимального потока

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

Контроль минимального расхода

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

Tagged Flow Control (ранее известный как предпочтительный контроль потока)

Управление помеченным потоком — это стратегия, которая пытается смягчить некоторые недостатки стратегии управления минимальным потоком. Он работает с использованием подхода минимального управления потоком, но только для подмножества приемников, помеченных для включения в группу управления потоком. Стратегия управления минимальным потоком является частным случаем этой стратегии, когда все получатели считаются находящимися в группе.

Настройка управления потоком

Одной из новых функций, появившихся в Aeron 1.26.0, была возможность управления стратегией управления потоками непосредственно из URI канала, позволяющая осуществлять точный контроль над каждой публикацией и подпиской. Значения по умолчанию также могут быть указаны в контексте медиа-драйвера. На стороне публикации канал может быть указан как:

Минимальные и максимальные параметры управления потоком для публикации являются простейшими, но помеченный один начинает становиться немного интереснее. , G: 1001 указывает, что групповой тег равен 1001, и любой получатель, который хочет участвовать в управлении потоком для этой публикации, должен будет указать этот групповой тег. URI канала подписки показывают, как гарантировать, что получатель отправит соответствующий групповой тег, чтобы он был включен в группу управления потоками издателей.

Маркированная стратегия управления потоком действительно полезна для приема из канала, где есть несколько разных типов подписчиков, которые имеют разные требования к надежности. Хорошим примером является поток событий, который должен быть отправлен в службу шлюза для отправки пользователям, возможно, через HTTP, а также должен обратиться к нескольким службам архивации для избыточного хранения данных в базе данных. Возможно, узлы шлюза могут легко справиться с потерей сообщений, сообщив пользователю об ошибке или повторно запросив данные. Однако это может быть невозможно для узлов службы архивирования. В этом случае публикация будет указывать помеченную стратегию управления потоком, а подписки на сервисы архивирования будут использовать
Параметр gtag, чтобы убедиться, что они включены в группу управления потоком. Службы шлюза могут покинуть
Значение gtag сбрасывается и не влияет на управление потоком на издателе.

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

Управление потоком на основе подключения

Оказывается, теперь это возможно и с выпуском 1.26.0. Как для тегированного управления потоком, так и для стратегий минимального управления потоком мы можем указать минимальный размер группы, который должен быть соблюден, прежде чем публикацию можно будет считать связанной. Это не зависит от требования, что должен быть один подключенный абонент. Поэтому значение по умолчанию для этого минимального размера группы равно 0. Как и стратегия и группа управления потоком, минимальный размер группы может быть указан в URI канала.

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

Время вне

Одна из последних новых функций, доступных в конфигурации URI канала, — это возможность указать продолжительность тайм-аута для минимальной и помеченной стратегии управления потоком. Как упоминалось ранее, по умолчанию это значение равно 2 с, но может быть установлено любое значение. При указании этого значения следует соблюдать осторожность, если оно слишком короткое, то при нормальном режиме работы приемники могут часто отключаться. Сообщения о состоянии отправляются каждые 100 мсек, поэтому любые более короткие сообщения бесполезны. Слишком длинный и неисправный приемник может привести к значительному противодействию давлению на издателя. Установка этого для мин и помеченных стратегий управления потоком:

Резюме

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