# P25-B. Ray: акторы и восстановление

- **Версия и дата проверки:** 1.1, 07.09.2026.
- **Статус:** готово к назначению.

## Статья и исходные материалы

- **Основная статья:** Philipp Moritz и соавт. — [Ray: A Distributed Framework for Emerging AI Applications](https://www.usenix.org/conference/osdi18/presentation/moritz). OSDI 2018.
- **Кратко о статье:** Приложения машинного обучения сочетают динамические графы задач с долгоживущим изменяемым состоянием. Ray предоставляет для них общую модель удалённых функций и акторов, дополняя её распределённым планированием, объектным хранилищем и механизмами восстановления. В этом проекте исследуется граница между состоянием актора, повторным выполнением задач и внешним сохранением данных при сбоях.
- **Почему результат актуален:** Ray объединяет задачи и акторы в одном распределённом runtime, рассчитанном на динамические графы вычислений, возникающие в обучении с подкреплением и других ИИ-приложениях.
- **Артефакты и данные:** [ray-project/ray](https://github.com/ray-project/ray), открытая система с локальным кластерным режимом и актуальной документацией. Зафиксированная основная ревизия: `ray-project/ray@2ff4d94078ee` (Apache-2.0).
- **Что уже предоставляет артефакт:** Ray предоставляет акторы, выполнение задач и механизмы перезапуска. Их разрешено использовать как runtime для собственного приложения; политику сохранения прикладного состояния задаёт команда.

## Обязательный результат

- **Проверяемый вопрос или утверждение:** Модель акторов упрощает долгоживущее изменяемое состояние, но гарантии восстановления и цена повторного выполнения зависят от границы между состоянием актора, задачами и внешним хранилищем.
- **Технический результат:** Реализовать локальное приложение из нескольких stateful-акторов и клиентов с журналом операций, контрольными суммами и управляемыми падениями. Добавить как минимум две стратегии восстановления состояния.
- **Обязательное приращение команды:** Создать предусмотренное приложение с журналом и контрольными суммами, две стратегии восстановления и процессный baseline. Организовать управляемые отказы worker и актора, независимую проверку конечного состояния и учёт потерянных, повторных операций и повторной работы.
- **Эксперимент:** Сравнить restart без внешнего состояния, checkpoint/replay и простой процессный baseline при отказе worker и актора. Измерить время восстановления, потерянные или повторные операции, p95/p99, объём повторной работы и правильность конечного состояния минимум в трёх сериях.
- **Границы выводов:** гарантии и цена восстановления проверяются для выбранного приложения акторов, стратегий хранения и локальных отказов; результат не устанавливает общую семантику долговечности Ray и поведение крупного кластера.
- **Ресурсный профиль:** локально, CPU, 8–16 ГБ памяти; масштаб статьи не воспроизводится, проверяется механизм на одном компьютере с несколькими процессами.

## Содержательные направления

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

## Возможное продолжение

Добавить placement groups, репликацию состояния, backpressure, цепочку акторов или отказ во время checkpoint.