Лолшто?

бо немає накладних витрат на обслуговування основних функцій.

ти несеш якусь беззмістовну псевдо-технічну ахінєю.

Як на мене тоді у нас значно більша проблема ніж select for update

Ну чому? Це цілком валідний кейс. Дані лежать на сфтп, в редісі, в кафці, в якійсь граф-дб, і т.д. і т.п. Купа прикладів сховищ, які не є рдб і які не зможуть фізично гратись в селект фор апдейт.

Маючи абстраговане рішення розподілених локів (зараз не важливо яке) ти маєш рішення яке буде працювати для всіх процедур, всіх робіт, всіх типів даних і сховищ.

А я навпаки бачу в цьому великий плюс, коли дані 100% не закораптяться через те що лок та дані в різних місцях. База працюватиме залізобетонно.

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

і далі сам відповідаєш

Створення і підтримка окремої таблиці для локів імхо дуже сумнівне рішення. Почнім з того, що щоб на чомусь залочитись, туди це щось треба покласти, це вже рейс кондішн. Можна повісити unique, чи мати таблиця з одного стовпця, який же і ПК. Але питання інсерту (що інсертити і коли) лишається.

робити сінглтон сервіс це дуже сумнівне вирішення проблеми

Отут я погоджуюсь

Бо про час чи синхронізацію мови не було

Я почав свій пост з:

І в усіх у них є одна принципова проблема —

якщо виконання тієї самої унікальної роботи, яка не має виконуватись паралельно, зав"язане на час — рассінхрон фізичних серверів по часу.

Наприклад, це шедулер. Зустрічається частіше ніж завжди.

Мова про одночастність подій для спостерігача незалежно від годинників на серверах

Ну тобто, з другої спроби не прочитали мій пост, буває

Прив"язка локу до рдбм-транзакції, в якій виконався той SELECT... FOR UPDATE,
що в цьому поганого:

1. Не завжди дані для блокування взагалі лежать в БД. Для даних, які не лежать в БД, для цього блокування тобі потрібно буде створювати окрему таблицю, куди напихувати сторонні ідентифікатори

2. Ліз локу прив"язаний до коміта виключно цієї самої транзакції. Що робити, якщо лок треба відпустити ДО кінця транзакції, чи через деякий час ПІСЛЯ, наприклад, після комміту тобі треба зробити хттп кол, дочекатись його респонса, записать якісь результати і тільки потім відпустить лок? Або коли один лок має охоплювати кілька транзацій?

3. Заблокувавши, наприклад, юзера, щоб оновити якийсь сегмент його даних, ти заблокуєш ВСЬОГО юзера, для ВСІХ інших сценаріїв, які могли б виконуватись паралельно. Наприклад, отримавши лок на юзері для маніпуляцій з його корзиною, ти цим самим заблокуєш якусь іншу роботу, наприклад якусь фонову синхронізацію, яка могла б виконуватись в паралель.

4. Інколи велика кількість блокувань при інтенсивному використанній бд, а не там де 3,5 анонімуса раз на рік, може призводить до заторможення бд. Це дискусійне питання, так, але гіпотетично такий сценарій можливий.

5. Відсутність просунутих АПІшок для бд-блокувань. В 99% випадків це тупо SELECT... FOR UPDATE чи аналогічна низькорівнева інструкція яка не має ні апі-механізмів ні будь-яких інших механізмів керування окрім комміт/роллбек. Ні ліз тайму, ні фенсінг-токена, ні трай-лок, ні явного анлока. Тепер порівняй це з Hazelcast FencedLock API чи навіть з Redisson RLock.

6. Блокування — це логіка рантайму, фактично, бізнес-логіка твоїх дій. SELECT FOR UPDATE це частина стореджа даних. Це концептуально різні шари програми.

Можна лочити клієнта в рдбмс

Швидке, просте, надзвичайно погане рішення рівня круд-хеловорлда з мільйоном мінусів.

У хлопців відбувається leader election на основі Distributed Lock

Так ТС про лідер елекшн ніде не написав, тільки базовий юзкейс розподіленого локу.

Якщо перечитати мій коментар ще раз, то можна зрозуміти про що я пишу :)

Реалізацій того самого функціоналу є багато.
І в усіх у них є одна принципова проблема — якщо виконання тієї самої унікальної роботи, яка не має виконуватись паралельно, зав«язане на час — рассінхрон фізичних серверів по часу.

Про це майже ніхто не думає, але це існує. Якщо ноди вашого застосунку задеплоєні на фізично різних машинах, між цими машинами може існувати різність у часі*, в такому випадку, «один і той же» час, наприклад, 00:00 наступить фізично в різний час, скажім, для сервера А це буде справжній 00:00, а для сервера Б це буде 00:00.099. Цього достатньо, щоб шаред лок спрацював не так, як потрібно, чи не так, як ви очікуєте. Якщо робота, яка має виконатись, довга, є дуже велика спокуса «синхронізувати» тільки її початок, і отут ви попадаєтесь.

Тому я взагалі не раджу використовувати такі механізми, які вони зав"язані на час. Те що вам потрібно — це вибори лідера в кластері (leader election), який буде виконувати роботу, або буде відповідальним за призначення 1 ноди з Х для виконання роботи.

* одного разу я бачив сервери, різниця між якими в часі досягла 8 хвилин.

+1

Правильно, рівно ніяк.
Так само як всі подібні подорожники не рятують від концептуального існуваннч нулла — чогось може не бути і все.

слів защітан, ти обісравсь.

Ти або просто дурачок, або дурачок-запроданець або дурачок-який-думає-шо-він-адін-умний.

Всі ми знаєм що наші воїни гинуть, так. Але наявність таких скетчів — як мінімум позитив в тому що в США є люди які бачать шо трамп підар і клоун.

Є виключення.
Age of Empires. Зараз під крилом МС в стімі гра переживає відподження.

Боббі Котік вбив бліззів, підріла.

На будь-яких ігрових івентах де він віжкриває своє хлєбало йому треба ссять в обличчя замість розмов

Боббі Котік очолював Activision Blizzard протягом більш як тридцяти років.

Ви хоч трохи перевіряйте шо пише. Activision купив Blizzard у 2007 році.

То і нахєр циву.

Грайте в Age of Empires 2. Там є нація Slavs, що представляють Київську Русь із тризубом Ярослава, золотим на блакитному звісно.

Якщо це сквозний пк, це ще гірше, ти зможеш проітерувать
GET shop/users/%USERID%/orders/%ORDERID% і скласти мапу у якого юзера є який ордер, фактично частково витягнувши інфу.

1. Є вірогідність що ід 12 це 12й ордер клієнта.
2. Велика вірогідність шо зробивши
GET shop/users/123/orders/123666565446
Ти отримаєш 404 NOT FOUND а не 403 FORBIDDEN чи 401 UNAUTHORIZED, таким чином перебором інтів 0-12 ти зможеш визначити всі ідентифікатори ордерів клієнта.

і тд і тп

ти не кулхацкєр (мабуть) шоб із цим шось робити, бо ти не вмієш і не знаєш що з цим робити.

Для людини компетентної у питаннях проникнення і зламу це додатковий який +1 до витягування інформації.

Ти ще не забувай, що доу — публічна штука і все що ти можеш зробити з ідентифікаторами і так публічне. Магазин, банк і тд — це вже сильно зовсім інша тема, бо наприклад,

shop/users/123/orders/12
говорить про те що конкретний юзер вже зробив як мінімум 12 ордерів, що по суті вже є витоком персональних даних.

На доу — нічого. А от якщо у вас є /users/123 то нормальна безпека видасть вам піздюлєй, бо це значить шо є ваше апі можно дрочить перебором інтів.