Предел пропускной способности сетки событий

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


azure azure-eventgrid event-driven
person k11k2    schedule 01.02.2018    source источник
comment
Похоже, вы ищете концентраторы событий. Хотите поделиться, почему вы выбрали сетку?   -  person evilSnobu    schedule 02.02.2018
comment
@evilSnobu Мы уже начали использовать концентратор событий, интегрировав его с функциями Azure, но, поскольку в сетке событий есть возможность повторных попыток, мы надеемся, что она будет соответствовать нашим текущим требованиям (необходимо повторять отправку уведомления, пока оно не будет успешным).   -  person k11k2    schedule 02.02.2018
comment
Какие уведомления и для какой цели? Обычно вы добавляете центры уведомлений, если предполагается, что они доступны человеку.   -  person evilSnobu    schedule 02.02.2018
comment
@ k11k2, Масштабируемость сетки событий: возможность маршрутизации 10 000 000 событий в секунду для каждого региона. docs.microsoft.com/ en-us / azure / iot-hub /   -  person Roman Kiss    schedule 02.02.2018
comment
@evilSnobu Мы отправляем SMS-уведомления пользователям на основе их запросов (для уведомления об обновлениях их профиля, данных учетной записи и т. д.). Да, в настоящее время мы отправляем события в концентратор событий и запускаем концентратор событий с помощью azf для обработки события и отправки пользователю. Bt в некоторых случаях во время обработки в любой момент времени из-за большого количества запросов или проблем с подключением; уведомление о процессе не удается. Чтобы повторить попытку обработки события, мы реализовали наш собственный механизм сбоя. это причина, по которой мы пытаемся переключиться на сетку событий   -  person k11k2    schedule 02.02.2018
comment
@RomanKiss Спасибо за обновление, но можем ли мы настроить количество событий, которые мы можем отправлять обработчику событий в секунду, то есть в нашем случае функция azure. Например, мы настроили maxBatchSize от концентратора событий до триггера концентратора событий как 30, как мы можем настроить для группы событий в учетной записи Azure.   -  person k11k2    schedule 02.02.2018
comment
Если вы не справляетесь с обработкой на стороне потребителя, просто переключитесь на служебную шину или служебную шину Premium для высокой пропускной способности. Это даст вам курсор на стороне сервера и правильную очередь, а не распределенное ведение журнала (концентраторы событий). Логика повтора встроена в SDK функций для триггера служебной шины. Если сообщение не удалось обработать, оно вернется в очередь и повторите попытку позже.   -  person evilSnobu    schedule 02.02.2018
comment
@evilSnobu есть ли причина не использовать Event Grid? причина необходимости довести эти опасения до нашего высокого авторитета.   -  person k11k2    schedule 02.02.2018
comment
@evilSnobu, как вы сказали, я прошел через это. System.Threading.Thread.Sleep(policy.RetryInterval); Но я думаю, что перевод потока в спящий режим на время повторной попытки - нереальное решение. Есть ли лучший способ обработать логику повтора в триггере служебной шины?   -  person k11k2    schedule 02.02.2018
comment
Вам не нужно заниматься этим самостоятельно, он встроен в среду выполнения (сценарий SDK WebJobs). Ваша функция Azure выполняет PeekLock, поэтому просто напишите своему потребителю, как будто ничего плохого не произойдет, см. Это - docs.microsoft.com/en-us/azure/azure-functions/   -  person evilSnobu    schedule 02.02.2018
comment
@ k11k2, AEG представляет модель Pub / Sub событий в реальном времени с масштабируемой надежной доставкой событий подписчикам (объект назначения - приемник событий). Дизайн AEG по умолчанию основан на событиях доставки PushWithAck в приемник событий, но, подписав концентратор событий Azure на AEG, мы можем легко расширить эту вечернюю модель для потоковой передачи и для событий доставки по запросу по приемнику событий.   -  person Roman Kiss    schedule 02.02.2018

Ответы (2)


arrow_upward
2
arrow_downward

Я спросил Microsoft об этой теме, и они ответили:

Затылок: ограничение скорости публикации составляет около 5000 событий в секунду. Это события, которые вы можете опубликовать в Event Grid. Вы можете достичь более высоких показателей, если экземпляр службы не загружен. Имейте в виду, что EG - это мультитенантная система.

https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-event-grid-routing-comparison Высокий: возможность маршрутизации 10 000 000 событий в секунду для каждого региона.

Выше представлены возможности всей службы по отправке событий для каждого региона.

person mfierro    schedule 23.04.2018
comment
10 миллионов - для Центра Интернета вещей. 5000 событий - это ограничение для тем событий / доменов событий, в зависимости от того, какой ресурс вы создаете. - person Anoop; 03.02.2020

arrow_upward
2
arrow_downward

Сетка событий создана для больших масштабов - миллионы событий в секунду с пропускной способностью как для входящего, так и для исходящего трафика: https://docs.microsoft.com/en-us/azure/event-grid/overview#capabilities

В Event Grid нет концепции пространства имен, поэтому вы не предоставляете заранее определенную пропускную способность. Он масштабируется, когда вы используете его на основе оплаты за операцию.

person Bahram Banisadr    schedule 05.02.2018