Высокомасштабная обработка сообщений в концентраторе событий

Насколько я понимаю, eventhub может обрабатывать/принимать миллионы сообщений в секунду. И для настройки приема мы можем использовать пропускную способность.

Больше пропускной способности = больше мощности приема.

Но на принимающей/потребляющей стороне вы можете создать до 32 получателей (поскольку мы можем создать 32 раздела, и один раздел может использоваться одним получателем).

Исходя из вышеизложенного, если для обработки одного сообщения требуется 100 миллисекунд, один потребитель может обработать 10 сообщений в секунду, а 32 потребителя могут обработать 32 * 10 = 320 сообщений в секунду.

Как заставить получателя потреблять больше сообщений (например, 5-10 тыс. в секунду).

1) Либо мне нужно асинхронно обрабатывать сообщения внутри ProcessEventsAsync. Но в этом случае я не смог бы поддерживать порядок.

2) Или я должен попросить Microsoft разрешить мне создать больше разделов.

Пожалуйста посоветуй


azure autoscaling azure-eventhub
person Pragmatic    schedule 25.12.2014    source источник
comment
Привет @Pragmatic, с 32 разделами и 10 TU я мог получить 6 сообщений об отсутствии за 10 минут. заметил, что при 20 ТЕ оно сократилось до 5 мин. но увеличение TU может привести к тому, что вы заплатите больше денег. Если вы уже решили эту проблему, поделитесь своими комментариями. так как я хотел бы получить все 6 сообщений об отсутствии для обработки за 1 минуту или меньше.   -  person ಅನಿಲ್    schedule 23.08.2016

Ответы (1)


arrow_upward
6
arrow_downward

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

Вы правы в том, что вашей единицей потребления параллелизма является раздел. Если ваши потребители могут выполнять только 10 операций в секунду по порядку или даже 100 операций в секунду по порядку, вам потребуется больше разделов для обработки миллионов событий. Хотя 100 мс/событие, безусловно, кажется мне медленным, и я думаю, что вы должны искать здесь оптимизацию (т. е. отдавать работу, которую вам не нужно ждать, реже фиксировать и т. д.), вы достигнете точки, когда вам потребуется больше разделов в масштабе.

Некоторые вещи, о которых следует помнить: 32 раздела дают только 32 Мбит/с на вход и 64 Мбит/с на исход. Оба эти фактора имеют значение, поскольку исходящая пропускная способность распределяется между всеми группами потребителей, которые вы используете. Таким образом, если у вас есть 4 группы потребителей, считывающие данные (каждая по 16 Мбит/с), вам потребуется в два раза больше разделов (или, по крайней мере, единиц пропускной способности) для ввода, чем если бы вы основывались исключительно на входе ваших данных (потому что в противном случае вы бы отстали) .

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

person cacsar    schedule 08.01.2015
comment
если у вас уже есть концентратор событий и вам нужно улучшить скорость потребления, еще одно решение, которое следует рассмотреть, — это конвейерные концентраторы событий (передача данных из занятого раздела EventHub в другой концентратор событий), а затем потребление из новых 32 разделов (которые отделить от одного раздела). - person Sreeram Garlapati; 31.01.2015
comment
Хотя комментарий @Sreeram, вероятно, является вашим единственным реальным подходом к существующему концентратору событий, недостатком этого является то, что вы в конечном итоге платите дважды за каждое событие (0,028 доллара США за миллион). Положительным моментом является то, что вы также получаете еще один набор из 5 (4 для безопасности) потребителей на раздел, что является ограничением, которое я не отметил в своем ответе. - person cacsar; 01.02.2015