Визначте одну одиницю корисної роботи
Для внутрішнього експорту 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 MiB на активний експорт, чотири одночасні експорти вже означають близько 1,200 MiB до накладних витрат середовища виконання. Це вхідні дані для планування, а не бенчмарки. Додайте з'єднання з базою даних, пам'ять запитів, тимчасовий диск і пропускну здатність виводу; кількість процесів — лише один ліміт.
Відрепетируйте з одним активним експортом і реалістичним відставанням. Збільште до двох, повторюючи той самий трафік API. Порівняйте завершені корисні експорти, вік найстарішого завдання, затримку, збої та тиск на хост. Якщо пропускна здатність ледь покращується, а очікування бази даних зростають, припиніть збільшувати паралелізм. Додатковий CPU може не усунути це вузьке місце.
Зупиніть збій від створення більшого навантаження
Класифікуйте помилки перед повторною спробою. Тимчасовий збій сховища може бути транзиторним; неавторизований обліковий запис або непідтримуваний формат експорту потребує термінальної помилки або втручання. Використовуйте скінченний бюджет спроб і відкладені повторні спроби з відступом і джиттером, де це підтримується. Тримайте невдалі завдання доступними для перевірки з видаленими чутливими полями.
Застосуйте тайм-аути до зовнішніх викликів і загальний бюджет завдання. Скасування спроби не доводить, що її віддалений побічний ефект не стався. Публікація з тайм-аутом могла вже записати вивід. Узгоджуйте за ідентифікатором експорту, а не публікуйте інший результат наосліп.
Включіть воркерів у розгортання та відновлення
Зупиніть нову роботу на старому воркері, використовуючи його документовану поведінку завершення. Дайте роботі в процесі завершитися або безпечно перервіть її в межах відомого дедлайну. Перевірте збій після запису виводу, але до фіксації завершення; замісна спроба має знайти узгоджений результат, а не дублювати його.
Підтримуйте сумісність форматів повідомлень між перекривними релізами. Новий API може поставити в чергу корисне навантаження, яке старий воркер не може прочитати. Версіонуйте контракт або впорядкуйте розгортання так, щоб підтримувані споживачі існували до появи нових повідомлень. Включіть цих авторів бази даних у перегляд сумісності схеми.
Виберіть наступне обмеження для зміни
Залиште налаштування паралелізму, політику повторних спроб, контракт завдання та вимірюване правило зупинки. Якщо дорогі експорти затримують малі завдання, розгляньте окремі черги з незалежними бюджетами, перш ніж підвищувати глобальний ліміт. Якщо затримка API страждає за будь-якого реалістичного навантаження експорту, розділення воркерів може бути кориснішим, ніж збільшення одного спільного хоста.
Повторіть те саме навантаження після зміни та збережіть порівняння. Сценарій API та воркерів пояснює, де App 2 і додаткова пам'ять входять у вибір. Ці процедури не передбачають керованої черги, необмежених завдань або автоматичного масштабування.
Офіційні посилання
Документацію переглянуто для цієї статті. Приклади — це планувальні вправи, а не команди, перевірені на сервері PrivacyNodes. Перевірте документацію для вашої встановленої версії.