Почему сайты, такие как stackoverflow с значками, используют какой-то тип отложенной работы, чтобы определить, когда нужно назначить новый значок?

Question

Stackoverflow имеет отличную систему значков. Одна вещь, которую я заметил, это то, что значки не сразу присуждаются, но иногда, похоже, есть какая-то задержка после того, как я отвечаю критериям. Я заметил это на некоторых других сайтах, у которых есть значки.

Предположительно это связано с тем, что они используют задержанную работу, которая периодически проверяет, должны ли быть отмечены новые значки. Я вижу этот подход также консультировал здесь:
How to implement badges?

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

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

Мне кажется, что система, которую я предпочитаю, должна быть быстрой и простой в понимании. Есть ли недостатки, которые мне здесь не хватает, почему необходимо усложнять работу с задержкой?

уточнить: Я планирую иметь абстрактный класс Достижения, с каждым фактическим достижением реализации достижений. Каждое достижение будет иметь функцию checkAwardBadge, которая может вызываться из контроллера или даже отложенное задание, если я должен выбрать этот маршрут или в любое время, чтобы проверить, получил ли пользователь определенный значок. Таким образом, код успеха будет централизован.

Answer 1

Ваша реализация может работать на простых сценариях (например, тот, который вы описываете), но если что-то становится более сложным у вас есть решение, которое:

1. Makes ненужных проверки в каждом действии
2. Добавляет производительность штрафной к каждому действию
3. Не масштабируется
4. Не имеет центрального места для всех правил.

Answer 2

Это может быть так, что если действие будет выполнено и немедленно отменено, это не приведет к присвоению значка.

Answer 3

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

Периодическое задание будет генерировать новый статический контент и будет работать очень часто, но реже, чем каждый запрос на одну страницу.

Answer 4

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

Я работаю для алгоритмической торговой компании в режиме реального времени. Часть того, что делает наше программное обеспечение, - это данные рыночного процесса от поставщика.

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

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

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

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

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