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

Question

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

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

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

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

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

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

Answer 1

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

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

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

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

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

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

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

Answer 2

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

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

Answer 3

Возможно, что если действие выполнено и немедленно отменено, это не приведет к награждению значком.

Answer 4

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

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