SpikeArrest не может распределяться между процессорами сообщений. Обычно он используется для остановки больших всплесков трафика, а не для контроля трафика на предлагаемых вами уровнях (3 вызова в минуту). Обычно вы помещаете его в предварительный поток прокси-запроса и прерываете его, если трафик слишком высок.
Самое близкое, что вы можете получить до 3 в минуту, используя SpikeArrest с вашими циклическими процессорами сообщений, — это 1 в минуту, что приведет к 6 вызовам в минуту. Вы можете указать SpikeArrests только как «n в секунду» или «n в минуту», что действительно преобразуется в «1 в 1/n секунду» или «1 в 1/n минуту», как вы упомянули выше.
Вы действительно поддерживаете только один вызов каждые 20 секунд на вашем бэкэнде? Если вы пытаетесь поддерживать один вызов каждые 20 секунд для каждого пользователя или приложения, я предлагаю вам попытаться выполнить это с помощью Политика квот. Квоты могут совместно использовать счетчик для всех обработчиков сообщений. Вы также можете использовать квоты для всего трафика (а не для каждого пользователя или для каждого приложения), указав идентификатор квоты, который является константой. Вы можете позволить 3 в минуту, но все они могут войти в то же время в течение этой минуты.
Если вы просто пытаетесь защитить свой сервер от чрезмерной нагрузки, Часто используется политика ConcurrentRateLimit.
Последнее решение — реализовать некоторый пользовательский код.
Обновление для решения дополнительных вопросов:
Переформулировать:
- 6 процессоров сообщений обрабатывают циклический алгоритм
- хотите, чтобы 4 приложения имели разрешение 5 вызовов в секунду
- хотите, чтобы остальные приложения делились 10 звонками в секунду
Чтобы получить желаемую степень детализации, вам необходимо использовать квоты. К сожалению, вы не можете установить квоту, чтобы она имела значение «в секунду» для распределенной квоты (распределенная квота разделяет счетчик между обработчиками сообщений, а не имеет собственный счетчик для каждого обработчика сообщений). Лучшее, что вы можете сделать, это поминутно, что в вашем случае будет 300 вызовов в минуту. В противном случае вы можете использовать нераспределенную квоту (разделяя квоту между 6 обработчиками сообщений), но проблема, с которой вы столкнетесь, заключается в том, что вызовы, поступающие на одни MP, будут отклонены, а другие будут приняты, что может сбивать с толку ваши разработчики.
Для распределенных квот вы должны установить 300 вызовов в минуту в продукте API (см. документы) и назначьте этот продукт своим четырем приложениям. Затем в вашем коде, если этот продукт не назначен приложению текущего вызова API, вы должны использовать квоту, жестко запрограммированную на 10 в секунду (600 в минуту), и использовать постоянный идентификатор, а не client_id, чтобы все другой трафик использует эту квоту.
Квоты не мешают вам отправлять все ваши запросы почти одновременно, и я предполагаю, что ваш сервер не может обрабатывать более 1200 запросов одновременно. Вам нужно сгладить трафик с помощью политики SpikeArrest. Вы захотите разрешить максимальный трафик через SpikeArrest, который может обработать ваш сервер. Это поможет защититься от всплесков трафика, но вы, вероятно, получите отклоненный трафик, который обычно разрешается квотой. Политику SpikeArrest следует проверять до квоты, чтобы отклоненный трафик не учитывался в квоте приложения.
Как вы, вероятно, видите, настройка для таких ситуаций, как ваша, — это больше искусство, чем наука. Мое предложение состояло бы в том, чтобы провести серьезное тестирование производительности/нагрузки и настроить его, пока вы не найдете правильные значения. Если вы сможете понять, как использовать нераспределенные квоты для получения приемлемой производительности и предсказуемости, это позволит вам работать с числами в секунду, а не с числами в минуту, что, вероятно, снизит вероятность массовых всплесков.
Удачи!
person
Mike Dunker
schedule
25.04.2014
