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

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

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

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

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

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

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

Ответ 1

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

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

Ответ 2

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

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

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

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

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

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

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

Ответ 3

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

Ответ 4

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

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