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

1. Механизм сохранения состояния (State Persistence)

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

Стратегия заключается в записи текущего статуса обработки (например, обработано 1500 из 5000 записей) и контекста (последняя обработанная запись, ошибки, метаданные). При перезапуске worker читает этот файл и продолжает работу с последней успешной точки.

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

2. Файловая система как хранилище: использование JSON или Pickle

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

Pickle (в Python) позволяет сохранять сложные объекты, но менее безопасен при работе с ненадежными источниками данных и сложнее для чтения другими системами. Для переносимости выбирайте JSON.

Пример структуры файла состояния: {"processed_count": 1500, "last_id": 1499, "status": "running", "errors": []}. Это позволяет быстро оценить прогресс без парсинга всего контента.

3. Структура файла прогресса: определение полей

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

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

Не храните в файле состояния сами большие данные (тексты, изображения). Ссылайтесь только на их идентификаторы или пути к файлам.

4. Обработка ошибок при чтении

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

Если файл существует, но поврежден (например, некорректный JSON), не пытайтесь восстановить данные из него. Логгер должен записать ошибку, а процесс перезапуститься с чистого листа или с последней известной верифицированной точки.

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

5. Синхронизация локального и облачного состояния

Если вы используете гибридную архитектуру с локальным Ollama и облачным API, состояние должно учитывать доступность обоих источников.

Сохраняйте в файле флаг последнего использованного источника (локальный или облачный). При перезапуске worker проверяет статус локального узла. Если он недоступен, автоматически переключает логику на облачный источник.

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

6. Таймауты и контроль времени ожидания

Настройте таймауты для запросов к локальному узлу (например, 5–10 секунд). Если ответ не приходит в течение этого времени, считайте запрос неудачным.

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

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

7. Восстановление после сбоя сети

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

Если оба источника недоступны, процесс завершается с ошибкой, но файл состояния остается неизменным. При следующем запуске worker проверит статус источников и выберет доступный вариант.

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

8. Очистка устаревших файлов прогресса

Если вы запускаете несколько параллельных процессов или используете разные среды, создавайте файлы состояния с уникальными именами (например, по ID задачи или времени создания).

Реализуйте механизм очистки старых файлов. Например, удаляйте файлы старше 24 часов или те, которые относятся к завершенным задачам.

Не удаляйте файлы состояния во время активной обработки. Используйте отдельный процесс или планировщик для очистки.

Вопросы и ответы

Как часто нужно обновлять файл состояния?

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

Что делать, если файл состояния поврежден?

Если файл поврежден, не пытайтесь его исправить вручную. Запишите ошибку в лог и перезапустите процесс с чистого листа или с последней верифицированной точки из резервной копии.

Можно ли использовать базу данных вместо файла?

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

По теме

Похожие статьи