Advisory locks у PostgreSQL для розподіленого планування завдань

Припиніть додавати Redis або SQS до свого стека лише заради планування завдань.

Замість цього ви можете використовувати advisory locks у PostgreSQL. Такий підхід позбавляє потреби в новій інфраструктурі.

У моїх тестах така конфігурація обробляє 10 000 завдань на хвилину на одному екземплярі бази даних. Вона часто перевершує Redis за затримкою (latency), оскільки ваші воркери вже мають підключення до бази даних. Ви уникаєте зайвого мережевого стрибка (network hop).

Як це реалізувати:

• Використовуйте pg_try_advisory_xact_lock для захоплення завдань. • Використовуйте FOR UPDATE SKIP LOCKED для обробки конкуренції за рядки. • Використовуйте транзакційний варіант, щоб уникнути витоку блокувань.

Чому транзакційні блокування мають значення:

Транзакційні блокування звільняються автоматично, коли транзакція завершується (commit) або відкочується (rollback). Це запобігає появі «сирітських» (orphaned) блокувань у разі збою вашого додатка. Це також безпечно працює з PgBouncer у режимі транзакцій.

Уникайте сесійних блокувань (session locks), якщо використовуєте PgBouncer. PgBouncer перепризначає підключення між транзакціями. Це порушує блокування на рівні сесії та призводить до прихованих помилок.

Якщо вам потрібні сесійні блокування, створіть окремий пул підключень для ваших воркерів. Не змішуйте веб-трафік і трафік воркерів завдань в одному пулі.

Масштабування за допомогою ключів:

Advisory locks використовують bigint або два цілих числа. Використання двох цілих чисел забезпечує природне розділення просторів імен (namespacing). Якщо ви хешуєте текстові ключі у bigint, стежте за колізіями. Кількість колізій залишається низькою, поки ви не досягнете 100 000 унікальних ID блокувань. Після цього використовуйте форму з двома цілими числами для безпеки.

Компроміс:

• Advisory locks виграють завдяки простоті та низьким експлуатаційним витратам. • Redis виграє за показниками чистої пропускної здатності та горизонтального масштабування.

Більшості команд не потрібно більше 10 000 завдань на хвилину. Якщо ви перебуваєте нижче цього ліміту, використовуйте PostgreSQL. Це дозволить зберегти архітектуру чистою, а витрати — низькими.

Джерело: https://dev.to/software_mvp-factory/postgresql-advisory-locks-for-distributed-job-scheduling-15kp