стопэ

вы какую задачу решаете?

Состояние гонки между горутинами и внешней бб

Бд

эм, может быть имеется введу гонка на уровне бд?

например есть баланс вы его выбираете и тут-же обновляете в следующем запросе

если вы делаете это в двух гоурутинах то получится фигня

но это состояние "гонки" уже внутри бд решается

транзакциями

эм, может быть имеется введу гонка на уровне бд?

Гонка между горутин

в чем она заключается то?

В том что пока совершается неблокируемый вызов бд, одна горутина засыпает и просыпается другая. Если другая горутина аналогична первой она сделает тот же запрос, затем просыпается первая горутина и прибавляет деньги и ставит пометку об оплате, просыпается вторая и делает то де самое так как результат соответствовал первому запросу и тоже приьавляет деньги

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

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

Это пример

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

Есть два варианта, в зависимости от того, как устроено приложение и может ли у вас БД быть хранилищем логики: 1. Делаете бизнес-операцию атомарной на уровне приложения, например, обрабатывая все запросы на эту операцию через каналы 2. Делаете эту бизнес-оперцию на уровне БД, используя транзакции (стоит вниматально выбрать уровень изоляции), например, в хранимке

А я думал про мьютексы

что бы давать советы, надо понимать бизнес задачу

я просто нюхом чую что там что-то не так с логикой

Например приходит запрос на пополнение, мы юзера заносим в мьютекс и другие пополнения этого юзера ждут

А других юзеров выполняются асинхронно

То есть синхронное выполнение в рамках одного юзера

Например приходит запрос на пополнение, мы юзера заносим в мьютекс и другие пополнения этого юзера ждут

вы случаем на http хадлерах обрабатываете некую логику?

Замучаетесь это мютексами регулировать.

и нам это скармливаете как "несколько гоурутин"

вы случаем на http хадлерах обрабатываете некую логику?

Вебсокет

уже ближе

а вебсокет на стандартной либе?

и нам это скармливаете как "несколько гоурутин"

А что не так?

Просто обычный тсп сокет. Каждый пакет от юзера обрабатывается в горутине

я как понял так, вы слушаеет вебсокет и от клиента приходит несколько пакетов

причем там есть дубли

так?

Отправляем подряд несколько пакетов на пополнение и получаем гонку

Как выше описал

вам как надо?

А какая ДБ?

что бы несколько пакетов обработали корректно или проигнорировать "дубли" пакетов?

А какая ДБ?

да там не в бд дело

что бы несколько пакетов обработали корректно или проигнорировать "дубли" пакетов?

Дада дубли для одного юзера

Семафоры мб?

да стойте

какие семафоры

если у вас клиент ДУБЛИРУЕТ пакеты

Ну тут, либо все перации на изменение ставить в поток, чтобы не было несогласованности, либо на уровне бызы изолировать.

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

Лол ну трабла не в дублях. Я могу сформировать второй и третий пакет на другие суммы

И они пройдут проверку

Трабла в гонке

заверните в транзакцию

в чем тогда проблема?

Трабла в гонке

Тут не то что гонка, это несогласованность. Какая дб?

Транзакции на уровне бд происходят. Mysql. А проверка проходит в гоу

Как вариант это перенести в хранимки

какая проверка то?

А на стороне гоу можно что-то придумать

у вас: Открыл транзакцию select insert Закрыл транзакцию

коммит

в зависимости от уровня изоляции это будет работать по разному

у вас: Открыл транзакцию select insert Закрыл транзакцию

То же самое) вторая горуттна открыла транз и закомитила

еще может помочь select for update

При коммите нет проверки на легетимность

А на стороне гоу можно что-то придумать

Либо польностью на стороне клиента базы обеспечивайте согласованность, либо в самой базе.

Да я знаю транзакции)

Они тут не помогут

Выше уже отписал

Либо в хранимки переводить

Либо какие-то хитрые мьютексы пилить

Или семафоры

Для конкретного действия юзера

Чтобы одновременно не происходило 2 действия

ну тогда воспользуйтесь select for update

если хотите сделать средствами бд

сначала считаете, потом обновите

Про изоляцию в MySQL https://dev.mysql.com/doc/refman/8.0/en/innodb-transaction-isolation-levels.html

Да я знаю транзакции)

прочитайте про уровень изоляции

прочитайте про уровень изоляции

Предлагаете на уровне бд лочить рид?

одну запись

Хм, ну тоже как вариант

но вообще при работе с балансом в банке так и не делают никогда

но вообще при работе с балансом в банке так и не делают никогда

А как делают?

делают табличку с транзакциями на insert, и баланс выводят на основе суммы по колонке

никаких update

А ну я понял, транзакции в нормализованном виде, баланс в денормализованном

каждое списание/пополнение - отдельная транзакция

Платежные транзакции*

таким образом легко поправить с любого места

даже если кто-то списал 1 миллион долларов

мы просто анулируем 1 транзакцию и все

Хотя должна только одна)

Тут Александр опятьразвёл какое то страшное ужасное словоблудие ни о чём. В чём конкретно проблема ваша проявилась?

В том что пока совершается неблокируемый вызов бд, одна горутина засыпает и просыпается другая. Если другая горутина аналогична первой она сделает тот же запрос, затем просыпается первая горутина и прибавляет деньги и ставит пометку об оплате, просыпается вторая и делает то де самое так как результат соответствовал первому запросу и тоже приьавляет деньги

Гонка с бд между горутинами

Но уже есть варианты решения с бд

Вам про уровни изоляции выше написали правильно, кажется.

Ну да. Как вариант. Я думал что можно как-то в гоу решить

Но с бд тоже норм

Ну да. Как вариант. Я думал что можно как-то в гоу решить

https://habr.com/post/317884/

вот тут посмотрите