Реактивные системы - Реакция на время
Допустим, у нас есть система прогнозирования реактивных продаж.
Каждый раз, когда мы совершаем продажу, мы пересчитываем наш прогноз будущих продаж. Это прекрасно работает, если есть много продаж, запускающих наше повторное прогнозирование. Однако что произойдет, если продажи снизятся со 100 событий в секунду до 0. И останутся 0 в течение длительного времени? Прогноз, который мы опубликовали, когда продажи были хорошими, остается самым актуальным прогнозом.
Как бы вы смоделировали в этой ситуации событие, представляющее "никаких продаж не происходит", не возвращаясь к какому-либо пакетному ежечасному / ежеминутному / произвольному событию временного сегмента, которое говорит "X время прошло".
Это частный случай общего вопроса - как вы моделируете время, когда ничего не происходит в системе, основанной на событиях, - без использования тикающего события в стиле часов, которое заставит всех пересмотреть свои текущие значения [реализация, которая не масштабируется],
Единственный вариант, который я рассмотрел, который имеет смысл: каждый раз, когда мы совершаем продажу, мы также планируем отложенное событие на 2 часа в будущем, которое просит нас пересмотреть нашу оценку этой продажи. При обработке этого отложенного события мы можем затем запланировать дальнейшие отложенные события для повторного рассмотрения.
1 ответ
Учитывая, что это очень общий сценарий, вы сделали довольно большое предположение о том, что невозможно придумать дизайн для переоценки прошлых продаж в масштабируемом режиме, если только он не совершил одну продажу за раз.
В сценарии много разных чисел, связанных с масштабом, и вы смотрите только тот, при котором один запланированный обновитель прогноза может попытаться обработать очень большое количество прошлых продаж одновременно.
Другие проблемы с масштабируемостью, о которых я могу подумать:
Переоценка прогноза для каждой новой продажи не будет звучать замечательно, если вы ожидаете сотни продаж в секунду. Если вы говорите о модели финансового прогнозирования для бухгалтерского учета, вряд ли ее нужно обновлять каждый раз, когда организация совершает продажу, если организация совершает сотни продаж в секунду.
Если вы говорите о механизме краткосрочного прогнозирования, который будет использоваться для финансовых рынков (то есть, для прогнозирования того, сколько денег вам понадобится в течение следующих 10 секунд, или энергии, или других ресурсов), то это звучит так, как если бы вы имели постоянную волатильность и вы вряд ли столкнетесь с ситуацией, когда ничего не происходит часами. А если вам нужно, чтобы прогнозы обновлялись очень часто, то ожидание пары часов перед повторным обновлением вряд ли даст вам необходимую информацию в том виде, в котором она вам нужна.
При вашем подходе вы получите одно запланированное событие в будущем для каждого продукта (которое может быть большим), и каждый раз, когда вы совершаете продажу, вы отбрасываете старое запланированное событие и планируете новое. Поэтому для часто продаваемых продуктов вы будете выполнять повторяющуюся работу, чтобы постоянно продвигать банку в будущем, когда вы вряд ли когда-либо попадете туда.
То, что составляет хороший дизайн, будет основано на реальном сценарии. Обобщающий случай интересен для размышления, но хороший дизайн должен соответствовать их обстоятельствам.
Вот несколько идей, которые у меня могут быть подходящими:
Если вам нужен обновленный прогноз по продукту, когда этот продукт продается, но некоторые продукты могут продаваться очень часто, то хорошим подходом может быть ограничение или буферизация продаж для каждого продукта. Если продукт продается 50 раз в секунду, вы, вероятно, можете позволить себе подождать 1 секунду, 10 секунд, 2 часа и т. Д. И оценить все эти продажи сразу, а не пересматривать 50 раз в секунду. Особенно, если ваш процесс прогнозирования тяжелый, выполнение его для каждой продажи, вероятно, вызовет высокую нагрузку для низкой стоимости, так как информация будет почти сразу устаревшей к следующей продаже.
У вас также может быть общий таймер, который обновляет прогнозы для всех продуктов, которые не были проданы в последнем окне, но обрабатывает продукты в буферах. Например, каждый час вы можете выбрать 10 продуктов с самыми старыми прогнозами и обновить их. Это препятствует повторному прогнозированию всего таймера всего набора продуктов за одно попадание.
Вы можете использовать только описанный выше подход с одним таймером и забыть о прогнозах на каждую продажу, если хотите что-то очень простое.
Если вас беспокоит нагрузка от пакетного прогнозирования, такую работу следует выполнять на оборудовании, отличном от того, которое используется для продаж.