Вооот. Наконец-то появилось на ютубе видео, которое объясняет реальные подходы к написанию кода. Надеюсь и дальше будут похожие видео, спасибо! Про транзакшнл идея хорошая, туда же можно и про аннотацию лок добавить, жду с нетерпением!😊
Катя, сделай пожалуйста видео про объяснение АНОТАЦИЙ СПРИНГА, КЛАССЫ КОТОРЫЕ ИСПОЛЬЗУЮТСЯ В СПРИНГЕ И ВЗАИМОДЕЙСТВИЕ ЧЕРЕЗ СЕТЬ. плииииз. залайкайте комент чтобы Катюньдель увидела и сделала видео
Создавать мапу для реализации стратегии можно следующим образом: 1. У каждого task processor прописываешь метод, который возвращает тип (taskType) 1. Создаешь конфигурационный файл, в него инжектишь список таск процессоров 2. Создаешь Бин мапы, где каждый элемент списка мапишь по taskType Теперь можно добавлять сколько угодно обработчиков делать, просто добавляя новый taskType и его реализацию
1 из 10 соответствующий должности - это очень хороший показатель. И это релевантно для любой сферы. Было время подбирал сотрудников в строительную компанию. Я бы мог только мечтать, если бы 1 из 10 кандидатов подходил.
Было бы здорово, если Ты сделала бы вторую часть разбора этого патерна. О том как можно улучшить этот паттерн и какие можно сделать оптимизации для улучшения производительности. Хотим узнать о Event Driven )
1) Сервисы помеченные как бины спринга не нужно создавать через new. Если хотите сделать стратегию через спринг, посмотрите доклад Евгения Борисова про паттерны на спринге... 2) Помоему у вас select for update и сам update в разных транзакциях, думаете локи будут работать?:) А так в целом нормально. 🎉
классное объяснение по такой полезной и в то же время мало-известной (как мне показалось) теме 💯💯 был личный опыт - на собесе спросили как можно убедиться в целостности данных при распределённых транзакциях (ни про 2х фазный коммит, ни сагу, ни аутбокс я не знал), пришлось самому что то выдумывать 😅😅
Увожение! Одноразовые интерфейсы мб нужны для dependency inversion или при работе над частью фичи которая не включает реализацию интерфейса, а только те места, которые надо сделать в рамках задачи
годный контент, надеюсь такие видосы будут каждый день выходить. темный фон конечно депрессивно смотрится, но эт уже вкусовщина, мне бы и снятый на кухне такой видос зашел бы
15:31 - верное замечание по-поводу интерфейсов - однозначно лойс. У нас на проекте сейчас (!) интерфейсы используются как правило в библиотеках, поскольку слепое следование SOLID ведет к раздутости кода. Тем ребятам, кто впоследствии будет смотреть код, где слепо следуют этому принципу будет очень неприятно разбираться во всех этих кишках и простынях кода
интерфейсы это про ООП, а не про SOLID. солиду нужно следовать всегда в промышленном коде. как раз в простынях кода разбираться и не придется, потому что каждая ответственность будет сосредоточена в отдельном классе/пакете/модуле
Не согласен. Считается что использование интерфейсов нужно для создания JDK Dynamic Proxy, так как CGLIB Proxy это более тяжелый механизм, так как требует создания подкласса.
На Хабре есть статья, где чувак пытается заставить спринг создать JDK прокси. И у него так и не получилось. Спринг упорно создавал CJLIB прокси даже для классов имеющих интерфейс
Все отлично по содержанию, спасибо! Классно будет, если на канале будет такой контент. Его не хватает. P.S. По мне слишком часто отдаляется/приближается камера. Прям тяжело смотреть
Из пула точно берутся транзакции, не коннекшн?) 34:47 например, executorService + countdownLatch) 37:21 Да что за "запихиваем"? Инжектим, внедряем, применяем мб? Спасибо за видео❤
Ну ещё бы надо добавить, что это at least once доставка, так как отправитель может упасть после сделанной отправки , не успев проставить соответствующий статус.
Досмотрел до UUID ключа. Аргументация еще круче "потому что я люблю". Ни слова про перфоманс, ни слова про то почему может потребоваться UUID и какие версии есть.
Провожу собеседования много лет, никогда не спрашивал(и у меня никто не спрашивал) такого ^__^ и у меня есть ряд вопросов по коду * зачем отдельная транзакция на создание таски, ведь она уже создана в сервисе выше? я понимаю что она пропагейтится, но фигачить на каждый метод не круто * в мапстракт маппере создается еще один джексон маппер, зачем когда он уже есть в контексте спринга который и настраивается еще из пропертей? а тут 2 маппера с разными настройками * последнее и самое главное, начинали с "держать транзакцию пока выполнится запрос плохо", но пришли к "теперь мы держим транзакцию n*requestTime" что еще дольше и еще хуже чем первая :) на счет микросервисности, этот паттерн применим везде, но текущая реализация не подходит для микросервисов(джоба только в 1 поток может работать) код на бусти не видел, может там skip locked и тред пулы есть)
Да тут вообще дизайн полный ужас. Это в какой компании интересно такой подход используют? И полагаться на время в разных выборках тоже так себе практика время скорее всего не будет суперточно совпадать на разных инстансах особенно если они на разных физических машинах. Ну и да сваливать все в одну таблицу что бы потом из type городить огромный бородатый switch который будет решать в какую очередь отправить.. вообще вишенка.
начинали с "держать транзакцию пока выполнится запрос плохо", но пришли к "теперь мы держим транзакцию n*requestTime" что еще дольше и еще хуже чем первая - почему дольше-то? Сохранить в БД дольше чем отправить запрос и дождаться ответа?
Что делать при подходе один сервис - одна база? Для отдельного сервиса Sceduler есть отдельная база, в которую нужно положить сообщение - это опять отправка данных в другой сервис во время транзакции... Или Scheduler отдельный сервис внутри микросервиса?
канал интересный, подписался, правда вопрос это по сути самописанный RabbitMQ в своей базе данных, async messaging pub-sub with retry, я правильно понял?
32:59 Решение конечно красивое, но зачем было помечать их service если используете new ? И потом, почему service а не component? Service для бизнес логики то что в нашем домене, а тут какие то retryableTask о которых бизнес не знает даже
Туда можно недотянуть? Судя по их говноприложению там знаний не требуется от слова совсем, особенно тем кто проектирует это все, да и юридический отдел из детского сада набирают.
@@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.
Какую именно информацию? При оформлении заказа уже есть адрес доставки и отправки. Расстояние между двумя точками, время примерной доставки и стоимость вполне можно рассчитать в синхроне. Данные о курьере, если такой предусмотрен, ты не получишь, пока система его не подберёт. Это может быть и секунда, и минута, и десять минут. Поэтому на фронт обычно отдаётся статус заказа 'PENDING', отрисовывая экран с оформленным заказом и надпись "подбираем курьера", при подборе курьера отправляется пуш на клиента, который отрисовывает уже другой экран с информацией о курьере. Именно так работает Bolt такси, например.
@@channel-yg2xc а что, у тебя фронт будет получать полную информацию о курьере через сервис заказов? Или все таки достаточно зарегистрировать синхронно доставку, получить id?
@@channel-yg2xc а у тебя что, сервис заказов возвращает полную информацию о доставке на фронт? Может все таки зарегистрировать доставку, получить id? Я конечно рад за bold такси, что у них распределённый монолит работает, но все таки я бы предпочел микросервисы
На джвае нет что ли готовых шедуле библиотек ? - свой велосипед для типовой задачи как-то кринжово. На счет интерфейса для заказов . я бы небыл так уверен , сегодня в БД пишете заказы . а завтра решили сливать их в какую либо CRM-ку , да и в целом бизнес логика оформления заказа часто меняется , лучше пусть будет интерфейс он каши не просит реализуется за пять сек, и это точно не сложнее чем все потом править.
Здравствуйте, но возник такой вопрос: зачем такие данные хранить в 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 - вы получите те же проблемы решения.
Отличный видос! Действительно обязательная тема для миддл+/синьор бэкендеров. Nit: Кажется в видео было упущено сохранение обновленных значений retryTime для тех retryableTasks которые мы все же не смогли обработать. Не сильно шарю в джаве, но кажется если обновленные значения закинуть в цикле через сеттер, то в бд они не отразятся. Наверное надо было просто добавить метод в репо, который бы обновил те записи, у которых статус не изменился на success.
Подскажите, очень надо. Java не учил ещё, знаю только python. Часто нужно получить apk. Декомпилировать. И собственно реверс и поиск как значений, так и методы формирования значений для запросов приложения, которые отснифаны ранее. Либо снятие защиты от снифа или от запуска на эмуляторе андроида , снова упаковка в apk и запуск. Реверс инженеринг. Как? Где? Чем? Каким образом? В общем, сервисы, ресурсы, где можно учить, изучать, использовать, для решения подобных задач. Java выучу, клянусь и ещё 4-5 языков, чуть позже, сейчас другое важное учу и решаю. Подскажи, очень нужно дельный совет. Заранее спасибо. Целую в щёчки, жму сосочки.
Я все равно не уловил фишку. Почему не послать просто в очередь? Зачем это все? И это как по мне не решает проблему, а переносить в другое место. Планировщик так же будет блокировать таблицу на добавление новых записей. Собственно, поэтому никто не знает ответ на собесах - слишком это кривое, неэлегантное решение.
Какие новые записи создаёт планировщик и что блокирует? В виде не сказано про idempotent Id в каждом запросе от планировщика к другому сервису. Этот id помогает слать один запрос много раз. А после успешной отправки запроса или ответа 409/406 (и т.д.) открыть транзакцию и обновить bool поле "отправлено"
Я не понял, а чем собственно rest запрос на другой микросервис, который может быть "долгим" отличается от той же самой записи в базу данных, которая тоже может быть долгой. Это два внешних сервиса, никто не гарантирует что в какой-то из них запрос будет идти дольше/быстрее
И даже если мы запишем запрос с json в базу чтобы потом когда то там куда то там его отправить - мы все ещё не гарантируем что он дойдет до нужного сервиса. Даже не гарантируем когда он дойдет до сервиса. Просто поменяли шило на мыло.
Вопрос правильный, ответ такой: базу выбираете вы сами и рассчитываете под свои потребности и можете подкрутить, если что. Другой же микросервис вы не контролируете, ну по крайней мере будем так считать. Ну и вот.
Тем что в первом случае у тебя вся транзакция отвалится по таймауту. Второй вариант позволяет тебе сохранить транзакционность доставки не имея проблем с таймаутом и тем что транзакция занята ожиданием ответа от другого сервиса. Конечно transactional outbox не под все задачи подходит. Но на видео разобрали очень популярный юзкейс. Если тебе нужная транзакционность между сервисами, посмотри в сторону 2PC и связанные паттерны. Вижу что в комментах люди пытаются натянуть сову на глобус.
@@paxpax1707 извините конечно но каким боком сохранение в базу и бесконечные ретраи обеспечивают транзакционность? Запрос спокойно себе может никогда не осуществится. Это полный бред
Устал слушать воду на 4й минуте. Пошел в гугл и прочитал за 3 минуты, что представляет из себя данный паттерн. Зачем эти 40 минут? Краткость - сестра таланта! В общем, только вводную часть можно было сократить до 30 секунд. Дальше не знаю. Обсасывать простейший паттерн 40 минут, это сильно.
Как минимум во вступлении отсутствует информация что мы что-то сохраняем в базу данных, это смешно просто слушать, что сообщение может потеряться в Кафке, а из тмб оно не может потом потеряться в Кафке, дилетантство, прочитали пару статей в интернете и давай клепать ролики для хомяков
Проблема в необходимости писать в больше чем один сервис, с этого надо начинать, у вас каша полная, вы не понимаете ничего в этом и не умеете выражать свои мысли последовательно
Вооот. Наконец-то появилось на ютубе видео, которое объясняет реальные подходы к написанию кода. Надеюсь и дальше будут похожие видео, спасибо!
Про транзакшнл идея хорошая, туда же можно и про аннотацию лок добавить, жду с нетерпением!😊
Умничка, очень хорошо объясняешь) приятно слушать + пример кода, что ещё нужно для счастья
Катя, сделай пожалуйста видео про объяснение АНОТАЦИЙ СПРИНГА, КЛАССЫ КОТОРЫЕ ИСПОЛЬЗУЮТСЯ В СПРИНГЕ И ВЗАИМОДЕЙСТВИЕ ЧЕРЕЗ СЕТЬ. плииииз. залайкайте комент чтобы Катюньдель увидела и сделала видео
А прочитать слабо? Поколение аутистов...
Катя, спасибо за видос! Тема действительно актуальная!
Очень круто рассказываешь детали! Спасибо за труд, продолжай в том же духе!
Крутой урок, спасибо
Создавать мапу для реализации стратегии можно следующим образом:
1. У каждого task processor прописываешь метод, который возвращает тип (taskType)
1. Создаешь конфигурационный файл, в него инжектишь список таск процессоров
2. Создаешь Бин мапы, где каждый элемент списка мапишь по taskType
Теперь можно добавлять сколько угодно обработчиков делать, просто добавляя новый taskType и его реализацию
Отличный контент, спасибо! Пилите больше
Наконец-то!!! Эту информацию нужно нести в массы. Спрашиваю на собесе уже 10 лет, 1 из 10 может хоть что-то ответить, а ведь это азы!
1 из 10 соответствующий должности - это очень хороший показатель. И это релевантно для любой сферы. Было время подбирал сотрудников в строительную компанию. Я бы мог только мечтать, если бы 1 из 10 кандидатов подходил.
классное видео! Пожелание по монтажу - не увеличивать части кода и схем на доске, это и так норм видно, а при перепрыгивании зума сложнее следить
Продолжай, супер комфортная подача материала)
Было бы здорово, если Ты сделала бы вторую часть разбора этого патерна. О том как можно улучшить этот паттерн и какие можно сделать оптимизации для улучшения производительности.
Хотим узнать о Event Driven )
Мегаполезный видос, столько сопутствующих тем затронуто. Ну прям бест практикс! Огромное спасибо!
Прикольно, спасибо) Хоть сам пишу на руби, но все было более чем понятно
Тоже не вижу смысла сразу создавать интерфейсы на все подряд. Понадобится вторая реализация, тогда можно выделить интерфейс.
1) Сервисы помеченные как бины спринга не нужно создавать через new. Если хотите сделать стратегию через спринг, посмотрите доклад Евгения Борисова про паттерны на спринге...
2) Помоему у вас select for update и сам update в разных транзакциях, думаете локи будут работать?:)
А так в целом нормально. 🎉
У меня глаз задёргался, когда я увидел new
Спасибо за отличное видео! Было бы интересно увидеть реализацию реактивного подхода(если сталкивалась) 🙃
полезное видео! спасибо!
Мне понравилось видео, отдельное спасибо за пример кода!
классное объяснение по такой полезной и в то же время мало-известной (как мне показалось) теме 💯💯
был личный опыт - на собесе спросили как можно убедиться в целостности данных при распределённых транзакциях (ни про 2х фазный коммит, ни сагу, ни аутбокс я не знал), пришлось самому что то выдумывать 😅😅
Увожение!
Одноразовые интерфейсы мб нужны для dependency inversion или при работе над частью фичи которая не включает реализацию интерфейса, а только те места, которые надо сделать в рамках задачи
Очень полезно. Отдельное спасибо за англословечки с нормальным русским произношением, слух не режет.
Прошу еще про другие паттерны, начал изучать java
годный контент, надеюсь такие видосы будут каждый день выходить. темный фон конечно депрессивно смотрится, но эт уже вкусовщина, мне бы и снятый на кухне такой видос зашел бы
15:31 - верное замечание по-поводу интерфейсов - однозначно лойс. У нас на проекте сейчас (!) интерфейсы используются как правило в библиотеках, поскольку слепое следование SOLID ведет к раздутости кода. Тем ребятам, кто впоследствии будет смотреть код, где слепо следуют этому принципу будет очень неприятно разбираться во всех этих кишках и простынях кода
Разве что чтоб потом в тестах мокать было удобнее
Тут кто как понял солид. Инжектируемый инстанс репозитория сам по себе интерфейс. Тут как посмотреть
интерфейсы это про ООП, а не про SOLID. солиду нужно следовать всегда в промышленном коде. как раз в простынях кода разбираться и не придется, потому что каждая ответственность будет сосредоточена в отдельном классе/пакете/модуле
Не согласен. Считается что использование интерфейсов нужно для создания JDK Dynamic Proxy, так как CGLIB Proxy это более тяжелый механизм, так как требует создания подкласса.
На Хабре есть статья, где чувак пытается заставить спринг создать JDK прокси. И у него так и не получилось. Спринг упорно создавал CJLIB прокси даже для классов имеющих интерфейс
Все отлично по содержанию, спасибо! Классно будет, если на канале будет такой контент. Его не хватает.
P.S. По мне слишком часто отдаляется/приближается камера. Прям тяжело смотреть
Классное видео, хоть я php разраб но было интересно как у вас в java мире это все пишется, спасибо за видео!
В пхп мире ровно так же используется этот паттерн
@@a-shchedrin8466 поэтому человек и написал не "как у вас в java мире это все используется", а "как у вас в java мире это все пишется"
Из пула точно берутся транзакции, не коннекшн?)
34:47 например, executorService + countdownLatch)
37:21 Да что за "запихиваем"? Инжектим, внедряем, применяем мб?
Спасибо за видео❤
В одном потоке несколько тасков лучше не обрабатывать либо брать из базы одну таску под локом
крутяк, спасибо за видео!
Размер транзакций ограничен, понятно что про пул конекшинов, но вызвало улыбку)
про transactional было бы интересно
Многопоточку и transactional было бы интересно послушать 🙏
Качественный контент, наконец-то!
Ё спасибо было круто😊
Годно по состоянию на начало 200х. А сейчас уж лучше event driven вокруг брокера
Ну ещё бы надо добавить, что это at least once доставка, так как отправитель может упасть после сделанной отправки , не успев проставить соответствующий статус.
вокруг брокера(сага - хореография) уже не модно. Последние новости моды: temporal(сага оркестрируемая + FSM) :)
Лучшее видео за последнюю тысячу лет!!! О нем будут слагать легенды и эпосы!!
Об этом комментарии точно сложат легенды. Так глубоко никто никого не нахваливал в нашей галактике последние миллиард лет😂
В каком месте?
@@mugen31337 справа
@@mugen31337 справа
Паттерн команда используется с маппой?
Досмотрел до UUID ключа. Аргументация еще круче "потому что я люблю". Ни слова про перфоманс, ни слова про то почему может потребоваться UUID и какие версии есть.
@@anti1am3r приходи на след видос, буду все для тебя аргументировать
Еще на стрим можешь зайти
Паттерн на 33:02 - фабрика?
Провожу собеседования много лет, никогда не спрашивал(и у меня никто не спрашивал) такого ^__^
и у меня есть ряд вопросов по коду
* зачем отдельная транзакция на создание таски, ведь она уже создана в сервисе выше? я понимаю что она пропагейтится, но фигачить на каждый метод не круто
* в мапстракт маппере создается еще один джексон маппер, зачем когда он уже есть в контексте спринга который и настраивается еще из пропертей? а тут 2 маппера с разными настройками
* последнее и самое главное, начинали с "держать транзакцию пока выполнится запрос плохо", но пришли к "теперь мы держим транзакцию n*requestTime" что еще дольше и еще хуже чем первая :)
на счет микросервисности, этот паттерн применим везде, но текущая реализация не подходит для микросервисов(джоба только в 1 поток может работать)
код на бусти не видел, может там skip locked и тред пулы есть)
Да тут вообще дизайн полный ужас. Это в какой компании интересно такой подход используют? И полагаться на время в разных выборках тоже так себе практика время скорее всего не будет суперточно совпадать на разных инстансах особенно если они на разных физических машинах. Ну и да сваливать все в одну таблицу что бы потом из type городить огромный бородатый switch который будет решать в какую очередь отправить.. вообще вишенка.
@@maksimmuruev423 какой свитч ты чего алё, про нормальную стратегию не слышали
начинали с "держать транзакцию пока выполнится запрос плохо", но пришли к "теперь мы держим транзакцию n*requestTime" что еще дольше и еще хуже чем первая
-
почему дольше-то? Сохранить в БД дольше чем отправить запрос и дождаться ответа?
Как насчет аналогичного примера с гарантированной доставкой/получением в/из Кафка?
Процессоры можно было бы тоже сделать бинами)
всё. я влюбился.
Привет, давай про @Transactional, что за плагин который подсказывает автокомплитит код?
годно, пили еще
380 подписчиков?! Я ожидал как минимум 380 тысяч!
Такие все классные программисты , а где ваш видео-Хостинг взамен UA-cam интересно спросить
Паттерн стратегия, изи!)
Что делать при подходе один сервис - одна база? Для отдельного сервиса Sceduler есть отдельная база, в которую нужно положить сообщение - это опять отправка данных в другой сервис во время транзакции... Или Scheduler отдельный сервис внутри микросервиса?
Если тебе нужна транзакционность между сервисами, посмотри в сторону Saga или в целом 2PC.
Катя, расскажи лучше, пожалуйста, как в hh устраивалась и как испыталку "прошла"🍿
канал интересный, подписался, правда вопрос это по сути самописанный RabbitMQ в своей базе данных, async messaging pub-sub with retry, я правильно понял?
А что если мы успешно заретраили, но упали на апдейте статуса тасок?
@@pagorbunov сообщение отправится ещё раз. Тип доставки at least once
топ
32:59
Решение конечно красивое, но зачем было помечать их service если используете new ?
И потом, почему service а не component? Service для бизнес логики то что в нашем домене, а тут какие то retryableTask о которых бизнес не знает даже
Спасибо за видео, на гитлабе не видно проект
Хата волкаа? ❤🎉
Привет? В вб получилось пройти отбор или не дотянула? Спасибо. Просьо интересно.
Туда можно недотянуть? Судя по их говноприложению там знаний не требуется от слова совсем, особенно тем кто проектирует это все, да и юридический отдел из детского сада набирают.
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.
А если ux дизайнеры решили, что нужно сразу получать информацию о доставке? А у вас delivery service отвечает минуту. Что будете делать?
Какую именно информацию? При оформлении заказа уже есть адрес доставки и отправки. Расстояние между двумя точками, время примерной доставки и стоимость вполне можно рассчитать в синхроне. Данные о курьере, если такой предусмотрен, ты не получишь, пока система его не подберёт. Это может быть и секунда, и минута, и десять минут. Поэтому на фронт обычно отдаётся статус заказа 'PENDING', отрисовывая экран с оформленным заказом и надпись "подбираем курьера", при подборе курьера отправляется пуш на клиента, который отрисовывает уже другой экран с информацией о курьере. Именно так работает Bolt такси, например.
@@channel-yg2xc а что, у тебя фронт будет получать полную информацию о курьере через сервис заказов? Или все таки достаточно зарегистрировать синхронно доставку, получить id?
@@channel-yg2xc а у тебя что, сервис заказов возвращает полную информацию о доставке на фронт? Может все таки зарегистрировать доставку, получить id? Я конечно рад за bold такси, что у них распределённый монолит работает, но все таки я бы предпочел микросервисы
22:01 Зачем @Transactional над createRetyableTask?
prevet krasavisa
Skip locked нужен, видос хорошая попытка объяснить, но косячнула чуток
На бусти нюдсы будут?
На джвае нет что ли готовых шедуле библиотек ? - свой велосипед для типовой задачи как-то кринжово.
На счет интерфейса для заказов . я бы небыл так уверен , сегодня в БД пишете заказы . а завтра решили сливать их в какую либо CRM-ку , да и в целом бизнес логика оформления заказа часто меняется , лучше пусть будет интерфейс он каши не просит реализуется за пять сек, и это точно не сложнее чем все потом править.
Все же у нас пул соединений, не транзакций. И мы не ограничиваем кол-во транзакций в хикари. Ну и в целом аргументация по транзакциям очень слабая.
Хо-хо-хо, мать, ты появилась как раз вовремя, тебя то я и искал
Здравствуйте, но возник такой вопрос: зачем такие данные хранить в 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 - вы получите те же проблемы решения.
Отличный видос! Действительно обязательная тема для миддл+/синьор бэкендеров.
Nit: Кажется в видео было упущено сохранение обновленных значений retryTime для тех retryableTasks которые мы все же не смогли обработать. Не сильно шарю в джаве, но кажется если обновленные значения закинуть в цикле через сеттер, то в бд они не отразятся. Наверное надо было просто добавить метод в репо, который бы обновил те записи, у которых статус не изменился на success.
Откуда ты все это знаешь
Подскажите, очень надо.
Java не учил ещё, знаю только python.
Часто нужно получить apk.
Декомпилировать.
И собственно реверс и поиск как значений, так и методы формирования значений для запросов приложения, которые отснифаны ранее.
Либо снятие защиты от снифа или от запуска на эмуляторе андроида , снова упаковка в apk и запуск.
Реверс инженеринг.
Как?
Где?
Чем?
Каким образом?
В общем, сервисы, ресурсы, где можно учить, изучать, использовать, для решения подобных задач.
Java выучу, клянусь и ещё 4-5 языков, чуть позже, сейчас другое важное учу и решаю.
Подскажи, очень нужно дельный совет.
Заранее спасибо.
Целую в щёчки, жму сосочки.
Герои не носят плащи
Здесь после каждого слова склейка видео? 😸 Теперь я знаю способ делать из женщин разрабов 😹😹
Просто она через каждое слово матерится, заводская привычка, пришлось вырезать
Я все равно не уловил фишку. Почему не послать просто в очередь? Зачем это все? И это как по мне не решает проблему, а переносить в другое место. Планировщик так же будет блокировать таблицу на добавление новых записей. Собственно, поэтому никто не знает ответ на собесах - слишком это кривое, неэлегантное решение.
Какие новые записи создаёт планировщик и что блокирует?
В виде не сказано про idempotent Id в каждом запросе от планировщика к другому сервису. Этот id помогает слать один запрос много раз. А после успешной отправки запроса или ответа 409/406 (и т.д.) открыть транзакцию и обновить bool поле "отправлено"
чудовищно растянутая логика в части базы данных
Я больше не слушаю Асмр )
Я не понял, а чем собственно rest запрос на другой микросервис, который может быть "долгим" отличается от той же самой записи в базу данных, которая тоже может быть долгой. Это два внешних сервиса, никто не гарантирует что в какой-то из них запрос будет идти дольше/быстрее
И даже если мы запишем запрос с json в базу чтобы потом когда то там куда то там его отправить - мы все ещё не гарантируем что он дойдет до нужного сервиса. Даже не гарантируем когда он дойдет до сервиса. Просто поменяли шило на мыло.
Также потенциально таблица с заданиями отправить запросы может невероятно разрастись. Добавляется ещё одна потенциальная точка отказа
Вопрос правильный, ответ такой: базу выбираете вы сами и рассчитываете под свои потребности и можете подкрутить, если что. Другой же микросервис вы не контролируете, ну по крайней мере будем так считать. Ну и вот.
Тем что в первом случае у тебя вся транзакция отвалится по таймауту. Второй вариант позволяет тебе сохранить транзакционность доставки не имея проблем с таймаутом и тем что транзакция занята ожиданием ответа от другого сервиса. Конечно transactional outbox не под все задачи подходит. Но на видео разобрали очень популярный юзкейс. Если тебе нужная транзакционность между сервисами, посмотри в сторону 2PC и связанные паттерны. Вижу что в комментах люди пытаются натянуть сову на глобус.
@@paxpax1707 извините конечно но каким боком сохранение в базу и бесконечные ретраи обеспечивают транзакционность? Запрос спокойно себе может никогда не осуществится. Это полный бред
Ну почему java 😭😭😭😭😭
Устал слушать воду на 4й минуте. Пошел в гугл и прочитал за 3 минуты, что представляет из себя данный паттерн. Зачем эти 40 минут? Краткость - сестра таланта! В общем, только вводную часть можно было сократить до 30 секунд. Дальше не знаю. Обсасывать простейший паттерн 40 минут, это сильно.
Там ещё код такой и в целом "архитектура".
Спасибо, сэкономил время
Ну вам такой стиль не подходит значит . Кому то наоборот чем детальнее и подробнее тем лучше, все люди разные🤷♂️
Описание проблемы неверное, она не понимает о чем говорит.
Так опиши конкретно, что не правильно
Как минимум во вступлении отсутствует информация что мы что-то сохраняем в базу данных, это смешно просто слушать, что сообщение может потеряться в Кафке, а из тмб оно не может потом потеряться в Кафке, дилетантство, прочитали пару статей в интернете и давай клепать ролики для хомяков
Проблема в необходимости писать в больше чем один сервис, с этого надо начинать, у вас каша полная, вы не понимаете ничего в этом и не умеете выражать свои мысли последовательно
Катя, иди борщ варить.
А я реально очень вкусный кубанский борщ готовить умею, видимо нужен кукинг стрим
@@JAVAGYMRAT 💋
Кстати, что у тебя за ноут, MagicBook16?
Дыа
такая ты малышка умная