Реактивные системы - Реагирование на время прохождения

Question

Допустим, у нас есть реактивная система прогнозирования продаж.

Каждый раз, когда мы производим продажу, мы пересчитываем наш прогноз на будущие продажи. Это прекрасно работает, если есть много продаж, вызывающих наше повторное прогнозирование. Что произойдет, если продажи идут от 100 событий в секунду до 0. И остаются 0 в течение длительного времени? Прогноз, который мы опубликовали, когда продажи были хорошим, остается самым последним прогнозом.

Как бы вы моделировали в этой ситуации событие, которое представляет собой «Никаких продаж», не возвращаясь к какому-либо периодическому/часовому/произвольному событию временного сегмента, в котором говорится, что «X прошло».

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

Единственный вариант, который я счел имеющим смысл: Каждый раз, когда мы проводим продажу, мы также планируем отсроченное событие в течение 2 часов в будущем, которое просит нас пересмотреть нашу оценку этой продажи. При обработке этого отложенного события мы можем выбрать планирование дальнейших отложенных событий для повторного рассмотрения.

Answer 1

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

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

Другие вопросы масштабируемости я могу думать:

• пересматривают прогноз для каждого нового продажи не звучит замечательно, если вы ожидаете 100s продаж в секунду. Если вы говорите о модели финансового прогнозирования для бухгалтерского учета, маловероятно, что ее нужно обновлять каждый раз, когда организация производит продажу, если организация производит сотни продаж в секунду.

• Если вы говорите о краткосрочном интеллектуальном двигателе, который будет использоваться для финансовых рынков (то есть, предсказав, сколько денег вам понадобится в течение следующих 10 секунд или энергии или других ресурсов), тогда это звучит как у вас есть постоянная волатильность, и вы вряд ли будете иметь ситуацию, когда ничего не происходит в течение нескольких часов. И если вам понадобятся прогнозы, которые обновляются очень часто, ожидание в течение нескольких часов перед запуском повторного обновления вряд ли поможет вам получить нужную вам информацию в том виде, в котором она вам нужна.

• С вашим подходом вы получите одно запланированное событие на каждый продукт (который может быть большим), и каждый раз, когда вы совершаете продажу, вы будете отбрасывать старое запланированное событие и планировать новый. Поэтому для часто продаваемых продуктов вы будете делать повторяющиеся работы, чтобы постоянно бить банк вниз по дороге немного дальше, когда вы вряд ли когда-либо доберетесь туда.

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

Вот несколько идей, которые у меня есть, что может быть целесообразным:

• Если вы хотите обновленный прогноз для каждого продукта, когда этот продукт имеет продажи, но некоторые продукты могут продавать очень часто, то хороший подход может быть для дросселирования или буферизации продаж на основе каждого продукта. Если продукт продается 50 раз в секунду, вы можете позволить себе подождать 1 секунду, 10 секунд, 2 часа, что угодно и оценить все эти продажи сразу, вместо повторного прогнозирования 50 раз в секунду. Особенно, если ваш процесс прогнозирования тяжелый, делать это для каждой продажи, вероятно, приведет к высокой нагрузке для низкой стоимости, так как информация будет устаревшей почти сразу после следующей продажи.

• У вас также может быть общий таймер, который обновляет прогнозы для всех продуктов, которые не были проданы в последнем окне, но обрабатывают продукты в буферах. Например, каждый час вы можете выбрать 10 продуктов с самыми старыми прогнозами и обновить их. Это предотвращает повторное прогнозирование всего таймера одного таймера одним нажатием.

• Вы можете использовать только подход с одним таймером выше и забыть о прогнозах обновлений при каждой продаже, если хотите что-то мертвое просто.

• Если вы беспокоитесь о нагрузке от пакетного прогнозирования, этот вид работы должен выполняться на разных аппаратных средствах от тех, которые обрабатывают продажи.