#машины_разное

Обещанный пост про блокировки!

Если совсем просто, то механизм блокировок (lock) реализуется с помощью обычной хеш-таблицы/словаря/чего-бы-то-ни-было. Ключом к этому словарю обычно является сам объект блокировки, а значение - некий идентификатор/токен замочка.

Объектом блокировки в данном контексте может быть что угодно. Довольно древний, по современным меркам, storage engine MySQL под названием MyISAM блокирует целые таблицы, а более новый InnoDB - строки. Продвинутый механизм блокировок в PostgreSQL, который задействует snapshot isolation - блокировка назначается на строку, но в определенный момент времени! Записи, в том числе обновления и удаления данных, в таблицах Postgres, работают в режиме append only, заправляя это все крепеньким vacuum’ом, ну или как там это называется, знатоки пусть меня поправят.

Локальная система блокировок существует в памяти СУБД.
1. Подключился к СУБД
2. Запрашиваешь “замочек” на строку Х в таблице У (acquire lock)
3. Получаешь некий токен “замочка” - механизм тебя “запоминает”
4. Производишь запись, “освобождаешь” замок (release lock)

Другие транзакции, точно так же приходят за замком и смиренно ждут, пока ты его освободишь. При этом блокировки могут быть на чтение и на запись, простые и двуфазные (тут уже идите читать кабанчика от Клепманна). В целом работа с механизмами блокировок в пределах одноузловой система простая и понятная.

Но если вы работаете в смузихлебном стартапе, то скорее всего вы живете в условиях распределенных систем, а значит у вас распределенные хранилища, а возможно и распределенные системы блокировок!

И если вам сейчас показалось, что я несу откровенную чушь - то зря. В SRE книге Гугла в 4-ой главе рассказывается про распределенную систему блокировок Chubby. Другим примером распределенного замочка может быть ситуация, когда вы хотите заблокировать некую сущность в пределах нескольких независимых систем. Распределенный замок может быть реализован и в рамках самой системы, например Redlock в Redis. Мы к этому еще вернемся, но тут важно уточнить, что Redlock это фича для потребителя, а не внутренний механизм для работы с запросами.

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

Решается это еще интереснее, и вот тут я хочу поделиться наинтереснейшей статьей от автора того самого Кабанчика. Там вам и про блокировки, и почему Redlock говно. Не потому что Redlock, а потому что в распределенных системах все говно, если хорошенько докопаться.