💡 Инструкция: Выберите один ответ из пяти. На 30 вопросов отведено 85 минут. В каждом задании верен только один вариант. Фрагменты относятся к Scala 3; внешняя библиотека названа прямо в коде или условии.
Вопрос 3 из 30
При исправлении темы «Обратное давление» что следует изменить, чтобы следующий рефакторинг не вернул тот же риск?
Scala Обратное давление: решение на ревью Копировать
import akka.stream.scaladsl.Source
val stream = Source(1 to 1000).buffer(32, akka.stream.OverflowStrategy.backpressure)
// На ревью требуется устранить причину дефекта, не скрывая её приведением типа или значением по умолчанию.
Увеличить каждый буфер до максимально возможного размера и считать проблему медленного потребителя решённой.
Разделяйте дефект, плохой элемент и временный отказ; для каждого задайте журналирование, повтор и допустимость потери.
Задайте ограниченный буфер и осознанную политику: замедление, отбрасывание, объединение или отказ с сигналом.
Рисуйте направление спроса и данных, проверяйте циклы, буферы и точки асинхронного выполнения отдельно.
Заменить backpressure на отбрасывание элементов, не сообщая потребителю о потере данных.
Вопрос 4 из 30
В контракте темы «Обратное давление» что следует оставить в проектном решении после этого изменения контекста?
\lambda_{in}\le\mu_{out}
Граф потока описывает узлы и связи, включая слияние и разветвление; материализация создаёт работающий экземпляр графа; широкое правило `resume` может молча потерять данные и оставить зависимый сервис в логически неполном состоянии.
Обратное давление согласует скорость производителя и потребителя, не позволяя бесконтрольно накапливать элементы в памяти; одна зелёная проверка заменяет отдельные тесты на отмену, повтор и освобождение ресурса.
Надёжность в эксплуатации включает ограничение ресурсов, корректное завершение, повтор с backoff и сохранение позиции чтения; неограниченный буфер лишь откладывает перегрузку: задержка и память растут, пока процесс не станет нестабильным.
Обратное давление согласует скорость производителя и потребителя, не позволяя бесконтрольно накапливать элементы в памяти; одного журнала «stream stopped» недостаточно: он не показывает, где появился спрос, задержка или отказ.
Обратное давление согласует скорость производителя и потребителя, не позволяя бесконтрольно накапливать элементы в памяти; неограниченный буфер лишь откладывает перегрузку: задержка и память растут, пока процесс не станет нестабильным.
Вопрос 5 из 30
При проверке темы «Обратное давление» какой итог можно проверить автоматически или воспроизводимым примером?
В теме «Обратное давление» исправить один показанный вызов по рекомендации «Рисуйте направление спроса и данных, проверяйте циклы, буферы и точки асинхронного выполнения отдельно». Общий контракт и прежнюю границу отдельно не воспроизводить.
Задайте ограниченный буфер и осознанную политику: замедление, отбрасывание, объединение или отказ с сигналом. В проверке воспроизвести ситуацию: неограниченный буфер лишь откладывает перегрузку: задержка и память растут, пока процесс не станет нестабильным.
Задайте ограниченный буфер и осознанную политику: замедление, отбрасывание, объединение или отказ с сигналом. В проверке воспроизвести ситуацию: одного журнала «stream stopped» недостаточно: он не показывает, где появился спрос, задержка или отказ.
Обратное давление согласует скорость производителя и потребителя, не позволяя бесконтрольно накапливать элементы в памяти. Убедиться лишь в успешном запуске, не фиксируя статический тип.
Разделяйте дефект, плохой элемент и временный отказ; для каждого задайте журналирование, повтор и допустимость потери. В проверке воспроизвести ситуацию: неограниченный буфер лишь откладывает перегрузку: задержка и память растут, пока процесс не станет нестабильным.
Вопрос 9 из 30
В контракте темы «Граф потока» поток перезапустили после ошибки, когда часть элементов уже дошла до внешней системы. Какой вывод одновременно сохраняет правило и учитывает его границу?
B\approx\lambda W
Наблюдаемость потока требует метрик пропускной способности, задержки, буферов, повторов и причины завершения. Учитывать границу: цикл без буфера или асинхронной границы может образовать взаимное ожидание и остановить весь граф.
Граф потока описывает узлы и связи, включая слияние и разветвление; материализация создаёт работающий экземпляр графа. Учитывать границу: выбросить materialized value значит потерять возможность дождаться завершения, остановить поток или заметить ошибку.
Ошибка stage по умолчанию завершает поток; supervision или recover меняют судьбу элемента и всего графа. Учитывать границу: одного журнала «stream stopped» недостаточно: он не показывает, где появился спрос, задержка или отказ.
Граф потока описывает узлы и связи, включая слияние и разветвление; материализация создаёт работающий экземпляр графа. Учитывать границу: цикл без буфера или асинхронной границы может образовать взаимное ожидание и остановить весь граф.
Граф потока описывает узлы и связи, включая слияние и разветвление; материализация создаёт работающий экземпляр графа. Учитывать границу: если код компилируется, дополнительные проверки вывода типов и поиска `given` не нужны.
Вопрос 12 из 30
Для темы «Ошибки» какой пограничный случай относится к контракту, а не только к стилю записи?
Scala Ошибки: изменившийся контекст Копировать
// Дополнительный контекст: Поток перезапустили после ошибки, когда часть элементов уже дошла до внешней системы.
val safe = akka.stream.scaladsl.Flow[String].map(_.toInt).recover { case _: NumberFormatException => 0 }
Проверка границы должна учитывать, что широкое правило `resume` может молча потерять данные и оставить зависимый сервис в логически неполном состоянии.
Проверка границы должна учитывать, что материализованный `Future` не может завершиться ошибкой, если источник успел выдать хотя бы один элемент.
Проверка границы должна учитывать, что неограниченная очередь перед потоком безопаснее ограниченной: она предотвращает отказ при всплеске нагрузки.
Проверка границы должна учитывать, что неограниченный буфер лишь откладывает перегрузку: задержка и память растут, пока процесс не станет нестабильным.
Проверка границы должна учитывать, что выбросить materialized value значит потерять возможность дождаться завершения, остановить поток или заметить ошибку.
Вопрос 17 из 30
Для темы «Материализация» какой пограничный случай относится к контракту, а не только к стилю записи?
Scala Материализация: изменившийся контекст Копировать
// Дополнительный контекст: Производитель ускорился, потребитель замедлился, а между ними появился ограниченный буфер.
import akka.stream.scaladsl.*
import akka.stream.*
val runnable = Source(1 to 10).toMat(Sink.seq)(Keep.right)
Одного обычного запуска недостаточно, поскольку широкое правило `resume` может молча потерять данные и оставить зависимый сервис в логически неполном состоянии.
Одного обычного запуска недостаточно, поскольку выбросить materialized value значит потерять возможность дождаться завершения, остановить поток или заметить ошибку.
Одного обычного запуска недостаточно, поскольку побочный эффект в `map` выполняется ровно один раз, даже если поток перезапускается после ошибки.
Одного обычного запуска недостаточно, поскольку неограниченная очередь перед потоком безопаснее ограниченной: она предотвращает отказ при всплеске нагрузки.
Одного обычного запуска недостаточно, поскольку цикл без буфера или асинхронной границы может образовать взаимное ожидание и остановить весь граф.
Вопрос 19 из 30
В контракте темы «Материализация» условия эксплуатации изменились, но синтаксис остался прежним. Что теперь важно удержать вместе?
Материализованное значение — результат запуска графа: Future завершения, управление очередью, KillSwitch или пользовательская метрика. Пограничный сценарий: успешная обработка одного значения подтверждает совместимость всех вариантов модели.
Материализованное значение — результат запуска графа: Future завершения, управление очередью, KillSwitch или пользовательская метрика. Пограничный сценарий: выбросить materialized value значит потерять возможность дождаться завершения, остановить поток или заметить ошибку.
Материализованное значение — результат запуска графа: Future завершения, управление очередью, KillSwitch или пользовательская метрика. Пограничный сценарий: широкое правило `resume` может молча потерять данные и оставить зависимый сервис в логически неполном состоянии.
Наблюдаемость потока требует метрик пропускной способности, задержки, буферов, повторов и причины завершения. Пограничный сценарий: цикл без буфера или асинхронной границы может образовать взаимное ожидание и остановить весь граф.
Граф потока описывает узлы и связи, включая слияние и разветвление; материализация создаёт работающий экземпляр графа. Пограничный сценарий: выбросить materialized value значит потерять возможность дождаться завершения, остановить поток или заметить ошибку.
Вопрос 20 из 30
При проверке темы «Материализация» что поможет соседнему модулю не повторить ту же ошибку?
Выбирайте `Keep.left/right/both` осознанно и возвращайте наружу именно тот handle, которым владеет вызывающий слой. В проверке воспроизвести ситуацию: широкое правило `resume` может молча потерять данные и оставить зависимый сервис в логически неполном состоянии.
Выбирайте `Keep.left/right/both` осознанно и возвращайте наружу именно тот handle, которым владеет вызывающий слой. В проверке воспроизвести ситуацию: выбросить materialized value значит потерять возможность дождаться завершения, остановить поток или заметить ошибку.
Материализованное значение — результат запуска графа: Future завершения, управление очередью, KillSwitch или пользовательская метрика. Ограничиться ручным запуском без автоматической регрессии.
В теме «Материализация» исправить один показанный вызов по рекомендации «Задайте ограниченный буфер и осознанную политику: замедление, отбрасывание, объединение или отказ с сигналом». Общий контракт и прежнюю границу отдельно не воспроизводить.
Разделяйте дефект, плохой элемент и временный отказ; для каждого задайте журналирование, повтор и допустимость потери. В проверке воспроизвести ситуацию: выбросить materialized value значит потерять возможность дождаться завершения, остановить поток или заметить ошибку.
Вопрос 24 из 30
В контракте темы «Наблюдаемость и диагностика» какое решение не превращает частный успешный случай в общее обещание?
Оставить в контракте правило «граф потока описывает узлы и связи, включая слияние и разветвление; материализация создаёт работающий экземпляр графа»; проверяемое ограничение — «одного журнала «stream stopped» недостаточно: он не показывает, где появился спрос, задержка или отказ».
Оставить в контракте правило «наблюдаемость потока требует метрик пропускной способности, задержки, буферов, повторов и причины завершения»; проверяемое ограничение — «неограниченный буфер лишь откладывает перегрузку: задержка и память растут, пока процесс не станет нестабильным».
Оставить в контракте правило «наблюдаемость потока требует метрик пропускной способности, задержки, буферов, повторов и причины завершения»; проверяемое ограничение — «одного журнала «stream stopped» недостаточно: он не показывает, где появился спрос, задержка или отказ».
Оставить в контракте правило «материализованное значение — результат запуска графа: Future завершения, управление очередью, KillSwitch или пользовательская метрика»; проверяемое ограничение — «автоматический бесконечный restart может бесконечно повторять ядовитый элемент и создавать шторм запросов».
Оставить в контракте правило «наблюдаемость потока требует метрик пропускной способности, задержки, буферов, повторов и причины завершения»; проверяемое ограничение — «результат одного измерения можно считать устойчивой характеристикой производительности».
Вопрос 25 из 30
При проверке темы «Наблюдаемость и диагностика» какой контроль остаётся полезным после рефакторинга и переименования кода?
Добавляйте метки этапов, идентификатор корреляции и метрики на границах; завершение материализованного потока записывайте вместе с причиной. В проверке воспроизвести ситуацию: неограниченный буфер лишь откладывает перегрузку: задержка и память растут, пока процесс не станет нестабильным.
Добавляйте метки этапов, идентификатор корреляции и метрики на границах; завершение материализованного потока записывайте вместе с причиной. В проверке воспроизвести ситуацию: одного журнала «stream stopped» недостаточно: он не показывает, где появился спрос, задержка или отказ.
Ограничивайте число повторов, отделяйте проблемное сообщение, сохраняйте checkpoint только после подтверждённой обработки. В проверке воспроизвести ситуацию: одного журнала «stream stopped» недостаточно: он не показывает, где появился спрос, задержка или отказ.
В теме «Наблюдаемость и диагностика» исправить один показанный вызов по рекомендации «Разделяйте дефект, плохой элемент и временный отказ; для каждого задайте журналирование, повтор и допустимость потери». Общий контракт и прежнюю границу отдельно не воспроизводить.
Наблюдаемость потока требует метрик пропускной способности, задержки, буферов, повторов и причины завершения. Проверить один объект и не рассматривать разделяемое состояние.
Вопрос 26 из 30
Какая характеристика конструкции «Надёжность в эксплуатации» подтверждается показанным фрагментом?
Scala Надёжность в эксплуатации: чтение фрагмента Копировать
import akka.stream.scaladsl.{RestartSource, Source}
import scala.concurrent.duration.*
val source = Source(1 to 100)
val restarted = RestartSource.withBackoff(
minBackoff = 1.second,
maxBackoff = 30.seconds,
randomFactor = 0.2
)(() => source)
Обратное давление согласует скорость производителя и потребителя, не позволяя бесконтрольно накапливать элементы в памяти.
Материализованное значение совпадает с последним элементом потока независимо от выбранных `Keep.left`, `Keep.right` или `Keep.both`.
Обратное давление означает, что быстрый производитель продолжает писать без ограничений, а потребитель пропускает лишние элементы.
Надёжность в эксплуатации включает ограничение ресурсов, корректное завершение, повтор с backoff и сохранение позиции чтения.
Граф потока описывает узлы и связи, включая слияние и разветвление; материализация создаёт работающий экземпляр графа.
Вопрос 28 из 30
При исправлении темы «Надёжность в эксплуатации» нужно устранить причину, а не замаскировать симптом. Какое изменение подходит лучше?
Scala Надёжность в эксплуатации: решение на ревью Копировать
import akka.stream.scaladsl.{RestartSource, Source}
import scala.concurrent.duration.*
val source = Source(1 to 100)
val restarted = RestartSource.withBackoff(
minBackoff = 1.second,
maxBackoff = 30.seconds,
randomFactor = 0.2
)(() => source)
// На ревью требуется устранить причину дефекта, не скрывая её приведением типа или значением по умолчанию.
Ограничивайте число повторов, отделяйте проблемное сообщение, сохраняйте checkpoint только после подтверждённой обработки.
Выбирайте `Keep.left/right/both` осознанно и возвращайте наружу именно тот handle, которым владеет вызывающий слой.
Разделяйте дефект, плохой элемент и временный отказ; для каждого задайте журналирование, повтор и допустимость потери.
Увеличить каждый буфер до максимально возможного размера и считать проблему медленного потребителя решённой.
Использовать RestartSource для любой ошибки без классификации причины и ограничения числа повторов.
Вопрос 29 из 30
В контракте темы «Надёжность в эксплуатации» после изменения окружения команда пересматривает контракт. Какой вариант корректен?
Надёжность в эксплуатации включает ограничение ресурсов, корректное завершение, повтор с backoff и сохранение позиции чтения. При этом учитывать: автоматический бесконечный restart может бесконечно повторять ядовитый элемент и создавать шторм запросов.
Надёжность в эксплуатации включает ограничение ресурсов, корректное завершение, повтор с backoff и сохранение позиции чтения. При этом учитывать: одного журнала «stream stopped» недостаточно: он не показывает, где появился спрос, задержка или отказ.
Граф потока описывает узлы и связи, включая слияние и разветвление; материализация создаёт работающий экземпляр графа. При этом учитывать: широкое правило `resume` может молча потерять данные и оставить зависимый сервис в логически неполном состоянии.
Обратное давление согласует скорость производителя и потребителя, не позволяя бесконтрольно накапливать элементы в памяти. При этом учитывать: автоматический бесконечный restart может бесконечно повторять ядовитый элемент и создавать шторм запросов.
Надёжность в эксплуатации включает ограничение ресурсов, корректное завершение, повтор с backoff и сохранение позиции чтения. При этом учитывать: прохождение happy path исключает ошибки сериализации на старых и неполных данных.
Вопрос 30 из 30
При проверке темы «Надёжность в эксплуатации» какая проверка связывает принятую правку с реальной границей решения?
Надёжность в эксплуатации включает ограничение ресурсов, корректное завершение, повтор с backoff и сохранение позиции чтения. Считать отсутствие исключения достаточным подтверждением контракта.
В теме «Надёжность в эксплуатации» исправить один показанный вызов по рекомендации «Выбирайте `Keep.left/right/both` осознанно и возвращайте наружу именно тот handle, которым владеет вызывающий слой». Общий контракт и прежнюю границу отдельно не воспроизводить.
Разделяйте дефект, плохой элемент и временный отказ; для каждого задайте журналирование, повтор и допустимость потери. В проверке воспроизвести ситуацию: автоматический бесконечный restart может бесконечно повторять ядовитый элемент и создавать шторм запросов.
Ограничивайте число повторов, отделяйте проблемное сообщение, сохраняйте checkpoint только после подтверждённой обработки. В проверке воспроизвести ситуацию: автоматический бесконечный restart может бесконечно повторять ядовитый элемент и создавать шторм запросов.
Ограничивайте число повторов, отделяйте проблемное сообщение, сохраняйте checkpoint только после подтверждённой обработки. В проверке воспроизвести ситуацию: одного журнала «stream stopped» недостаточно: он не показывает, где появился спрос, задержка или отказ.