А у меня в связи с обсуждением тоже назрел вопрос.

А как в микросервисах и кубере решают задачу распределенных примитивов(локи, лидер елекшн). Сейчас у нас монолит и отдельно поднят зукипер (там же дискавери). Вообще появляется ли такой вопрос в микросервисах? И если про leader election (заставить только один инстанс приложения выполнять отдельную логику) можно решить, просто выделив в отдельный сервис, то что делать с локами не понятно. Отдельный etcd/zookeeper/redis?

я обычно беру что-то типа https://github.com/lukas-krecan/ShedLock и использую (как бэкенд - или какой-то постгресс, или что-то еще, тут много вариантов)

известный мне подход: локи в бд. если нужно выполнять другую/немного друю логику то можно и настройку окружения передать. как бы постгрес по умолчанию а для редких вопросов синхронизации что-то поднимать отдельное вроде неэффективно

Локи в бд может быть очень неэффективно (если модель пуллинга бд), зукипер, етсд дают модель подписки на изменение ключа

Тоже опирается на что-то типа бд, зукипер и тд. Я так понимаю это скорее аналог spring-cloud компонента лока, чем отдельное решения для синхронизации

конкретно в моем приложении локи это именно локи данных. по этому так

Локи данных в бд? Или распределенные локи в приложении?(java.concurrent.Lock)

так-то согласен что эти вещи эффективнее хотя бы потому что бд не совсем тот инструмент для разруливания синхронизации

первое

Тогда понятно, вопрос именно синхронизации блоков в коде, чтобы в этот момент не появилось несогласованных данных например (проблема атомарности проверки наличия данных)

кстати интересно было бы узнать для каких примерно задач предполагаются эти локи? распределеные транзакции?

Ну например при реакции на событие проверить, что нет уже чего-то созданного в другом приложении

чем тут гн подходит rdbms? долго?

Другой инстанс может параллельно обрабатывать этот же событие

пишут в одно место? две транзакции. одна навернется например по unique key. или я не догнал

Да классическая проблема параллельного кода (что решалось бы блоком синхронизации) если бы не были разные приложения. Если чего-то нет, выполни код. А параллельно другой инстанс может заканчивать создания этого самого. Так карты легли и балансировщик раскинул запросы пользователя например.

Ключа уникального не будет, потому что может быть много таких записей вцелом(но одна активная)

то есть в etcd один процесс кладет "я начал ид=123" а второй падает/идет в другую ветку ифа если оно там есть?

Ну да, типо того. Возможно пример я не привел нормальный и это можно решить составным ключём

Можно и в бд строчку записать - взял лок на такой объект, потом в конце отпустить.

ну суть все равно понятна.

Надеюсь речь идёт про транзакции? Или вы про NoSql key-value базы говорите?

Я вцелом про распределенные локи(и другие примитивы - leader election, disovery - тут все понятно) и кто как их использует. Или может в микросервисах они вообще не нужны (у нас монолит)

lock table 😂

Ну как вариант 😂

С ними кстати много приколов. Например, если это какой-нибудь Redis с TTL механизмом, то можно запросто набить себе шишок, надеюсь понимаете о чём я 😅

Ну про консистентность редиса немного слышал, поэтому могу предположить. Ну есть проверенные рабочие решения - етсд, зукипер) они как раз про консистентность в ущерб доступности

Не не, не про это, а про то, что фактически легко напороться на гонку. Когда один поток инстанса A подзавис, но не отпустил блокировку, при этом из-за TTL блокировка снята, а второй поток инстанса B смело пошёл в критическую секцию. Но это если у вас TTL стоит, он может не стоять, но там свои минусы появляются

чет кажется что лучше лок пропадет чем будет висеть до перезагрузки

Ну тут наверное можно не снимать когда отвиснет, словить исключение и откатить транзакцию, а второй повисит пока лок не отпустится. В итоге будет все хорошо

Так лок пропадёт, но если критическая секция будет взята "без согласования", то можно напороться на проблемы

Если успешно не снять, транзакцию можно не комитить. Но это простой случай да, отправленное сообщение не вернёшь (но и тут свои есть решения)

оба варинта конечно проблема. но дэдлок на проде это неприятно

https://medium.com/ayte-io/distributed-locks-semaphores-again-36d35c36b21e tl:dr: you're fucked, гарантии недостижимы by design, есть только торги между теоретическим временем простоя и работоспособностью подвисающей системы или плохой сети; одним внешним сервисом это не решить, внешний сервис хранит стейт, но в приложении все равно должна быть прослойка, дающая ответ, находится ли приложении в критической секции; внешний сервис может быть любым стораджем с CAS операцией; ищите для своих задач алгоритмы, состоящие из идемпотентных действий