Сергей, огромное спасибо за ролики с Владимиром. Как-то пропустил появление роликов с ним, но зашел на канал и увидел целый плейлист, сразу настроение стало лучше.
Здравствуйте всем у меня вопрос. Я попалнял тройку на 3 месяца прикладывал тройку экране спрашивает попалнят я прикладываю сбер карту снимают деньги а потом отказ транзакции и я поехал дальше ждала 2 дня деньги не возвращаются. .И начинается футбольный мячик отправляют банк из банка транспортной компании итоге жду до сих пор кто знает куда мне подъехать и позвонить.😶😶🌫️
С инстансами не очень понял. Можно ведь каждую транзакцию хранить в таблице для транзакций и просто менять ее статус на "реализована", когда юзер ее подтверждает. А для подтверждения сделать условие, чтоб на счету всегда была переводимая сумма плюс комиссия. Неужели для современного железа проблематично обслуживать такой механизм? Или я где-то туплю?
Как то очень давно хотел устроится в один банк программистом. Пришел на собеседование. Задали ряд вопросов. Ну вроде норм. Потом на последок спросили "Сколько транзакций в день ты выполняешь?". Я ушел и больше никогда не ходил на собеседования в банки.
Владимир, в каком-то из видео вы ответили мне в комментарии и посоветовали книгу Клеппмана "Высоконагруженные системы", сейчас ее читаю, книга просто супер! Какие книги вы еще посоветуете читать? Спасибо
Первый )) Уже смотрю и лайк сходу. Начало по интонации звучит как признание в кругу анонимных алкоголиков - меня зовут ... и я разработчик программного обеспечения )
Если много инстансов одного приложения, то активный скажем пишет в поле БД что конкретный счет блокирован. Другой инстанс приложения читая из БД видит, что счет блокирован и не обрабатывает операцию,только разрешенные поля при блокировки.Владимир, верно понял суть?
Да, это один из вариантов. В реальности чуть сложнее. Обычно учет ведется по паттерну, известному нынче как Event Sourcing, а в 13 веке - как Double-entry bookkeeping :) Идея в том, что у нас есть счет, как сущность. На нем может быть остаток на начало цикла (дня). И лог (Leger) в котором записываются все транзакции: дебет-кредит. И реальный остаток на счету - он вычисляется, как сумма транзакций, в которых он принимает участие. Беда в том, что когда при проведении нашей операции мы сначала вычисляем остаток и на основе этого принимаем решение - можно ли проводить операцию - кто-то, кто быстрее нас, может провести свою операцию (например, снять все деньги). В результате мы можем уйти в минус. Это очень паскудный "феномен", называется write skew, который пробивает почти все уровни изоляции (об этом - позднее). Как вариант - перед началом операции мы проверяем счет, с которого снимаем, на предмет блокировки. Если все ок - то блочим его для всех других пользователей. По окончании операции - не забываем снимать блок.
Было интересно, но меня пугала мысль что я ничего не понимал. и только в конце видео меня отпустило, когда оказалось что понимать придется в следующих видео сегодня моя самооценка в минус не уйдет
А это именно то, что мы делаем: мы продаем то, что у нас есть, типа память, дисковое пространство, процессорное время за то, что нам надо, и пытаемся намухлевать на курсе ;)
1:51 У меня просьба к Владимиру не бейте по столу , не приятно слушать вашу речь при шумах скрипящего стула на котором вы сидите и ДАЖЕ прикосновение рук к столу довольно хорошо слышно и это *БОЛЬШЕ* *ВСЕГО* *БЕСИТ!* 12:41 кто то сверлить начал. По поводу баз данных и взаимодействия мастер сервера между бд и клиентом довольно интересная тематика.
Типичный ютуб. Гуглю уровни изоляции, получаю ЭТО. Какие то мычания, вас невозможно слушать. Пример никакой. Что значит синий прямоугольник слева(90)? То что остаётся в банке на счету магазина? Но тогда почему там 90, если товар стоит 100? ОК, допустим это значит остаток на счёте. Тогда что значчит прямоугольник слева? Опять остаток на счёте? допустим. Тогда почему, после реджекта, нет красного прямоугольника справа? На счету же осталось 50, они не списались. логика напрочь отсутствует
5:43 - можем параллельно обработать запрос, 7:04 - не можем параллельно обработать запрос. Так можем или не можем? 9:27 Владимир Кузнецов начал просто читать с экрана ноута.
В первом случае можем, потому что операции над разными счетами не связаны. Во втором - не можем, потому что в этом случае счет один. Можем нарушить констрейнт и снять больше ,чем есть на счету. И читать Владимир начал раньше раньше, гораздо раньше чем 9:27 :)
Наверно стоит уточнить, что в больших масштабах ситуацию одновременного списания со счета обычно разрешают и загоняют баланс в минус. Иногда такие коллизии легче изредка решать извинениями и компенсациями, чем получить постоянно лежащий сервис где запросы обрабатываются неприемлемо долго. Банки уже не стесняются присылать СМС о списании денег со счета, когда платеж не прошел. А потом через пол-часа шлют СМС о возврате средств.
Тема очень интересная, но о простом как-то затянуто и сложно получилось... Еще, уровни изоляции транзакций в ms sql server и postgresql схожи по названию, но у postgresql, например, на serializable криво работает. А также, если Вам надо сделать, например, отчёт Анализ счёта, а у Вас в регистрах бухучета n-десятков миллионов записей, то решение разработать отчёт в приложении будет провально, т.е., проверку того же сальдо по счету клиента надо перекладывать на скуль, как и все громоздкие операции, просто потому, что у скуля это займет секунды или их доли, а Ваша логика приложения будет делать перебор, который займет часы....
Ну полностью serializable сделать сложно, тот же Oracle его не дает (типа, хотите хендлить skew - юзайте блокировки сами, благо Oracle дает такую возможность). Собсно, 2PL c как-бы предикативными локами дает только SQL Server и DB2... Постргесс до 9.1 хендлил serializable как и все базы с MVCC... Только может, чуть меньше этого стеснялся :) И, кстати, именно он сейчас дает SSI - аналог 2PL c предикативными локами только на оптимистичных локах. Его только в 2008 представили... Свежачок :)
@@vladymyrkuznietsov8815 Как бы да, только в постгресе старые версии строк будут удаляться по факту признания их ненужными и mvcc в чистом виде мы не получим. Это ясно. И именно по этому serializable работает "криво" в понимании/сравнении с ms sql. Типа мы и умные и красивые. А по факту, мы ни того не другого не достигаем и получаем всякие артефакты... Изначально ремарка была о том, что немного затянуто и сложно, а позже ниточка к способу реализации проверок через логику базы данных со сравнением скорости выполнения данной операции через приложение. Ограничения, которые Вы описали - понятны.
@@vladislavkuzmenko4005 "А по факту, мы ни того не другого не достигаем и получаем всякие артефакты..." Ну почему же не получаем-то? Уровень изоляции Snapshot, который принес MVCC не матчится полностью на serializable из-за write skew. Это можно поправить либо явными локами как предлагает Orecle, либо как это делает тот же MySQL, неявными шаред локами... SSI в постгрессе вполне serializable. Там, правда, иногда ложные срабатывания бывают, но вроде как не так часто, чтобы это стало проблемой...
@@vladymyrkuznietsov8815 взяли ms sql. Используем блокировки или контроль версий для конкретной транзакции. Оговорили, настроили бл, погнали работать. Контроль версий не предполагает блокировок как таковых, за исключением операций восстановления. Берём постгрес. Вам необходимо обновить две трети таблицы на миллион записей. Вы открываете транзакцию в ser. В этот момент я обновляю те записи, до которых Вы не дошли. Транзакция у Вас откатывается. А где тут Лок на диапазон ключей?
@@vladislavkuzmenko4005 Хе-хе, так в этом то и идея оптимистической блокировки - мы откатываем транзакцию. И есть огромное количество девов, которые не обрабатывают этот вполне валидный кейс :) Я с Вами согласен, мне тоже как-то понятнее подход sql server, но там дедлок поймать легче легкого :)
Если чесно, то это видео не о чем. Куча поднятых вопросов и ни одного ответа. Все эти проблемы можно решить написав одно маленькое приложение (буквально несколько строк кода) со своим API, которое будет выстраивать в очередь все запросы на изменеия в базе, а напрямую сделать доступ только для чтения, хотя его тоже можно и не делать, а давать доступ через то же приложение (ведь всеравно доступ читать нужно разграничить). И никаких транзакций не нужно. Задачи в которых нужны транзакции совершенно другого характера, я даже не встречал где нужны только они и никак по-другому их не решить.
Ахаха. Так смешно видеть пролайканые все комментарии кроме тех кто пишет про стучание по столу и скрипящий стул. Автор, не бойся критики, лучше скажи спасибо, что люди дают фидбек. И просто исправьте эти моменты
@@vladymyrkuznietsov8815 не прерываясь больше инфы дать, от того что я эту часть посмотрел я считай ничего не узнал, а теперь жди, а когда след. выйдет уже предыдущий надо будет пересматривать что бы вспомнить смысл
@@Erwin_Anderson Хм... А многие жалуются, что большой кусок труднее смотреть, и если честно, его трудно писать... Возможно, по окончанию курса надо будет собрать все в один длинный ролик.
@@vladymyrkuznietsov8815 Лучше всего плэйлистом, когда видео делят тему на подразделы и проще по ним навигироваться и в поиске они больше запросов по теме охватят. А чтобы видео было короче лучше поменьше левой болтовни и более лаконично, я в начале половину видео пролистал. Это вообще большая проблема всевозможных туторов на русском всегда больше такой болтовни, тупых шуточек, хуже структура повествования, особенно всякие вебинары на 3 часа где инфы на 10 минутный видосик на инглише. У буржуев все четко по делу с инфографикой и примерами.
@@Erwin_Anderson Не всем такое заходит. Вот пример ролика без петросянства и одним логическим куском: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-TQAzmpdwJGA.html Я на него потратил времени как на все остальные, вместе взятые. 2 раза переписывал. Как мы можем понять он вообще "не зашел". Хотя он очень актуален. Я могу винить автора и формат. Автора мне менять сложно, проще формат :)
