Вооот. Наконец-то появилось на ютубе видео, которое объясняет реальные подходы к написанию кода. Надеюсь и дальше будут похожие видео, спасибо! Про транзакшнл идея хорошая, туда же можно и про аннотацию лок добавить, жду с нетерпением!😊
На 3:30 какая то каша. Во-первых пула транзакций не существует, есть connection pool, во-вторых, что значит что долгие транзакции блокируют другие быстрые транзакции, а конкретно в вашем примере на чтение??? Что под этим подразумевается? Вы хотите сказать, что если у меня транзакция, пусть даже уже 30 минут держит блокировку на какой-либо записи - я не смогу выполнить select ? С чего бы это вдруг? Особенно если берем за неупомянутые условие, что уровнь изоляции у нас стоит «read commited» т.е. по умолчанию.
Для отображения хоткеев при использовании есть какой-то готовый плагин в IDEA. Он будет выводить на экран комбинации клавиш и не придется каждый раз объяснять что было нажато
Создавать мапу для реализации стратегии можно следующим образом: 1. У каждого task processor прописываешь метод, который возвращает тип (taskType) 1. Создаешь конфигурационный файл, в него инжектишь список таск процессоров 2. Создаешь Бин мапы, где каждый элемент списка мапишь по taskType Теперь можно добавлять сколько угодно обработчиков делать, просто добавляя новый taskType и его реализацию
Катя, сделай пожалуйста видео про объяснение АНОТАЦИЙ СПРИНГА, КЛАССЫ КОТОРЫЕ ИСПОЛЬЗУЮТСЯ В СПРИНГЕ И ВЗАИМОДЕЙСТВИЕ ЧЕРЕЗ СЕТЬ. плииииз. залайкайте комент чтобы Катюньдель увидела и сделала видео
Возможно, буду капитаном, но интерфейсы все-таки лучше создавать для: 1) Возможности замокать его для тестирования, передав под интерфейсом фальшивую реализацию сервиса, имитирующую работу, необходимую для проведения теста 2) Тут уже спорно конечно, но все же, для соблюдения Interface segregation из SOLID. Например, если нужно реализовать сервис, который занимается всеми задачами в рамках одного домена, а в какую-то часть приложения нужно проинжектить только нужный для этой части функционал этого сервиса - применяем Interface только для этого функционала
1 из 10 соответствующий должности - это очень хороший показатель. И это релевантно для любой сферы. Было время подбирал сотрудников в строительную компанию. Я бы мог только мечтать, если бы 1 из 10 кандидатов подходил.
Было бы здорово, если Ты сделала бы вторую часть разбора этого патерна. О том как можно улучшить этот паттерн и какие можно сделать оптимизации для улучшения производительности. Хотим узнать о Event Driven )
Увожение! Одноразовые интерфейсы мб нужны для dependency inversion или при работе над частью фичи которая не включает реализацию интерфейса, а только те места, которые надо сделать в рамках задачи
1) Сервисы помеченные как бины спринга не нужно создавать через new. Если хотите сделать стратегию через спринг, посмотрите доклад Евгения Борисова про паттерны на спринге... 2) Помоему у вас select for update и сам update в разных транзакциях, думаете локи будут работать?:) А так в целом нормально. 🎉
2) А как ты себе представляешь использование SELECT FOR UPDATE для лока в рамках одной транзакции? Какой в этом смысл? Стейтменты в рамках одной транзакции и так же последовательно выполняются. SELECT FOR UPDATE и создан для того, чтобы другие транзакции UPDATE не выполняли. Вообще представляешь себе возникновение состояния гонки в рамках одной транзакции? Я думаю, что нет Единственное, что могут быть повторные отправки в случае такого подхода, но это вроде базовая практика идемпотентные эндпоинты писать, так что проблем быть не должно
если таблица retryable_task одна в микросервисной архитектуре, и ты предлагаешь одну таблицу иметь для всех ретраев, то как эта таблица будет шариться между сервисами?
Из пула точно берутся транзакции, не коннекшн?) 34:47 например, executorService + countdownLatch) 37:21 Да что за "запихиваем"? Инжектим, внедряем, применяем мб? Спасибо за видео❤
годный контент, надеюсь такие видосы будут каждый день выходить. темный фон конечно депрессивно смотрится, но эт уже вкусовщина, мне бы и снятый на кухне такой видос зашел бы
классное объяснение по такой полезной и в то же время мало-известной (как мне показалось) теме 💯💯 был личный опыт - на собесе спросили как можно убедиться в целостности данных при распределённых транзакциях (ни про 2х фазный коммит, ни сагу, ни аутбокс я не знал), пришлось самому что то выдумывать 😅😅
Все отлично по содержанию, спасибо! Классно будет, если на канале будет такой контент. Его не хватает. P.S. По мне слишком часто отдаляется/приближается камера. Прям тяжело смотреть
15:31 - верное замечание по-поводу интерфейсов - однозначно лойс. У нас на проекте сейчас (!) интерфейсы используются как правило в библиотеках, поскольку слепое следование SOLID ведет к раздутости кода. Тем ребятам, кто впоследствии будет смотреть код, где слепо следуют этому принципу будет очень неприятно разбираться во всех этих кишках и простынях кода
интерфейсы это про ООП, а не про SOLID. солиду нужно следовать всегда в промышленном коде. как раз в простынях кода разбираться и не придется, потому что каждая ответственность будет сосредоточена в отдельном классе/пакете/модуле
Не согласен. Считается что использование интерфейсов нужно для создания JDK Dynamic Proxy, так как CGLIB Proxy это более тяжелый механизм, так как требует создания подкласса.
На Хабре есть статья, где чувак пытается заставить спринг создать JDK прокси. И у него так и не получилось. Спринг упорно создавал CJLIB прокси даже для классов имеющих интерфейс
32:59 Решение конечно красивое, но зачем было помечать их service если используете new ? И потом, почему service а не component? Service для бизнес логики то что в нашем домене, а тут какие то retryableTask о которых бизнес не знает даже
Что делать при подходе один сервис - одна база? Для отдельного сервиса Sceduler есть отдельная база, в которую нужно положить сообщение - это опять отправка данных в другой сервис во время транзакции... Или Scheduler отдельный сервис внутри микросервиса?
канал интересный, подписался, правда вопрос это по сути самописанный RabbitMQ в своей базе данных, async messaging pub-sub with retry, я правильно понял?
Провожу собеседования много лет, никогда не спрашивал(и у меня никто не спрашивал) такого ^__^ и у меня есть ряд вопросов по коду * зачем отдельная транзакция на создание таски, ведь она уже создана в сервисе выше? я понимаю что она пропагейтится, но фигачить на каждый метод не круто * в мапстракт маппере создается еще один джексон маппер, зачем когда он уже есть в контексте спринга который и настраивается еще из пропертей? а тут 2 маппера с разными настройками * последнее и самое главное, начинали с "держать транзакцию пока выполнится запрос плохо", но пришли к "теперь мы держим транзакцию n*requestTime" что еще дольше и еще хуже чем первая :) на счет микросервисности, этот паттерн применим везде, но текущая реализация не подходит для микросервисов(джоба только в 1 поток может работать) код на бусти не видел, может там skip locked и тред пулы есть)
Да тут вообще дизайн полный ужас. Это в какой компании интересно такой подход используют? И полагаться на время в разных выборках тоже так себе практика время скорее всего не будет суперточно совпадать на разных инстансах особенно если они на разных физических машинах. Ну и да сваливать все в одну таблицу что бы потом из type городить огромный бородатый switch который будет решать в какую очередь отправить.. вообще вишенка.
начинали с "держать транзакцию пока выполнится запрос плохо", но пришли к "теперь мы держим транзакцию n*requestTime" что еще дольше и еще хуже чем первая - почему дольше-то? Сохранить в БД дольше чем отправить запрос и дождаться ответа?
Ну ещё бы надо добавить, что это at least once доставка, так как отправитель может упасть после сделанной отправки , не успев проставить соответствующий статус.
Здравствуйте, но возник такой вопрос: зачем такие данные хранить в sql бд, почему нельзя засунуть это в редис. Не знаю как в java, но знакомы ли вы с Celery?
@@dragvs Редис и есть БД, и я не понял вопроса, но попытаюсь, ответить, по тому как я понял: Зачем в данном кейсе нам вообще sql бд? Если сохранение тасков можно хранить в ligthweight бд, с форматом ключ-значение
@@inftech8976 вы понимаете что такое ACID и почему оно важно в данном кейсе? Вы предлагаете просто SQL DB заменить на NoSQL - в чем профит? В банках часто применяется SQL для хранения данных, как вы будете обосновывать решение? А почему не блокчейн? Он тут тоже подходит - в обе «таблицы» писать одной транзакцией. Выбор не так тривиален и сильно зависит от контекста.
@@dragvs По вашему если я поменяю sql на nosql, то нарушится консистетность? Как она может нарушится, если нет никаких данных, которые бы могли взаимодействовать друг с другом? Хранение тасков и хранение к примеру клиентских данных, это совсем разные вещи, и никак не относятся друг к другу. При чем тут банк и хранение данных там? Я не говорил, что надо использовать основную БД как редис, ни один разумный человек не поставит основную бд с NoSQL, либо вы не понимаете суть этого ролика В случае видео, с хранением тасков, которые могли бы потеряться, автор использует SQL бд, а в таких случаях, бд с sql плохо подходит, потому что она будет работать медленно и нагружать к тому же сам сервис бд, если конечно не сделать отдельный сервис для тасков к примеру тем же postgres. А редис, конечно тоже нужно поднимать сервис, но нагрузки будет меньше, да и быстрее будут выводы, просто потому что таски - не такие сущности как те же клиентские данные. key-value
@@inftech8976 как вы будете ACID обеспечивать? Вам нужно атомарно и конситентно сохранить запись с данными и запись для отправки во внешнюю систему. Консистентность у вас нарушится если одна БД запишет а другая нет, у вас же payload это производная от записи в SQL базу. В этом весь «сок» паттерна. То что вы пытаетесь предложить можно с таким же успехом сразу запрос слать во внешнюю систему, какая разница Redis у вас внешка или notification service - вы получите те же проблемы решения.
Какую именно информацию? При оформлении заказа уже есть адрес доставки и отправки. Расстояние между двумя точками, время примерной доставки и стоимость вполне можно рассчитать в синхроне. Данные о курьере, если такой предусмотрен, ты не получишь, пока система его не подберёт. Это может быть и секунда, и минута, и десять минут. Поэтому на фронт обычно отдаётся статус заказа 'PENDING', отрисовывая экран с оформленным заказом и надпись "подбираем курьера", при подборе курьера отправляется пуш на клиента, который отрисовывает уже другой экран с информацией о курьере. Именно так работает Bolt такси, например.
@@channel-yg2xc а что, у тебя фронт будет получать полную информацию о курьере через сервис заказов? Или все таки достаточно зарегистрировать синхронно доставку, получить id?
@@channel-yg2xc а у тебя что, сервис заказов возвращает полную информацию о доставке на фронт? Может все таки зарегистрировать доставку, получить id? Я конечно рад за bold такси, что у них распределённый монолит работает, но все таки я бы предпочел микросервисы
А в чем смысл на 2:20 говорить, что пихать операцию создания записи в бд и рест запрос в транзакцию это кринж, а потом на этапе передачи сообщения в брокер, обмазывать это транзакцией(19:30)?
Досмотрел до UUID ключа. Аргументация еще круче "потому что я люблю". Ни слова про перфоманс, ни слова про то почему может потребоваться UUID и какие версии есть.
Подскажите, очень надо. Java не учил ещё, знаю только python. Часто нужно получить apk. Декомпилировать. И собственно реверс и поиск как значений, так и методы формирования значений для запросов приложения, которые отснифаны ранее. Либо снятие защиты от снифа или от запуска на эмуляторе андроида , снова упаковка в apk и запуск. Реверс инженеринг. Как? Где? Чем? Каким образом? В общем, сервисы, ресурсы, где можно учить, изучать, использовать, для решения подобных задач. Java выучу, клянусь и ещё 4-5 языков, чуть позже, сейчас другое важное учу и решаю. Подскажи, очень нужно дельный совет. Заранее спасибо. Целую в щёчки, жму сосочки.
Отличный видос! Действительно обязательная тема для миддл+/синьор бэкендеров. Nit: Кажется в видео было упущено сохранение обновленных значений retryTime для тех retryableTasks которые мы все же не смогли обработать. Не сильно шарю в джаве, но кажется если обновленные значения закинуть в цикле через сеттер, то в бд они не отразятся. Наверное надо было просто добавить метод в репо, который бы обновил те записи, у которых статус не изменился на success.
На джвае нет что ли готовых шедуле библиотек ? - свой велосипед для типовой задачи как-то кринжово. На счет интерфейса для заказов . я бы небыл так уверен , сегодня в БД пишете заказы . а завтра решили сливать их в какую либо CRM-ку , да и в целом бизнес логика оформления заказа часто меняется , лучше пусть будет интерфейс он каши не просит реализуется за пять сек, и это точно не сложнее чем все потом править.
@@ggnet-lm7pgНет, rest это не соглашение формата данных. Строго говоря, данные могут быть в любом формате: json, xml, html, byte file, plain text и т.д. Rest в первую очередь соглашение о формате урла и отображении состояния запрашиваемой/передаваемой инофрмации путем внедения уникального идентификатора. Согласно модели OSI, rest не протокол, а SOAP вполне, т.к. имеет строгие ограничения формата передаваемых данных, при чем оба они работают с протоколом http.
@@channel-yg2xc Я и не говорил, что REST - это протокол. Я сказал что это data transfer architectural pattern/view, который накладывает определённые ограничения на передачу данных. В названии SOAP - явно указывается, что это протокол, в отличии от REST. REST - не является имплементацией, и не зависит от application/transport протокола.
@@ggnet-lm7pg - REST это не протокол, а соглашение - протокол это и есть соглашение - я не говорил что Rest - это протокол ))) Но это такое, ты сказал, цитирую: "...Но REST сам по себе лишь один из видов представления передачи данных", я ответил, что это не так. Все ограничения формата данных, передаваемых по REST - это ограничения протокола http. В самом же REST нет ограничений http request body ни логически-концептуальных, ни физических, - его физически ограничивает протокол http и ни что более. Соответственно "вид/view"(проще говоря, данные запроса и ответа) может быть любым, который удовлетворяет протоколу http.
Я все равно не уловил фишку. Почему не послать просто в очередь? Зачем это все? И это как по мне не решает проблему, а переносить в другое место. Планировщик так же будет блокировать таблицу на добавление новых записей. Собственно, поэтому никто не знает ответ на собесах - слишком это кривое, неэлегантное решение.
Какие новые записи создаёт планировщик и что блокирует? В виде не сказано про idempotent Id в каждом запросе от планировщика к другому сервису. Этот id помогает слать один запрос много раз. А после успешной отправки запроса или ответа 409/406 (и т.д.) открыть транзакцию и обновить bool поле "отправлено"
Я не понял, а чем собственно rest запрос на другой микросервис, который может быть "долгим" отличается от той же самой записи в базу данных, которая тоже может быть долгой. Это два внешних сервиса, никто не гарантирует что в какой-то из них запрос будет идти дольше/быстрее
И даже если мы запишем запрос с json в базу чтобы потом когда то там куда то там его отправить - мы все ещё не гарантируем что он дойдет до нужного сервиса. Даже не гарантируем когда он дойдет до сервиса. Просто поменяли шило на мыло.
Вопрос правильный, ответ такой: базу выбираете вы сами и рассчитываете под свои потребности и можете подкрутить, если что. Другой же микросервис вы не контролируете, ну по крайней мере будем так считать. Ну и вот.
Тем что в первом случае у тебя вся транзакция отвалится по таймауту. Второй вариант позволяет тебе сохранить транзакционность доставки не имея проблем с таймаутом и тем что транзакция занята ожиданием ответа от другого сервиса. Конечно transactional outbox не под все задачи подходит. Но на видео разобрали очень популярный юзкейс. Если тебе нужная транзакционность между сервисами, посмотри в сторону 2PC и связанные паттерны. Вижу что в комментах люди пытаются натянуть сову на глобус.
@@paxpax1707 извините конечно но каким боком сохранение в базу и бесконечные ретраи обеспечивают транзакционность? Запрос спокойно себе может никогда не осуществится. Это полный бред
Как минимум во вступлении отсутствует информация что мы что-то сохраняем в базу данных, это смешно просто слушать, что сообщение может потеряться в Кафке, а из тмб оно не может потом потеряться в Кафке, дилетантство, прочитали пару статей в интернете и давай клепать ролики для хомяков
Проблема в необходимости писать в больше чем один сервис, с этого надо начинать, у вас каша полная, вы не понимаете ничего в этом и не умеете выражать свои мысли последовательно
@@vladislavlebedev6059 сейчас половина айти такое к сожалению. Сейчас отовсюду слышны крики что главное это софтскилы для построения карьеры в айти, вот результат. Читаем пару статей и идём с докладом на конференцию выдавая себя за эксперта. Это айти которое мы заслужили ! 😉
Устал слушать воду на 4й минуте. Пошел в гугл и прочитал за 3 минуты, что представляет из себя данный паттерн. Зачем эти 40 минут? Краткость - сестра таланта! В общем, только вводную часть можно было сократить до 30 секунд. Дальше не знаю. Обсасывать простейший паттерн 40 минут, это сильно.
Я не поверил тебе, примерно на 4 минуте я понял о чем ты говоришь и у меня возникло желание пойти в гугл. Не понимаю зачем мне так долго очевидные вещи рассказывать
Вооот. Наконец-то появилось на ютубе видео, которое объясняет реальные подходы к написанию кода. Надеюсь и дальше будут похожие видео, спасибо!
Про транзакшнл идея хорошая, туда же можно и про аннотацию лок добавить, жду с нетерпением!😊
Умничка, очень хорошо объясняешь) приятно слушать + пример кода, что ещё нужно для счастья
На 3:30 какая то каша. Во-первых пула транзакций не существует, есть connection pool, во-вторых, что значит что долгие транзакции блокируют другие быстрые транзакции, а конкретно в вашем примере на чтение??? Что под этим подразумевается? Вы хотите сказать, что если у меня транзакция, пусть даже уже 30 минут держит блокировку на какой-либо записи - я не смогу выполнить select ? С чего бы это вдруг? Особенно если берем за неупомянутые условие, что уровнь изоляции у нас стоит «read commited» т.е. по умолчанию.
Катя, спасибо за видос! Тема действительно актуальная!
Очень круто рассказываешь детали! Спасибо за труд, продолжай в том же духе!
Для отображения хоткеев при использовании есть какой-то готовый плагин в IDEA. Он будет выводить на экран комбинации клавиш и не придется каждый раз объяснять что было нажато
Создавать мапу для реализации стратегии можно следующим образом:
1. У каждого task processor прописываешь метод, который возвращает тип (taskType)
1. Создаешь конфигурационный файл, в него инжектишь список таск процессоров
2. Создаешь Бин мапы, где каждый элемент списка мапишь по taskType
Теперь можно добавлять сколько угодно обработчиков делать, просто добавляя новый taskType и его реализацию
классное видео! Пожелание по монтажу - не увеличивать части кода и схем на доске, это и так норм видно, а при перепрыгивании зума сложнее следить
Катя, сделай пожалуйста видео про объяснение АНОТАЦИЙ СПРИНГА, КЛАССЫ КОТОРЫЕ ИСПОЛЬЗУЮТСЯ В СПРИНГЕ И ВЗАИМОДЕЙСТВИЕ ЧЕРЕЗ СЕТЬ. плииииз. залайкайте комент чтобы Катюньдель увидела и сделала видео
А прочитать слабо? Поколение аутистов...
Возможно, буду капитаном, но интерфейсы все-таки лучше создавать для:
1) Возможности замокать его для тестирования, передав под интерфейсом фальшивую реализацию сервиса, имитирующую работу, необходимую для проведения теста
2) Тут уже спорно конечно, но все же, для соблюдения Interface segregation из SOLID. Например, если нужно реализовать сервис, который занимается всеми задачами в рамках одного домена, а в какую-то часть приложения нужно проинжектить только нужный для этой части функционал этого сервиса - применяем Interface только для этого функционала
Лайкусик
Крутой урок, спасибо
Мегаполезный видос, столько сопутствующих тем затронуто. Ну прям бест практикс! Огромное спасибо!
Продолжай, супер комфортная подача материала)
Отличный контент, спасибо! Пилите больше
Наконец-то!!! Эту информацию нужно нести в массы. Спрашиваю на собесе уже 10 лет, 1 из 10 может хоть что-то ответить, а ведь это азы!
1 из 10 соответствующий должности - это очень хороший показатель. И это релевантно для любой сферы. Было время подбирал сотрудников в строительную компанию. Я бы мог только мечтать, если бы 1 из 10 кандидатов подходил.
Через интерфейсы работает прокси спринга, иначе он будет городить огород из абстрактных классов.
Было бы здорово, если Ты сделала бы вторую часть разбора этого патерна. О том как можно улучшить этот паттерн и какие можно сделать оптимизации для улучшения производительности.
Хотим узнать о Event Driven )
А если напимер rest запрос от Scheduler не дойдет в DeliveryService но дойдет в NotificationService или наоборот?
Увожение!
Одноразовые интерфейсы мб нужны для dependency inversion или при работе над частью фичи которая не включает реализацию интерфейса, а только те места, которые надо сделать в рамках задачи
1) Сервисы помеченные как бины спринга не нужно создавать через new. Если хотите сделать стратегию через спринг, посмотрите доклад Евгения Борисова про паттерны на спринге...
2) Помоему у вас select for update и сам update в разных транзакциях, думаете локи будут работать?:)
А так в целом нормально. 🎉
У меня глаз задёргался, когда я увидел new
2) А как ты себе представляешь использование SELECT FOR UPDATE для лока в рамках одной транзакции? Какой в этом смысл? Стейтменты в рамках одной транзакции и так же последовательно выполняются. SELECT FOR UPDATE и создан для того, чтобы другие транзакции UPDATE не выполняли. Вообще представляешь себе возникновение состояния гонки в рамках одной транзакции? Я думаю, что нет
Единственное, что могут быть повторные отправки в случае такого подхода, но это вроде базовая практика идемпотентные эндпоинты писать, так что проблем быть не должно
Спасибо за отличное видео! Было бы интересно увидеть реализацию реактивного подхода(если сталкивалась) 🙃
если таблица retryable_task одна в микросервисной архитектуре, и ты предлагаешь одну таблицу иметь для всех ретраев, то как эта таблица будет шариться между сервисами?
25.40 вместо ручной вставки типов, можно добавить метод в интерфейс TaskType. Далее private final List и потом его привратить во что то типа Map.
Прикольно, спасибо) Хоть сам пишу на руби, но все было более чем понятно
Из пула точно берутся транзакции, не коннекшн?)
34:47 например, executorService + countdownLatch)
37:21 Да что за "запихиваем"? Инжектим, внедряем, применяем мб?
Спасибо за видео❤
годный контент, надеюсь такие видосы будут каждый день выходить. темный фон конечно депрессивно смотрится, но эт уже вкусовщина, мне бы и снятый на кухне такой видос зашел бы
годнота
Мне понравилось видео, отдельное спасибо за пример кода!
Подпишусь, пожалуй. По многопоточке тоже интересно посмотреть ролик)
полезное видео! спасибо!
классное объяснение по такой полезной и в то же время мало-известной (как мне показалось) теме 💯💯
был личный опыт - на собесе спросили как можно убедиться в целостности данных при распределённых транзакциях (ни про 2х фазный коммит, ни сагу, ни аутбокс я не знал), пришлось самому что то выдумывать 😅😅
А что за паттерн с процессорами?
Как насчет аналогичного примера с гарантированной доставкой/получением в/из Кафка?
Качественный контент, наконец-то!
Паттерн на 33:02 - фабрика?
Тоже не вижу смысла сразу создавать интерфейсы на все подряд. Понадобится вторая реализация, тогда можно выделить интерфейс.
Чем больше слоев абстракций тем лучше. Сарказм если что. 😂
Паттерн команда используется с маппой?
Классное видео, хоть я php разраб но было интересно как у вас в java мире это все пишется, спасибо за видео!
В пхп мире ровно так же используется этот паттерн
@@a-shchedrin8466 поэтому человек и написал не "как у вас в java мире это все используется", а "как у вас в java мире это все пишется"
Разбор классный, ждём разбор задач с @Transactional.
Про интерфейсы - под капотом же спринг через них прокси объекты создаёт насколько помню
Все отлично по содержанию, спасибо! Классно будет, если на канале будет такой контент. Его не хватает.
P.S. По мне слишком часто отдаляется/приближается камера. Прям тяжело смотреть
Размер транзакций ограничен, понятно что про пул конекшинов, но вызвало улыбку)
Привет, давай про @Transactional, что за плагин который подсказывает автокомплитит код?
Прошу еще про другие паттерны, начал изучать java
В одном потоке несколько тасков лучше не обрабатывать либо брать из базы одну таску под локом
15:31 - верное замечание по-поводу интерфейсов - однозначно лойс. У нас на проекте сейчас (!) интерфейсы используются как правило в библиотеках, поскольку слепое следование SOLID ведет к раздутости кода. Тем ребятам, кто впоследствии будет смотреть код, где слепо следуют этому принципу будет очень неприятно разбираться во всех этих кишках и простынях кода
Разве что чтоб потом в тестах мокать было удобнее
Тут кто как понял солид. Инжектируемый инстанс репозитория сам по себе интерфейс. Тут как посмотреть
интерфейсы это про ООП, а не про SOLID. солиду нужно следовать всегда в промышленном коде. как раз в простынях кода разбираться и не придется, потому что каждая ответственность будет сосредоточена в отдельном классе/пакете/модуле
Не согласен. Считается что использование интерфейсов нужно для создания JDK Dynamic Proxy, так как CGLIB Proxy это более тяжелый механизм, так как требует создания подкласса.
На Хабре есть статья, где чувак пытается заставить спринг создать JDK прокси. И у него так и не получилось. Спринг упорно создавал CJLIB прокси даже для классов имеющих интерфейс
Очень полезно. Отдельное спасибо за англословечки с нормальным русским произношением, слух не режет.
32:59
Решение конечно красивое, но зачем было помечать их service если используете new ?
И потом, почему service а не component? Service для бизнес логики то что в нашем домене, а тут какие то retryableTask о которых бизнес не знает даже
Что делать при подходе один сервис - одна база? Для отдельного сервиса Sceduler есть отдельная база, в которую нужно положить сообщение - это опять отправка данных в другой сервис во время транзакции... Или Scheduler отдельный сервис внутри микросервиса?
Если тебе нужна транзакционность между сервисами, посмотри в сторону Saga или в целом 2PC.
Такие все классные программисты , а где ваш видео-Хостинг взамен UA-cam интересно спросить
крутяк, спасибо за видео!
22:01 Зачем @Transactional над createRetyableTask?
канал интересный, подписался, правда вопрос это по сути самописанный RabbitMQ в своей базе данных, async messaging pub-sub with retry, я правильно понял?
Ё спасибо было круто😊
Лучшее видео за последнюю тысячу лет!!! О нем будут слагать легенды и эпосы!!
Об этом комментарии точно сложат легенды. Так глубоко никто никого не нахваливал в нашей галактике последние миллиард лет😂
В каком месте?
@@mugen31337 справа
@@mugen31337 справа
Многопоточку и transactional было бы интересно послушать 🙏
про transactional было бы интересно
Почему в бд время не получать? CURRENT_TIMESTAMP().
Вместо Pageable можно Limit.of() (после 3ю2) спринга
Провожу собеседования много лет, никогда не спрашивал(и у меня никто не спрашивал) такого ^__^
и у меня есть ряд вопросов по коду
* зачем отдельная транзакция на создание таски, ведь она уже создана в сервисе выше? я понимаю что она пропагейтится, но фигачить на каждый метод не круто
* в мапстракт маппере создается еще один джексон маппер, зачем когда он уже есть в контексте спринга который и настраивается еще из пропертей? а тут 2 маппера с разными настройками
* последнее и самое главное, начинали с "держать транзакцию пока выполнится запрос плохо", но пришли к "теперь мы держим транзакцию n*requestTime" что еще дольше и еще хуже чем первая :)
на счет микросервисности, этот паттерн применим везде, но текущая реализация не подходит для микросервисов(джоба только в 1 поток может работать)
код на бусти не видел, может там skip locked и тред пулы есть)
Да тут вообще дизайн полный ужас. Это в какой компании интересно такой подход используют? И полагаться на время в разных выборках тоже так себе практика время скорее всего не будет суперточно совпадать на разных инстансах особенно если они на разных физических машинах. Ну и да сваливать все в одну таблицу что бы потом из type городить огромный бородатый switch который будет решать в какую очередь отправить.. вообще вишенка.
@@maksimmuruev423 какой свитч ты чего алё, про нормальную стратегию не слышали
начинали с "держать транзакцию пока выполнится запрос плохо", но пришли к "теперь мы держим транзакцию n*requestTime" что еще дольше и еще хуже чем первая
-
почему дольше-то? Сохранить в БД дольше чем отправить запрос и дождаться ответа?
Годно по состоянию на начало 200х. А сейчас уж лучше event driven вокруг брокера
Ну ещё бы надо добавить, что это at least once доставка, так как отправитель может упасть после сделанной отправки , не успев проставить соответствующий статус.
вокруг брокера(сага - хореография) уже не модно. Последние новости моды: temporal(сага оркестрируемая + FSM) :)
Плохая реализация паттерна стратегия-опен клоус нарушен например)Плюс объявление метода с 4 параметрами -такая себе история
Здравствуйте, но возник такой вопрос: зачем такие данные хранить в sql бд, почему нельзя засунуть это в редис. Не знаю как в java, но знакомы ли вы с Celery?
А как вы транзакционность обеспечите между БД и Redis?
@@dragvs Редис и есть БД, и я не понял вопроса, но попытаюсь, ответить, по тому как я понял: Зачем в данном кейсе нам вообще sql бд? Если сохранение тасков можно хранить в ligthweight бд, с форматом ключ-значение
@@inftech8976 вы понимаете что такое ACID и почему оно важно в данном кейсе? Вы предлагаете просто SQL DB заменить на NoSQL - в чем профит? В банках часто применяется SQL для хранения данных, как вы будете обосновывать решение? А почему не блокчейн? Он тут тоже подходит - в обе «таблицы» писать одной транзакцией. Выбор не так тривиален и сильно зависит от контекста.
@@dragvs По вашему если я поменяю sql на nosql, то нарушится консистетность? Как она может нарушится, если нет никаких данных, которые бы могли взаимодействовать друг с другом? Хранение тасков и хранение к примеру клиентских данных, это совсем разные вещи, и никак не относятся друг к другу.
При чем тут банк и хранение данных там? Я не говорил, что надо использовать основную БД как редис, ни один разумный человек не поставит основную бд с NoSQL, либо вы не понимаете суть этого ролика
В случае видео, с хранением тасков, которые могли бы потеряться, автор использует SQL бд, а в таких случаях, бд с sql плохо подходит, потому что она будет работать медленно и нагружать к тому же сам сервис бд, если конечно не сделать отдельный сервис для тасков к примеру тем же postgres. А редис, конечно тоже нужно поднимать сервис, но нагрузки будет меньше, да и быстрее будут выводы, просто потому что таски - не такие сущности как те же клиентские данные. key-value
@@inftech8976 как вы будете ACID обеспечивать? Вам нужно атомарно и конситентно сохранить запись с данными и запись для отправки во внешнюю систему. Консистентность у вас нарушится если одна БД запишет а другая нет, у вас же payload это производная от записи в SQL базу. В этом весь «сок» паттерна. То что вы пытаетесь предложить можно с таким же успехом сразу запрос слать во внешнюю систему, какая разница Redis у вас внешка или notification service - вы получите те же проблемы решения.
А если ux дизайнеры решили, что нужно сразу получать информацию о доставке? А у вас delivery service отвечает минуту. Что будете делать?
Какую именно информацию? При оформлении заказа уже есть адрес доставки и отправки. Расстояние между двумя точками, время примерной доставки и стоимость вполне можно рассчитать в синхроне. Данные о курьере, если такой предусмотрен, ты не получишь, пока система его не подберёт. Это может быть и секунда, и минута, и десять минут. Поэтому на фронт обычно отдаётся статус заказа 'PENDING', отрисовывая экран с оформленным заказом и надпись "подбираем курьера", при подборе курьера отправляется пуш на клиента, который отрисовывает уже другой экран с информацией о курьере. Именно так работает Bolt такси, например.
@@channel-yg2xc а что, у тебя фронт будет получать полную информацию о курьере через сервис заказов? Или все таки достаточно зарегистрировать синхронно доставку, получить id?
@@channel-yg2xc а у тебя что, сервис заказов возвращает полную информацию о доставке на фронт? Может все таки зарегистрировать доставку, получить id? Я конечно рад за bold такси, что у них распределённый монолит работает, но все таки я бы предпочел микросервисы
На бусти нюдсы будут?
Зачем эти переходы вперёд - назад на каждое предложение? Укачивать начинает то ли от переходов, то ли от возмущения странности монтажа
А в чем смысл на 2:20 говорить, что пихать операцию создания записи в бд и рест запрос в транзакцию это кринж, а потом на этапе передачи сообщения в брокер, обмазывать это транзакцией(19:30)?
годно, пили еще
380 подписчиков?! Я ожидал как минимум 380 тысяч!
Досмотрел до UUID ключа. Аргументация еще круче "потому что я люблю". Ни слова про перфоманс, ни слова про то почему может потребоваться UUID и какие версии есть.
@@anti1am3r приходи на след видос, буду все для тебя аргументировать
Еще на стрим можешь зайти
Процессоры можно было бы тоже сделать бинами)
Катя, расскажи лучше, пожалуйста, как в hh устраивалась и как испыталку "прошла"🍿
так она рассказывала, ты же оттуда это и узнал, тут видос про transactional outbox вроде, а не про прохождения испытов)
@vincentvega1444 кинь link, пожалуйста. Занимательно будет соотнести с той in-side инфой, что у меня имеется, и тем, что в паблике ;)
всё. я влюбился.
Подскажите, очень надо.
Java не учил ещё, знаю только python.
Часто нужно получить apk.
Декомпилировать.
И собственно реверс и поиск как значений, так и методы формирования значений для запросов приложения, которые отснифаны ранее.
Либо снятие защиты от снифа или от запуска на эмуляторе андроида , снова упаковка в apk и запуск.
Реверс инженеринг.
Как?
Где?
Чем?
Каким образом?
В общем, сервисы, ресурсы, где можно учить, изучать, использовать, для решения подобных задач.
Java выучу, клянусь и ещё 4-5 языков, чуть позже, сейчас другое важное учу и решаю.
Подскажи, очень нужно дельный совет.
Заранее спасибо.
Целую в щёчки, жму сосочки.
Отличный видос! Действительно обязательная тема для миддл+/синьор бэкендеров.
Nit: Кажется в видео было упущено сохранение обновленных значений retryTime для тех retryableTasks которые мы все же не смогли обработать. Не сильно шарю в джаве, но кажется если обновленные значения закинуть в цикле через сеттер, то в бд они не отразятся. Наверное надо было просто добавить метод в репо, который бы обновил те записи, у которых статус не изменился на success.
На джвае нет что ли готовых шедуле библиотек ? - свой велосипед для типовой задачи как-то кринжово.
На счет интерфейса для заказов . я бы небыл так уверен , сегодня в БД пишете заказы . а завтра решили сливать их в какую либо CRM-ку , да и в целом бизнес логика оформления заказа часто меняется , лучше пусть будет интерфейс он каши не просит реализуется за пять сек, и это точно не сложнее чем все потом править.
Спасибо за видео, на гитлабе не видно проект
Откуда ты все это знаешь
А что если мы успешно заретраили, но упали на апдейте статуса тасок?
@@pagorbunov сообщение отправится ещё раз. Тип доставки at least once
топ
ua-cam.com/video/HI-XvL2FkTQ/v-deo.htmlsi=YM1n8aHc0c-GOgNp&t=220
Привет.
Почему транзакция на запись блокирует чтение?
REST это не протокол, а соглашение.
стандарт*
протокол - это и есть соглашение, в каком виде приходят данные. Но REST сам по себе лишь один из видов представления передачи данных.
@@ggnet-lm7pgНет, rest это не соглашение формата данных. Строго говоря, данные могут быть в любом формате: json, xml, html, byte file, plain text и т.д. Rest в первую очередь соглашение о формате урла и отображении состояния запрашиваемой/передаваемой инофрмации путем внедения уникального идентификатора. Согласно модели OSI, rest не протокол, а SOAP вполне, т.к. имеет строгие ограничения формата передаваемых данных, при чем оба они работают с протоколом http.
@@channel-yg2xc Я и не говорил, что REST - это протокол. Я сказал что это data transfer architectural pattern/view, который накладывает определённые ограничения на передачу данных. В названии SOAP - явно указывается, что это протокол, в отличии от REST. REST - не является имплементацией, и не зависит от application/transport протокола.
@@ggnet-lm7pg
- REST это не протокол, а соглашение
- протокол это и есть соглашение
- я не говорил что Rest - это протокол
)))
Но это такое, ты сказал, цитирую: "...Но REST сам по себе лишь один из видов представления передачи данных", я ответил, что это не так. Все ограничения формата данных, передаваемых по REST - это ограничения протокола http. В самом же REST нет ограничений http request body ни логически-концептуальных, ни физических, - его физически ограничивает протокол http и ни что более. Соответственно "вид/view"(проще говоря, данные запроса и ответа) может быть любым, который удовлетворяет протоколу http.
Я все равно не уловил фишку. Почему не послать просто в очередь? Зачем это все? И это как по мне не решает проблему, а переносить в другое место. Планировщик так же будет блокировать таблицу на добавление новых записей. Собственно, поэтому никто не знает ответ на собесах - слишком это кривое, неэлегантное решение.
Какие новые записи создаёт планировщик и что блокирует?
В виде не сказано про idempotent Id в каждом запросе от планировщика к другому сервису. Этот id помогает слать один запрос много раз. А после успешной отправки запроса или ответа 409/406 (и т.д.) открыть транзакцию и обновить bool поле "отправлено"
prevet krasavisa
Хата волкаа? ❤🎉
Все же у нас пул соединений, не транзакций. И мы не ограничиваем кол-во транзакций в хикари. Ну и в целом аргументация по транзакциям очень слабая.
Здесь после каждого слова склейка видео? 😸 Теперь я знаю способ делать из женщин разрабов 😹😹
Просто она через каждое слово матерится, заводская привычка, пришлось вырезать
Я не понял, а чем собственно rest запрос на другой микросервис, который может быть "долгим" отличается от той же самой записи в базу данных, которая тоже может быть долгой. Это два внешних сервиса, никто не гарантирует что в какой-то из них запрос будет идти дольше/быстрее
И даже если мы запишем запрос с json в базу чтобы потом когда то там куда то там его отправить - мы все ещё не гарантируем что он дойдет до нужного сервиса. Даже не гарантируем когда он дойдет до сервиса. Просто поменяли шило на мыло.
Также потенциально таблица с заданиями отправить запросы может невероятно разрастись. Добавляется ещё одна потенциальная точка отказа
Вопрос правильный, ответ такой: базу выбираете вы сами и рассчитываете под свои потребности и можете подкрутить, если что. Другой же микросервис вы не контролируете, ну по крайней мере будем так считать. Ну и вот.
Тем что в первом случае у тебя вся транзакция отвалится по таймауту. Второй вариант позволяет тебе сохранить транзакционность доставки не имея проблем с таймаутом и тем что транзакция занята ожиданием ответа от другого сервиса. Конечно transactional outbox не под все задачи подходит. Но на видео разобрали очень популярный юзкейс. Если тебе нужная транзакционность между сервисами, посмотри в сторону 2PC и связанные паттерны. Вижу что в комментах люди пытаются натянуть сову на глобус.
@@paxpax1707 извините конечно но каким боком сохранение в базу и бесконечные ретраи обеспечивают транзакционность? Запрос спокойно себе может никогда не осуществится. Это полный бред
Ну почему java 😭😭😭😭😭
Герои не носят плащи
Какая бредятина...
Я больше не слушаю Асмр )
Описание проблемы неверное, она не понимает о чем говорит.
Так опиши конкретно, что не правильно
Как минимум во вступлении отсутствует информация что мы что-то сохраняем в базу данных, это смешно просто слушать, что сообщение может потеряться в Кафке, а из тмб оно не может потом потеряться в Кафке, дилетантство, прочитали пару статей в интернете и давай клепать ролики для хомяков
Проблема в необходимости писать в больше чем один сервис, с этого надо начинать, у вас каша полная, вы не понимаете ничего в этом и не умеете выражать свои мысли последовательно
@@vladislavlebedev6059 сейчас половина айти такое к сожалению. Сейчас отовсюду слышны крики что главное это софтскилы для построения карьеры в айти, вот результат. Читаем пару статей и идём с докладом на конференцию выдавая себя за эксперта. Это айти которое мы заслужили ! 😉
Устал слушать воду на 4й минуте. Пошел в гугл и прочитал за 3 минуты, что представляет из себя данный паттерн. Зачем эти 40 минут? Краткость - сестра таланта! В общем, только вводную часть можно было сократить до 30 секунд. Дальше не знаю. Обсасывать простейший паттерн 40 минут, это сильно.
Там ещё код такой и в целом "архитектура".
Спасибо, сэкономил время
Ну вам такой стиль не подходит значит . Кому то наоборот чем детальнее и подробнее тем лучше, все люди разные🤷♂️
Ты должен был наслаждаться красотой говорящего😅
Я не поверил тебе, примерно на 4 минуте я понял о чем ты говоришь и у меня возникло желание пойти в гугл.
Не понимаю зачем мне так долго очевидные вещи рассказывать
Катя, иди борщ варить.
А я реально очень вкусный кубанский борщ готовить умею, видимо нужен кукинг стрим
@@JAVAGYMRAT 💋
Кстати, что у тебя за ноут, MagicBook16?
Дыа
Хо-хо-хо, мать, ты появилась как раз вовремя, тебя то я и искал
такая ты малышка умная