Может кто-нибудь, пожалуйста, скажите мне, какой алгоритм перебалансировки для потребителей Kafka? Я хотел бы понять, как влияет количество разделов и потребительские потоки.
Спасибо,
Может кто-нибудь, пожалуйста, скажите мне, какой алгоритм перебалансировки для потребителей Kafka? Я хотел бы понять, как влияет количество разделов и потребительские потоки.
Спасибо,
Итак, на данный момент есть 2 алгоритма перебалансировки - Range
и RoundRobin
. Они также называются стратегиями назначения разделов.
Для простоты предположим, что у нас есть тема T1
с 10 разделами, и у нас также есть 2 потребителя с разными конфигурациями (для примера более ясными) - C1
с num.streams
, установленными на 1
и C2
с num.streams
установлен на 2
.
Вот как это работает с стратегией Range
:
Диапазон предоставляет доступные разделы в числовом порядке и потребительские потоки в лексикографическом порядке. Таким образом, в нашем случае порядок разделов будет 0, 1, 2, 3, 4, 5, 6, 7, 8, 9
, а порядок потребительских потоков будет C1-0, C2-0, C2-1
. Затем количество разделов делится на количество потребительских потоков, чтобы определить, сколько разделов должно принадлежать каждому потребительскому потоку. В нашем случае он не делится одинаково, поэтому поток C1-0
получит один дополнительный раздел. Окончательное назначение раздела будет выглядеть так:
C1-0
получает разделы 0, 1, 2, 3
C2-0
получает разделы 4, 5, 6
C2-1
получает разделы 7, 8, 9
Если будет 11 разделов, назначение разделов для этих потребителей немного изменится:
C1-0
получит разделы 0, 1, 2, 3
C2-0
получит разделы 4, 5, 6, 7
C2-1
получит разделы 8, 9, 10
Что это.
Такая же конфигурация не будет работать для стратегии RoundRobin
, так как для всех пользователей, подписавшихся на эту тему, требуется равное num.streams
, поэтому допустим, что у обоих пользователей num.streams
установлено значение 2 сейчас. Одно из основных различий по сравнению с стратегией Range
заключается в том, что вы не можете предсказать, какое задание будет до перебалансировки. Вот как это будет работать с стратегией RoundRobin
:
Во-первых, есть два условия, которые ДОЛЖНЫ быть выполнены до фактического назначения:
a) Каждая тема имеет одинаковое количество потоков внутри экземпляра пользователя (поэтому я упомянул выше, что разное количество потоков для каждого потребителя не будет работать)
b) Набор подписанных тем идентичен для каждого экземпляра пользователя внутри группы (у нас есть одна тема, чтобы теперь не проблема).
Когда эти 2 условия проверяются, пары topic-partition
сортируются по hashcode, чтобы уменьшить вероятность того, что все разделы одной темы будут назначены одному потребителю (если есть более чем одна тема для потребления).
И, наконец, все пары topic-partition
назначаются круговым способом доступным потребительским потокам. Например, если наши разделы темы будут отсортированы следующим образом: T1-5, T1-3, T1-0, T1-8, T1-2, T1-1, T1-4, T1-7, T1-6, T1-9
и потоки потребителей C1-0, C1-1, C2-0, C2-1
, тогда назначение будет таким:
T1-5
переходит в C1-0
T1-3
переходит в C1-1
T1-0
переходит в C2-0
T1-8
переходит в C2-1
На данный момент больше не осталось потребительских потоков, но есть еще больше разделов темы, поэтому начинается итерация по потребительским потокам: T1-2
переходит в C1-0
T1-1
переходит на C1-1
T1-4
переходит на C2-0
T1-7
переходит в C2-1
И снова: T1-6
переходит в C1-0
T1-9
переходит в C1-1
В этот момент все разделы темы назначаются, и каждый потребительский поток имеет почти равное количество разделов.
Надеюсь, что это поможет.
Вы можете прочитать этот документ Kafka http://kafka.apache.org/documentation/#impl_brokerregistration о алгоритме регистрации пользователей и алгоритме балансировки потребителя
Как говорится, каждый потребитель делает следующее во время перебалансировки:
1. For each topic T that C<sub>i</sub> subscribes to
2. let P<sub>T</sub> be all partitions producing topic T
3. let C<sub>G</sub> be all consumers in the same group as C<sub>i</sub> that consume topic T
4. sort P<sub>T</sub> (so partitions on the same broker are clustered together)
5. sort C<sub>G</sub>
6. let i be the index position of C<sub>i</sub> in C<sub>G</sub> and let N = size(P<sub>T</sub>)/size(C<sub>G</sub>)
7. assign partitions from i*N to (i+1)*N - 1 to consumer C<sub>i</sub>
8. remove current entries owned by C<sub>i</sub> from the partition owner registry
9. add newly assigned partitions to the partition owner registry
(we may need to re-try this until the original partition owner releases its ownership)
И также Обратите внимание:
Если потребителей больше, чем разделов, некоторые потребители вообще не получат никаких данных. Во время перебалансировки мы пытаемся назначить разделы потребителям таким образом, чтобы уменьшить количество узлов брокера, к которым должен подключиться каждый потребитель.