Сайт Романа ПарпалакаБлог20230415

Храните состояние долгоживущих процессов в базе данных, а не в памяти

15 апреля 2023 года, 00:47

Долгоживущие процессы давно стали важной частью веб-приложений и сервисов. Они выполняют фоновые задачи (обработка данных, формирование отчетов), служебные задачи по расписанию, обрабатывают асинхронные запросы и ответы. При их разработке нужно учитывать не только функциональные требования (это такие требования, без выполнения которых заказчик не примет работу), но и нефункциональные, например: надежность и отказоустойчивость, observability («наблюдаемость», прозрачность работы), обслуживаемость, масштабируемость.

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

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

Какие преимущества получаем от хранения состояния долгоживущих процессов в базе данных?

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

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

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

Наблюдаемость состояния в админке. Когда состояние хранится в базе данных, его легко вывести в админке. Таким образом, вы сделаете работу приложения наблюдаемым. Иначе ваше рабочее время будет уходить на однотипные вопросы коллег, реагирующих на обращения пользователей: «что случилось с заявкой №782354, запрос ушел, но ответа не было?»

Совет, вынесенный в заголовок, не нов. Делать процессы без состояния (stateless) — одно из требований к 12-факторным приложениям.

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

Поделиться

Отложенная загрузка картинок через атрибут lazyload Ctrl Срываем покровы

Читайте также

Очередь на основе PHP-FPM
Применил на практике прием, когда асинхронная очередь обработки сообщений реализовывается через PHP-FPM по протоколу fastcgi. На удивление, всё заработало сразу, никакой наладки не потребовалось.
2020

Оставьте свой комментарий


Формулы на латехе: $$f(x) = x^2-\sqrt{x}$$ превратится в $$f(x) = x^2-\sqrt{x}$$.
Выделение текста: [i]курсивом[/i] или [b]жирным[/b].
Цитату оформляйте так: [q = имя автора]цитата[/q] или [q]еще цитата[/q].
Других команд или HTML-тегов здесь нет.

Записи