Алгоритм для выравнивания пикового использования со временем?
делегат А является именованным типом, который определяет конкретный вид метода. Так же, как определение класса размечает всех участников для данного вида объекта, который это определяет, делегат размечает сигнатуру метода для вида метода, который это определяет.
На основе этого оператора, делегат является указателем функции, и он определяет то, на что похожа та функция.
яркий пример А для приложения реального мира делегата Предикат . В примере из ссылки Вы заметите тот Массив. Найдите , берет массив для поиска и затем предикат для обработки критериев того, что найти. В этом случае это передает метод ProductGT10, который соответствует подписи Предиката.
3 ответа
Если вы хотите избежать всплесков, связанных с использованием случайного раз посмотрите на различные функции хеширования, используемые для хэш-таблиц. Вы можете начать чтение со статей в Википедии на эту тему:
http://en.wikipedia.org/wiki/Hash_function
По сути, разделите все, что вы хотите, чтобы ваше окно обновления было на соответствующее количество сегментов. Один вариант может быть 3 часа * 60 минут * 60 секунд = 10800 ведер. Затем используйте это как размер вашей хеш-таблицы для выбранной функции хеширования. Ваш уникальный ввод может быть идентификатором устройства. Не забудьте использовать GMT для выбранного времени. Выбранный вами язык программирования, вероятно, имеет ряд встроенных функций хеширования, но в статье должны быть приведены некоторые ссылки, которые помогут вам начать работу, если вы хотите реализовать его с нуля.
Этот подход превосходит предыдущий ответ о времени произвольного доступа, поскольку он имеет гораздо лучшие свойства равномерности, а гарантирует ], что ваши шаблоны доступа будут приблизительно плоскими по сравнению со случайной функцией, которая может иногда показывать всплески.
Вот более конкретная информация о том, как реализовать различные функции:
http: //www.partow. net / programming / hashfunctions / index.html
Просто возьмите количество устройств, разделите временной интервал на n равных сегментов и назначьте каждый сегмент устройству, сообщая им, когда подключаться при следующем подключении.
Это даст вам оптимально равномерное распределение во всех случаях.
Нормализовать все время по Гринвичу, какое вам дело до часовых поясов, перехода на летнее время или чего-то еще? Теперь неважно, в каком часовом поясе вы находитесь.
Добавление случайного распределения может привести к слипанию (равномерное случайное распределение является однородным только в пределе, но не обязательно для какой-либо конкретной выборки), и его действительно следует использовать если нет механизма обратной связи. Поскольку вы можете до некоторой степени контролировать, когда они подключают случайный компонент, это вовсе не обязательно и даже отдаленно не оптимально.
Если вы ' Если вас беспокоит дрейф часов между устройствами, учтите, что даже если вы добавите случайность, это никоим образом не уменьшит случайность дрейфа ваших часов, а только внесет вклад в еще менее оптимальное распределение.
Если вы хотите обеспечить стабильное распределение. устройств по регионам, затем вычислите соотношение устройств по регионам и соответствующим образом распределите выделение слотов. Например, если у вас 50/25/25 по часовому поясу соответственно, назначьте интервалы первому часовому поясу, затем следующие два слота оставшимся часовым поясам, затем повторите.
и соответствующим образом распределять выделенные слоты. Например, если у вас 50/25/25 по часовому поясу соответственно, назначьте интервалы первому часовому поясу, затем следующие два слота оставшимся часовым поясам, затем повторите. и соответствующим образом распределять выделенные слоты. Например, если у вас 50/25/25 по часовому поясу соответственно, назначьте интервалы первому часовому поясу, затем следующие два слота оставшимся часовым поясам, затем повторите.Вы говорите, что можете сообщать устройствам, в какое время подключаться, поэтому я не понимаю, зачем вам что-то случайное или модульное. Когда каждое устройство подключается, выберите время завтра, которому в настоящее время не назначено много устройств, и назначьте устройство на это время. Если все устройства потребляют примерно одинаковое количество ресурсов для обслуживания, то тривиальный жадный алгоритм обеспечит полностью плавное распределение - назначьте каждому устройству то время, которое в настоящее время наименее загружено. Если сервер выполняет другую работу, а не только эти устройства, вам следует начать с его типичного профиля нагрузки, а затем добавить к нему нагрузку на устройство. Я бы не стал называть это «аналитическими вычислениями», просто сохраняя гистограмму ожидаемой нагрузки от времени в течение следующих 24 часов.
Или у вас есть проблема, что устройство может не подчиняться инструкциям (например, оно может быть отключено в назначенное время, а затем подключаться при следующем включении)? Очевидно, что если все ваши пользователи в определенном часовом поясе начнут работать утром в одно и то же время, это будет проблемной стратегией.