Многие из backend-разработчиков получали ошибки с неприятным содержанием, суть которого можно описать двумя словами: deadlock detected. Эти ошибки коварные. Возникают они там, где их не ждёшь, отладочной информации крайне мало или вообще нет, и для их решения необходимо глубокое понимание архитектуры как самого запроса и метода, из которого он вызвался (или методов, возможно, чужих...), так и архитектуры самой СУБД. Поэтому часто у таких ошибок либо переносится срок, либо попытки их исправить приводят к тому, что они возвращаются снова и снова. А deadlock-и так никуда и не исчезают.
Прежде чем говорить о взаимоблокировках отметим, что любое изменение записи — добавление, редактирование и удаление — 1) происходит внутри конкретной транзакции и 2) всегда накладывает на запись блокировку. Для упрощения я не буду здесь рассматривать частичные блокировки — это не сильно влияет на понимание сути проблемы. Просто условимся, что всегда блокируется запись целиком. При этом прочитать запись можно (СУБД-блокировочники в расчёт не берём), и прочитана будет та версия записи, которая доступна текущей транзакции на основании её уровня изоляции и состояния БД в момент её старта. При этом транзакция, которая изменила запись, конечно же увидит свои изменения. Но если другие транзакции попытаются что-либо сделать с этой же записью — отредактировать, удалить или добавить такую же (при наличии уникального индекса), они встанут на наложенную другой транзакцией блокировку и будут ждать, пока изменившая запись транзакция не завершится.
Взаимоблокировка, или deadlock, — это состояние, когда из-за наложившихся друг на друга блокировок дождаться завершения какой-либо из транзакций, удерживающих запись, становится невозможно. К счастью, все СУБД умеют отслеживать взаимоблокировки и принудительно завершать блокирующие транзакции по истечении определённого лимита времени. Это для них как фундамент, основа, без которой СУБД не может существовать. Но наличие подобного механизма не означает, что разработчику ничего не нужно делать с взаимоблокировками — напротив, важно найти причину взаимоблокировки и её устранить. В этой статье я постарался собрать известные сценарии взаимоблокировок, встречающиеся в повседневной практике и рассмотрел их на примере СУБД PostgreSQL. Также отдельно рассмотрен особый вид взаимоблокировок — взаимоблокировки на уровне приложения, с которыми СУБД самостоятельно справиться не может в принципе. Итак, приступим.
Сценарий 1. Классическая взаимоблокировка
Сценарий классической взаимоблокировки следующий:
Стартуют две транзакции — А и Б.
Транзакция А меняет запись 1.
Транзакция Б меняет запись 2.
Транзакция А пытается изменить запись 2 и встаёт на блокировку, ожидая завершения транзакции Б.
Транзакция Б пытается изменять запись 1 и встаёт на блокировку, ожидая завершения транзакции А.
Всё. Транзакции уперлись друг в друга, и единственный способ разрешить эту смертельную блокировку – принудительно завершить одну из них.
Заметьте, что взаимоблокировка возникла из-за того, что транзакции 1 и 2 меняют записи в разном порядке. Если бы порядок был бы одинаковый, взаимоблокировки бы не возникло:
Стартуют две транзакции — А и Б.
Транзакция А меняет запись 1.
Транзакция Б меняет запись 1 и встаёт на блокировку, ожидая завершения транзакции А.
Транзакция А меняет запись 2 (ведь ей уже никто не мешает это сделать).
Транзакция А завершается.
Транзакция Б перечитывает запись 1, изменённую транзакцией А, и в свою очередь тоже меняет её.
Транзакция Б перечитывает запись 2, изменённую транзакцией А, и также меняет её.
Транзакция Б завершается.
Как видно, никаких взаимоблокировок в этом случае не происходит. Отсюда делаем важный вывод: первый и основной способ борьбы с взаимоблокировками — правильный порядок обновления записей.
Сценарий 2. Взаимоблокировка вследствие нескольких запросов
Рассмотрим следующий вид взаимоблокировок, который довольно часто вызывает у разработчиков непонимание. Это происходит, когда внутри транзакции меняется одна запись, но у разных таблиц. Бедный разработчик, получивший такую ошибку, может долго смотреть на запрос, изменяющий одну-единственную запись по ключу, и недоумевать, откуда здесь взаимоблокировка? Я же ОДНУ! запись меняю! Но давайте шире посмотрим на этот пример и приведём сценарий подобной взаимоблокировки:
Стартует метод Foo. В методе запрос редактирует запись А таблицы Документ.
Стартует метод Bar. В методе запрос редактирует запись Б таблицы Работа.
В методе Foo следующий запрос редактирует запись Б таблицы Работа и встаёт на блокировку транзакции, запущенной методом Bar.
В методе Bar следующий запрос редактирует запись А таблицы Документ и встаёт на блокировку транзакции, запущенной методом Foo.
И снова вот она взаимоблокировка. Всё отличие от сценария 1 лишь в том, что запись меняют разные запросы. Но это не имеет никакого значения — запросы ведь выполняются в одной транзакции! А значит здесь подойдёт тот же метод борьбы — использовать один и тот же порядок изменения записей. Только в данном случае это будет порядок выполнения запросов. Вот тут может быть проблема, поскольку методы, изменяющие одни и те же таблицы, могут писать разные разработчики из совершенно разных отделов, и договориться о порядке изменения может быть намного сложнее — придётся найти ответственного за конкурирующий метод разработчика и договориться с ним о порядке изменения записей.
Сценарий 3. Взаимоблокировка при множественных изменениях внутри конкурирующих запросов с CTE
Третий сценарий сложный, и борьба с подобными взаимоблокировками требует понимания как архитектуры самих запросов, так и архитектуры СУБД. Он возникает у тех разработчиков, которые любят большие запросы с множественными изменениями. Перед описанием сценария этого вида взаимоблокировки попытаемся представить себе архитектуру подобных запросов.
Допустим, есть запрос, который одновременно и добавляет новые записи в таблицу, и изменяет существующие. Добавление записей контролируется уникальным индексом. Разработчик написал отдельные CTE — одно для изменения, внутри которого выполняется оператор UPDATE, а другое — для добавления с оператором INSERT. Разработчик грамотный, поэтому всё сделал правильно — учёл порядок записей как в запросе изменения, так и в запросе добавления записей. При этом записи для изменения предварительно заблокировал оператором SELECT с командой FOR (NO KEY) UPDATE. Запрос работает отлично, но... иногда приходят ошибки с взаимоблокировками... между одними и теми же запросами, запущенными разными бизнес-логиками. Что за чертовщина? Всё же учтено!
Всё, да не всё. Тут нужно вспомнить две особенности архитектуры PostgreSQL, касающиеся оптимизации. Первая состоит в том, что оптимизатор PostgreSQL может вообще не выполнять некоторые CTE, если видит, что данные из них нигде не будут использоваться (например, в конце итогового запроса стоит банальный SELECT TRUE). Но CTE, содержащие операторы изменения данных — INSERT, UPDATE и DELETE — выполняются всегда. И вторая — оптимизатор может решить выполнить разные CTE в разных потоках. И какой из них начнёт выполняться раньше, даже сам оптимизатор не знает.
И вот теперь мы готовы представить себе картину происходящего:
Бизнес-логика 1 запускает метод Foo с запросом, изменяющим и добавляющим данные.
Бизнес-логика 2 запускает тот же самый метод Foo с тем же запросом, но с другими данными (частично или полностью пересекающимися с первыми).
Оптимизатор СУБД решает выполнить оба запроса в параллельных потоках.
Стартует CTE добавления данных запроса из бизнес-логики 1 — поток, выполняющий добавление, освободился раньше.
Стартует CTE изменения данных запроса из бизнес-логики 2 — здесь быстрее освободился поток, выполняющий изменение. Пока всё хорошо, данные не пересекаются...
В запросе из бизнес-логики 1 стартует CTE изменения данных и встаёт на блокировку, наложенную транзакцией бизнес-логики 2.
В запросе из бизнес-логики 2 стартует CTE добавления данных и встаёт на блокировку, наложенную транзакцией бизнес-логики 1 (у нас же уникальный индекс!)...
И вот она, взаимоблокировка! Здравствуйте, где не ждали. Но если присмотреться, все признаки возникновения взаимоблокировки налицо - присутствует произвольный порядок выполнения CTE. Только теперь это произошло не по вине разработчика, а вследствие изменения данных в разных параллельных потоках, порядок выполнения которых не регламентирован.
Метод борьбы остался тем же самым — явно указать порядок выполнения CTE. Но как обмануть оптимизатор в этом случае? С помощью принудительной сериализации выполнения CTE. Для этого достаточно в одной CTE использовать результат выполнения другой, к примеру, в CTE с оператором INSERT добавить холостое условие, использующее CTE с оператором UPDATE, скажем, WHERE (SELECT COUNT(1) FROM update_cte) >= 0. Тогда оптимизатор поймёт, что CTE на добавление он сможет выполнить только после CTE на изменение, и не будет распараллеливать их выполнение.
Сценарий 4. Взаимоблокировка на уровне приложения
Но мы же умные, и можем создать взаимоблокировку, с которой СУБД вообще не в силах справиться! Для этого платформа backend-разработки должна предоставлять возможность выполнять разные методы в отдельных транзакциях. Это необходимое условие для создания взаимоблокировки на уровне приложения. С одной стороны, это хорошо, поскольку изолирует изменения, выполняемые методом. Но хорошо только до определённого момента.
Представьте себе следующий сценарий:
Стартует метод Foo. Стартует транзакция А.
Внутри метода Foo выполняется запрос, изменяющий одну запись Rec.
Далее метод Foo вызывает метод Bar (который выполняется в отдельной транзакции).
Метод Bar стартует новую транзакцию Б и выполняет запрос, изменяющий ту же самую запись Rec.
Что произошло? Поскольку запись Rec уже изменена в транзакции А, и транзакция А не завершена, запрос в методе Bar, выполняемый в транзакции Б, встаёт на блокировку транзакции А. А транзакция А не может завершиться, поскольку завершить её должен метод Foo, который в свою очередь, ожидает завершение метода Bar. Мы получили классический deadlock, за тем лишь исключением, что СУБД не знает, что транзакции А и Б принадлежат одному и тому же методу, и, следовательно, не может принудительно завершить одну из них.
Отследить и устранить такое может только служба эксплуатации, когда диагностирует наглухо зависший метод. Но уже очевидно, что такую ситуацию нельзя допускать. Какие для этого есть способы?
Не использовать выполнение метода в отдельных транзакциях без необходимости (заворачивать вложенные методы в общую транзакцию).
По возможности не допускать изменение одной и той же записи в разных методах.
Использовать таймауты на методах, чтобы метод мог быть принудительно завершён хотя бы по таймауту.
Скорее всего, это не все сценарии возникновения взаимоблокировок. Надеюсь, мне удалось донести мысль, что бороться с взаимоблокировками надо с помощью глубокого изучения происходящих процессов как в бизнес-логике, так и в СУБД. Поистине, труд разработчика никогда не будет скучным! Буду рад, если статья окажется полезной, и в результате количество взаимоблокировок в ваших приложениях сократится.
