Тесты СинергияАртём Хелп
Артём Help онлайнПолучить расчёт
Бесплатно оценим сроки и стоимостьОтправить задание в Telegram
Разработка высоконагруженных игровых серверов.dor_БАК_25-239-Б

Разработка высоконагруженных игровых серверов.dor_БАК_25-239-Б — вариант 8

Просмотрите все вопросы и варианты бесплатно. Правильные ответы скрыты и открываются только после получения доступа.

14 вопросов Вариант 8 Доступ 7 дней
Содержание теста

Вопросы и варианты

Без отметок и подсказок к правильным ответам

Вопрос 1

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

  1. Хранить сессии в памяти каждого процесса и включить sticky-sessions на балансировщике
  2. Перенести сессии во внешнее общее хранилище (например, Redis), сделав приложение максимально stateless
  3. Хранить всё состояние в JWT (JSON Web Token) без сроков жизни и без механизма отзыва
  4. Оставить одну машину «мастером» для всех авторизованных запросов
Вопрос 2

Нужно резко снизить нагрузку на бэкенд при раздаче статики и ускорить отдачу по миру. Что необходимосделать в первую очередь?

  1. Отключить кэширование для CSS (Cascading Style Sheets) /JS (JavaScript) и отдавать их только с origin-сервера
  2. Включить агрессивное кэширование версиированных статических файлов (public, max-age=31536000, immutable) и раздавать их через CDN (Content Delivery Network) /прокси-кэш
  3. Перенаправлять клиентов 302 на «менее загруженный» сервер
  4. Кэшировать персонализированные страницы, зависящие от cookie, на уровне прокси
Вопрос 3

На PvP-сервере (Player versus Player) периодически теряются отдельные апдейты позиций, из-за чего на TCP (Transmission Control Protocol) возникают «фризы». Какое решение уместнее для потоков частых небольших обновлений состояния?

  1. Перейти на UDP (User Datagram Protocol) для игровых апдейтов, реализовав на уровне приложения минимальные гарантия/дедупликацию
  2. Увеличить RTO (Recovery Time Objective) и ждать доставки каждого пакета
  3. Форсировать Nagle, чтобы меньше пакетов
  4. Запретить Window Scaling
Вопрос 4

В часы пика резко растут RTT (Real-Time Text) и появляется джиттер. Трассировка показывает перегруженный граничный роутер и длинный маршрут. Что в первую очередь предпринять на стороне архитектуры сервиса?

  1. Включить CDN (Content Delivery Network) /региональные точки присутствия ближе к игрокам
  2. Поднять tcp_fin_timeout
  3. Отключить keep-alive
  4. Увеличить MSS (Maximum Segment Size) до произвольного значения
Вопрос 5

Веб-клиент игры часто запрашивает один и тот же JSON (JavaScript Object Notation); нужно снизить трафик без изменения API (Application programming interface). Что необходимо внедрить в первую очередь?

  1. ETag и обработку If-None-Match
  2. Постоянные 301 редиректы на этот же URL (Uniform Resource Locator)
  3. No-store для всех ответов
  4. Отключить gzip
Вопрос 6

После миграции API (Application programming interface) на новый путь надо перевести старых клиентов, не ломая POST/PUT. Что необходимо выбрать?

  1. 302
  2. 303
  3. 307/308
  4. 301
Вопрос 7

Вечером растут RTT (Real-Time Text) и джиттер у игроков из разных регионов; один входной адрес обслуживает весь мир. Какое архитектурное решение в первую очередь снизит задержку без изменения игрового протокола?

  1. Перейти с L7 на L4 в том же регионе
  2. Включить Geo-DNS/latency-based DNS (Domain Name System) и завести региональные кластеры
  3. Увеличить размеры пакетов на сервере
  4. Отключить health-checks
Вопрос 8

Вы выводите один игровой инстанс на обновление без «выбивания» игроков. Что необходимо настроить на балансировщике и в процессе выката?

  1. Немедленный stop сервера и рестарт пула
  2. Перевод узла в draining + запрет новых матчей, дождаться завершения активных сессий
  3. Принудительный редирект всех игроков на новый инстанс
  4. Отключить VRRP (Virtual Router Redundancy Protocol)
Вопрос 9

Профилирование показало высокий LLC (Load-Line Calibration) miss rate из-за случайного обхода большого массива структур. Какое действие даст наибольший прирост производительности без изменения алгоритмической сложности?

  1. Перейти на последовательный блочный обход (tiling) и/или хранить данные в массиве (AoS→SoA)
  2. Включить no-store для всех ответов HTTP (HyperText Transfer Protocol)
  3. Увеличить количество потоков без пиннинга
  4. Записать массив на SSD (Solid-State Drive) и memory-map’ить его
Вопрос 10

На двухсокетном сервере выросла средняя латентность памяти ~50% после миграции: рабочие потоки «прыгают» между сокетами, данные выделяются «где придётся». Что необходимо сделать в первую очередь?

  1. Переехать на более быстрый SSD (Solid-State Drive)
  2. Закрепить потоки за ядрами (CPU (Central Processing Unit) affinity) и выделять память локально узлу (numa/mbind), разделив данные по узлам
  3. Отключить L3-кэш
  4. Уменьшить размер страницы до 1 КБ
Вопрос 11

У вас база данных с критичными к потере транзакциями. Нужно минимизировать риск потери данных при падении мастера, сохранив приемлемую задержку. Что необходимо выбрать в первую очередь?

  1. Полусинхронную репликацию (мастер ждёт хотя бы одну реплику)
  2. Чисто асинхронную репликацию
  3. Отключить WAL (Write-Ahead Logging) для ускорения
  4. Полную синхронию со всеми репликами в разных регионах
Вопрос 12

Профилирование показало, что основная задержка — случайные чтения на HDD (hard disk drive) (десятки IOPS (input/output operations per second)). Нужно резко ускорить OLTP-нагрузку (Online Transaction Processing). Что необходимо предпринять?

  1. Перенести «горячий» набор данных на SSD/RAID10 SSD (Solid-State Drive); остальное оставить на HDD (hard disk drive)
  2. Увеличить размер кластера файловой системы, не меняя носители
  3. Включить write-back кэш операционной системы и не использовать fsync
  4. Перейти на JBOD (Just a bunch of disk) без избыточности
Вопрос 13

В проде участились таймауты при вызове сервиса «Профили». Нужно снизить влияние сбоя на матчмейкинг. Что необходимо внедрить в первую очередь?

  1. Circuit Breaker с быстрым фолбэком (дефолтные данные/скрытие блока) и таймауты + retry-схему с backoff
  2. Увеличить таймауты до бесконечности
  3. Синхронно дергать «Профили» из каждого сервиса в цепочке
  4. Отключить алертинг, чтобы не мешал
Вопрос 14

Вечером пиковая нагрузка: запись результатов матча замедляет ответы игрового API (Application programming interface). Как поступить, чтобы сохранить отзывчивость?

  1. Писать всё синхронно в базе данных в рамках запроса
  2. Перенести запись вторичных данных (агрегации, рейтинги) в отложенную обработку через брокера сообщений; в API (Application programming interface) вернуть подтверждение при фиксации минимального факта победы
  3. Запретить кэш и увеличить логирование до trace для каждого запроса
  4. Удалить метрики, чтобы сэкономить CPU (Central Processing Unit)