Как стать автором
Обновить

Комментарии 11

Решение без блокировок / ретраев и тюнинга изоляции

Пока читал до этого раздела, думал о том, нафига вообще все это нужно (транзакции, блокировки и т.д.). Ощущение было, что сами себе придумали трудности и сами героически их решили. В kafka ключи и группы потребителей не просто так придумали, они ровно для этого.

Понятно, что статья прежде всего обучающая, но, возможно, стоит сразу написать про этот способ. Горячие головы, не дочитав, могут погибнуть в неравном бою с блокировками.

Тоже шел писать про это. Самой проблемы в целом не существует, если знать об этой особенности Кафки. Особенно, если учесть, что это базовые знания для Кафки.

Но в целом да. Многие не умеют пользоваться Propagation и Isolation level-ами должным образом

Доклад и статья, как вы верно заметили, посвещены в первую очередь учебным целям и повышению уровня осведомленности, о том что такие инструменты существуют.

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

Я что-то не понял, или проблему с лайками можно было починить просто написав вызов sql запроса навроде

UPDATE speakers SET likes = likes + <сколько_добавить> WHERE id = <кому>

?

Это старая тема для отдельного доклада, поставил лайк). Здесь результат будет зависеть от уровня изоляции транзакций, с рисками поймать dead lock при конкурентных апдейтах одной и той же строки. Подробнее, например, тут https://blog.pjam.me/posts/atomic-operations-in-sql/ .

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

В данном случае и пессимистическая блокировка на уровне строки (SELECT ... FOR UPDATE) не всегда помогает, если нужно обновлять несколько строк в одной транзакции. Нужно чётко следить за порядком строк, чтоб не нарваться на deadlock.

Надёжнее вынести код в хранимую процедуру PL/pgSQL и использовать блокировку критической секции кода при помощи pg_advisory_xact_lock() и т.п. Это как synchronized только в Postgres. В итоге имеем простейшую хранимку в пару строчек и транзакционную @Procedure в Repository спринга.

А что на счет application (advisory) lock в бд?

И на сколько часто случается, что по одному клиенту приходит столько сообщений, что происходит гонка?

Спасибо за статью. С точки зрения рассмотрения нюансов решения проблем в конкурентной обработки и использования транзакций - отлично, но с точки зрения проблемы вопрос: почему не рассматривали что-то а-ля CQRS или labmda подхода?

Есть сильно более простой вариант, что-то типа

update post set likes=likes+:rq_likes

, а ORM идет зад, т.к. делает дырявые абстракции

Напомнило : Если вы хотите приготовить яблочный пирог с нуля, сначала вы должны создать вселенную

А посоветуйте пожалуйста что почитать на тему правильного использования docker-compose в IDEA. В первую очередь интересует где и как все его файлы хранить, чтобы конфиги сервисов в контейнерах попадали в git, а вот файлы с данными (те же БД постгреса) нет. Ну и как все это настроить чтобы оно автоматом пересобирало контейнеры при изменении приложения. А то все ручками приходится делать по незнанию :-(

Зарегистрируйтесь на Хабре, чтобы оставить комментарий