Определите одну единицу полезной работы
Для внутреннего экспорта CSV запрос создаёт запись экспорта; воркер читает ограниченный набор данных, записывает объект вывода и помечает запись завершённой. Определите максимальный полезный объём, лимит времени и поведение при отмене. Используйте изолированную очередь, тестовую базу данных и получатель, который не может уведомить реальных клиентов.
Отделите время вычислений от ожидания базы данных и хранилища. Одно число длительности задачи скрывает эти различия. Построение всего файла в памяти масштабируется иначе, чем потоковая передача ограниченных пакетов. Держите сообщение очереди достаточно малым, чтобы описать работу, не встраивая данные клиента или учётные данные.
Сделайте повторную доставку безопасной по дизайну
Используйте долговечный идентификатор экспорта, чтобы связать попытки с одним логическим результатом. Обеспечьте уникальность и атомарный переход владения/завершения в долговечном состоянии. Проверка существования экспорта и последующая вставка отдельным незащищённым шагом позволяет параллельным попыткам соревноваться. Публикация объекта и подтверждение сообщения очереди также образуют границу сбоя.
# Illustrative contract, not queue implementation
job_type: export-account-report
logical_result: EXPORT_RECORD_ID
input_scope: AUTHORIZED_ACCOUNT_AND_DATE_RANGE
attempt_limit: REVIEWED_FINITE_LIMIT
completion: ONE_PUBLISHED_RESULT_FOR_THIS_EXPORT
retry: CLASSIFIED_TRANSIENT_FAILURES_ONLY
failed_result: INSPECTABLE_WITHOUT_CUSTOMER_SECRETSCelery связывает позднее подтверждение с идемпотентными задачами и документирует случаи, когда подтверждение всё же происходит после завершения дочернего процесса. Опция очереди не создаёт ровно однократное выполнение. Изучите семантику повторной доставки вашей системы и спроектируйте результат приложения так, чтобы он выдерживал повторы.
Техническая справка: Поведение задач Celery.
Установите бюджет перед увеличением числа процессов
Для гипотетического воркера, использующего 300 МиБ на активный экспорт, четыре одновременных экспорта уже подразумевают около 1,200 МиБ до накладных расходов времени выполнения. Это входные данные для планирования, а не бенчмарки. Добавьте соединения с базой данных, память запросов, временный диск и пропускную способность вывода; количество процессов — лишь один из лимитов.
Проведите репетицию с одним активным экспортом и реалистичным отставанием. Увеличьте до двух, повторяя тот же трафик API. Сравните завершённые полезные экспорты, возраст самой старой задачи, задержку, сбои и нагрузку на хост. Если пропускная способность едва улучшается, а ожидания базы данных растут, прекратите увеличивать параллелизм. Дополнительный CPU может не устранить это узкое место.
Не позволяйте сбою создавать дополнительную нагрузку
Классифицируйте ошибки перед повторной попыткой. Временный сбой хранилища может быть преходящим; неавторизованный аккаунт или неподдерживаемый формат экспорта требуют терминальной ошибки или вмешательства. Используйте конечный бюджет попыток и отложенные повторы с экспоненциальной задержкой и дрожанием, где это поддерживается. Сохраняйте неудачные задачи доступными для inspection с удалёнными конфиденциальными полями.
Применяйте тайм-ауты к внешним вызовам и общий бюджет задачи. Отказ от попытки не доказывает, что её удалённый побочный эффект не произошёл. Публикация с истёкшим тайм-аутом могла уже записать результат. Сверяйте по ID экспорта, а не публикуйте другой результат вслепую.
Включите воркеры в развёртывание и восстановление
Остановите новую работу на старом воркере, используя его документированное поведение при завершении. Дайте текущей работе завершиться или безопасно прервите её в известный дедлайн. Проверьте сбой после записи вывода, но до фиксации завершения; повторная попытка должна найти согласованный результат, а не дублировать его.
Поддерживайте совместимость форматов сообщений между перекрывающимися релизами. Новый API может поставить в очередь полезную нагрузку, которую старый воркер не может прочитать. Версионируйте контракт или упорядочьте развёртывание так, чтобы поддерживаемые потребители существовали до появления новых сообщений. Включите этих писателей базы данных в обзор совместимости схемы.
Выберите следующее ограничение для изменения
Оставьте настройку параллелизма, политику повторов, контракт задачи и измеренное правило остановки. Если дорогие экспорты задерживают мелкие задачи, рассмотрите отдельные очереди с независимыми бюджетами, прежде чем повышать глобальный лимит. Если задержка API страдает при любой реалистичной нагрузке экспорта, разделение воркеров может быть полезнее, чем увеличение одного общего хоста.
Повторите ту же нагрузку после изменения и сохраните сравнение. Сценарий API и воркеров объясняет, где App 2 и дополнительная память входят в выбор. Эти процедуры не подразумевают управляемую очередь, неограниченные задачи или автоматическое масштабирование.
Официальные ссылки
Документация была проверена для этой статьи. Примеры — это планировочные упражнения, а не команды, протестированные на сервере PrivacyNodes. Проверьте документацию для вашей установленной версии.