В чем преимущество и недостатки 'Retry паттерн' и 'Настройка ожидания запроса в БД' для обхода взаимоблокировок?

Question

[golikoffegor]

Если рассматривать только кейсы "Retry паттерн" и "Настройка ожидания запроса в БД" для решения вопроса с взаимоблокировками в БД, то какой из них стоит выбрать и почему? И какие у них недостатки и преимущества относительно решения проблемы со взаимоблокировками?

Answer 1

[Василий Банников]

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

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

"Настройка ожидания запроса" - это зависит от того, что именно под этим подразумевается. Подозреваю, что это настройка timeout - оно нужно чтобы твой запрос не зависал на слишком долгое время в случае, если он ожидает чего-то (например снятия блокировки, которая была установлена в рамках другого запроса).

Answer 2

[mayton2019]

Я не очень понимаю зачем здесь тема БД выпячивается наперед. Шаблон Retry используется очень широко.
И это не к БД относится а к приложению. Мы использовали обычно Guava Retrying with exponential back-off
вот как в примерах пишут https://github.com/rholder/guava-retrying и это примениме не только к БД
а к любым внешним API (Rest/SOAP e.t.c.). Эта механика работае почти везде. Ей много лет и она
воплощена многих сетевых протоколах а не только в приложениях.

По поводу настроек БД. Я могу рассказать про Oracle. Update использует специальный неблокирующий
синтаксис NOWAIT
SELECT .... FOR UPDATE NOWAIT;
который мгновенно возвращает ошибку если не удалось захватить сет строк для обновления. Это подходит
для работы с UI и толстым клиентом например или с веб клиентом.

Например для джоба которы должен работать ночью и взяв например
1000 клиентов или фирм и обработать - предпочтителен подход блокировки всего курсора
SELECT .... FOR UPDATE;.
В этом случае другие джобы будут стоять в ожидании.

А для дневной OLTP активности лучше брать корткие операции с NOWAIT. Проконсультируйтесь с вашей
документацией по вашей БД поддерживается ли неблокирующая операция.

Еще посмотрите видео от Филиппа Дельгядо. Он рассказывал как работали с очередями в Postgres,
там есть интересные режимы блокировок когда не "все или ничего" а есть какой-то компромиссный
режим.

Вообще Retry и защита от перегрузок это броня и снаряд. Как DDOS. Если вы с одной стороны внедряете Retry то с другой
стороны люди начинают плакать и стонать от ваших ретраев до тех пор пока не поставят
вам троттлер или аварийный размыкатель.

Короче думайте о последствиях.