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

Рост числа участников массовых стартов приводит к тому, что требования к такой системе становятся сопоставимыми с требованиями к высоконагруженным информационным сервисам. На крупном старте одновременно может формироваться большой поток временных отсечек, а страница результатов в тот же момент получает повышенный трафик со стороны участников и зрителей. Поэтому ошибка в архитектуре обработки данных проявляется не только как увеличение времени расчета, но и как задержка публикации результатов, рост нагрузки на СУБД и риск деградации всего пользовательского интерфейса.

Исходная версия системы спортивного хронометража создавалась для локальных соревнований и мероприятий среднего масштаба. При увеличении числа участников были выявлены ограничения: обработка каждой отсечки сопровождалась несколькими синхронными обращениями к базе данных, а обновление результатов выполнялось слишком часто и недостаточно агрегированно. Такой подход был приемлем для небольших стартов, однако при переходе к десяткам тысяч участников стал основным фактором снижения производительности.

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

В качестве входных данных программный модуль получает временные отсечки, поступающие от RFID-декодеров по HTTPS-протоколу. Каждая отсечка содержит идентификатор RFID-транспондера, идентификатор оборудования, идентификатор сессии и время фиксации события. Дополнительно используются данные конфигурации старта: перечень этапов, дистанций, контрольных точек, правил временных отступов, лимитов и стартовых протоколов. Управляющие команды оператора, например запуск пересчета или обновление конфигурации, также рассматриваются как входные события.

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

Архитектура разработанного решения построена как конвейер из нескольких сервисов. ApiUI принимает входящие HTTP-запросы от оборудования и устройств арбитров, сохраняет первичные данные и публикует события в очередь сообщений. SessionTagsService выполняет первичную вычислительную обработку: сопоставляет RFID-метки с регистрациями участников, применяет правила контрольных точек и формирует записи кругов. ResultsService рассчитывает итоговые таблицы результатов на основании подготовленных кругов. LiveApi отвечает за доставку обновлений в реальном времени, а PublicWebUI5 предоставляет результаты участникам и зрителям.

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

Сравнение исходного и разработанного подходов приведено в таблице 1.

Таблица 1

Сравнение исходной и оптимизированной архитектуры обработки результатов

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

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

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

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

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

Для реализации программного модуля был выбран язык C# и платформа.NET, поскольку они соответствуют существующей инфраструктуре проекта, поддерживают статическую типизацию, асинхронное программирование, развитую систему управления зависимостями и эксплуатацию в Docker-контейнерах. В качестве основной среды разработки использовалась Microsoft Visual Studio, обеспечивающая удобную работу с многопроектными решениями, отладкой и инструментами анализа кода.

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

Расчетная оценка до 150 тысяч участников получена не как утверждение о проведенном старте такого размера, а как экстраполяция фактической нагрузки. Если принять мероприятие на 30 тысяч участников за один профиль пикового дня, то способность системы выдерживать около пяти таких профилей соответствует примерно 150 тысячам участников. Такой способ оценки удобен для практической эксплуатации, поскольку организатору важна не абстрактная пропускная способность сервера, а число стартов и участников, которое можно обслужить без заметной деградации пользовательского сценария.

Сводные результаты оценки производительности приведены в таблице 2.

Таблица 2

Результаты практической и расчетной оценки производительности

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

Особенно важным оказалось исключение лишних обращений к СУБД из горячего пути обработки отсечек. База данных продолжает использоваться как надежное хранилище исходных и агрегированных данных, однако основные вычисления выполняются в памяти сервисов. Это позволяет уменьшить задержки, снизить конкуренцию за ресурсы СУБД и обеспечить более предсказуемое поведение при пиковых нагрузках.

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

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

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

Литература:

1. Кудрявцев Д. Н. Отчет по учебной практике (ознакомительной практике). — М.: НИУ МИЭТ, 2024.
2. Кудрявцев Д. Н. Отчет по технологической (проектно-технологической) практике. — М.: НИУ МИЭТ, 2025.
3. RabbitMQ Documentation. Work Queues and Publisher Confirms. — URL: https://www.rabbitmq.com/docs (дата обращения: 25.04.2026).
4. Microsoft Learn..NET documentation. — URL: https://learn.microsoft.com/dotnet/ (дата обращения: 25.04.2026).
5. Grafana Labs. k6 Documentation. — URL: https://grafana.com/docs/k6/ (дата обращения: 25.04.2026).
6. Microsoft Learn. SQL Server documentation. — URL: https://learn.microsoft.com/sql/ (дата обращения: 25.04.2026).