Каков рекомендуемый способ создания функциональности, аналогичный Stackoverflow "Входящие"?

У меня есть сайт asp.net-mvc, и люди управляют списком проектов. Исходя из некоторого алгоритма, я могу сказать, устарел ли проект. Когда пользователь входит в систему, я хочу, чтобы он показывал количество устаревших проектов (аналогично тому, как я вижу несколько обновлений в папке "Входящие" ).

Алгоритм вычисления устаревших проектов выглядит медленным, поэтому, если каждый пользователь регистрируется, я должен:

Запустить запрос для всего проекта, где они являются владельцем
Запустить алгоритм IsStale()
Отобразить счетчик, где IsStale = true

Я предполагаю, что это будет очень медленно. Кроме того, во всем проекте пишите, мне придется пересчитать выше, чтобы увидеть, изменились ли они.

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

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

Ответ 1

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

Как вы думаете, что я буду чувствовать, если я позвоню в 3 часа ночи с клиента, чтобы узнать, почему проект больше не вовремя? Очевидно, очень удивился, потому что система меня не предупредила. Почему это произошло? Потому что мне пришлось ждать 30 секунд (почему не только 1 секунда?) Для следующего запуска запланированного задания, чтобы обновить статус проекта.

Это просто не может быть решением. Предупреждение должно быть немедленно отправлено пользователю, даже если для выполнения процесса IsStale() требуется 30 секунд. Покажите пользователю изображение loading... или что-нибудь еще, но убедитесь, что пользователь имеет точные данные.

Теперь, в отношении реализации, ничего не может быть сделано, чтобы убежать от предыдущей проблемы: вам придется запускать этот процесс, когда что-то, что влияет на некоторые изменения даты. Однако то, что вы можете сделать, это не лишний раз запустить этот процесс. Например, вы упомянули, что можете запускать его всякий раз, когда пользователь входит в систему. Что делать, если 2 или более пользователя входят в систему и видят один и тот же проект и ничего не меняют? Нет необходимости запускать этот процесс дважды.

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

<сильные > Преимущества

Нет запланированной работы
Нет ненужных процессов (это возможно, потому что вы можете установить флаг dirty в проекте и запустить его, только если он true)
Нет ненужных запросов значения dirty
Пользователь всегда будет информирован о текущем и реальном состоянии проекта (который, безусловно, является самым важным элементом для адресации в любом решении)

Недостатки

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

Переходя к тому, как вы внедряете систему уведомлений аналогично StackOverflow, это совсем другой вопрос. Я думаю, у вас есть отношения "многие ко многим" с пользователями и проектами. Простейшим решением было бы добавить один атрибут к отношениям между этими объектами (средняя таблица):

Сильные стороны: у пользователя много проектов. В проекте много пользователей

Таким образом, при запуске процесса вы должны обновить каждого пользователя Has_pending_notifications новым результатом. Например, если пользователь обновляет проект и больше не вовремя, вы должны установить в поле true все пользователи Has_pending_notifications, чтобы они знали о ситуации. Аналогично, установите время false, когда проект вовремя (я понимаю, вы просто хотите убедиться, что уведомления отображаются, когда проект больше не вовремя).

Взяв пример StackOverflow, когда пользователь читает уведомление, вы должны установить флаг false. Убедитесь, что вы не используете временные метки, чтобы угадать, прочитал ли пользователь уведомление: вход в систему не означает чтение уведомлений.

Наконец, если само уведомление достаточно сложно, вы можете отвести его от отношений между пользователями и проектами и пойти на что-то вроде этого:

Сильные стороны: у пользователя много проектов. В проекте много пользователей. У пользователя есть много уведомлений. В уведомлениях есть один пользователь. В проекте много уведомлений. Уведомление имеет один проект.

Я надеюсь, что что-то, что я сказал, имеет смысл или даст вам другую лучшую идею:)

Ответ 2

Вы можете сделать следующее:

Для каждой записи пользователя добавьте поле datetime sayng в последний раз, когда выполняется медленное вычисление. Назовите это LastDate.
Для каждого проекта добавьте логическое значение, чтобы сказать, нужно ли его указывать. Вызвать это: Выбранный
При запуске параметра "Медленная" вы обновляете выбранные файлы
Теперь, когда пользователь регистрируется, если LastDate достаточно близко, вы используете результаты последнего медленного вычисления и просто выполняете весь проект с помощью Selected true. В противном случае yourun снова медленное вычисление. Вышеуказанная процедура является оптимальной, потому что она повторно вычисляет медленную процедуру ТОЛЬКО, ЕСЛИ НАСТОЯТЕЛЬНО НЕОБХОДИМА, при выполнении процедуры с фиксированными интервалами времени... имеет риск потерять время, потому что, возможно, пользователь будет использовать результат вычисления.

Ответ 3

Сделайте поле "устаревшим". Запустите инструкцию SQL, которая обновляет stale = 1 со всеми записями, где stale = 0 AND (этот алгоритм возвращает true). Затем запустите инструкцию SQL, которая выбирает все записи, где stale = 1.

Причина, по которой это будет работать быстро, состоит в том, что синтаксические анализаторы SQL, такие как PHP, не должны выполнять вторую половину оператора AND, если первая половина возвращает true, что делает ее очень быстрой прогон через весь список, проверяя все записи, пытаясь сделать их устаревшими, если не устаревать. Если он уже устарел, алгоритм не будет выполнен, что экономит ваше время. Если это не так, алгоритм будет запущен, чтобы убедиться, что он стал устаревшим, а затем устаревшим будет установлено значение 1.

Второй запрос затем возвращает все устаревшие записи, где stale = 1.

Ответ 4

Вы можете сделать это:

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

Ответ 5

Я думаю, что фундаментальные вопросы нужно решить, прежде чем думать о базах данных и коде. Первичный из них: "Почему IsStale() медленный?"

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

Записав системы планирования в прошлом, существует два типа изменений: те, которые могут произойти в слабом состоянии, и те, которые вызывают каскадные изменения расписания. Аналогично, существует два типа перестроек: общий и локальный. Полное восстановление является очевидным; локальные перестройки пытаются минимизировать "ущерб" другим запланированным ресурсам.

Вот суть проблемы: если у вас есть полная перестройка при каждом обновлении, вы можете посмотреть 30-минутные лаги с момента изменения до того момента, когда график будет стабильным. (Я основываю это на своем опыте с временем восстановления системы ERP с очень сложной рабочей нагрузкой).

Если реальность вашей системы заключается в том, что такие задачи занимают 30 минут, достижение целевой цели мгновенного удовлетворения ваших пользователей противоречит основополагающей сути дела. Тем не менее, вы можете обнаружить несогласованность расписания намного быстрее, чем перестраивать. В этом случае вы могли бы показать, что "расписание было переполнено, пересчитаны новые времена окончания" или что-то подобное... но я подозреваю, что если у вас много изменений в расписании, введенных разными пользователями одновременно, система будет деградировать в одно непрерывное отображение этого уведомления. Однако вы, по крайней мере, получаете преимущество в том, что вы можете выполнять периодические изменения в течение определенного периода времени для следующего восстановления.

Именно по этой причине большинство проблем планирования, которые я видел, на самом деле не выполняют повторные вычисления в реальном времени. В контексте ситуации с ERP существует мастер расписания, который отвечает за планирование рабочего цеха, и любые изменения проходят через них. График "мастер" был регенерирован до каждой смены (сдвиги составляли 12 часов, поэтому два раза в день), а во время сдвига задержки выполнялись с помощью "локальных" модификаций, которые не перетасовали мастер-расписание до следующего 12-часового блока.

В гораздо более простой ситуации (разработка программного обеспечения) расписание обновлялось один раз в день в ответ на отчет о прогрессе за день. Плохие новости были доставлены в ходе следующего утреннего схватки вместе с обновленным графиком.

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

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