Как блокировать строку в БД при чтении?

Question

[mitaichik]

Всем привет!

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

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

Как такого избежать?

Я вижу несколько решений, но все какие-то неказистые: юзать redis с его incr который содержит id следующего свободного промокода (они автоинкременты), можно сделать очередь с одним воркером на получение свободного промокода, можно вообще сделать отдельный fpm пул с единственным php-fpm процессом (это конечно садомазо) или ограничить очередь на запрос регистрации юзера в nginx.

Но наверняка же есть какой-то простой способ?

Заранее спасибо.

Answer 1

[Александр Аксентьев]

зачем их заранее генерировать вообще?

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

Если отбросить варианты из разряда promo_code_{user_id}

Ну или выбирать select for update чтобы лочилась строка
https://dev.mysql.com/doc/refman/5.7/en/innodb-loc...
но это вариант через жопу в целом как-то.

Comments

[mitaichik]

Промокоды мы не генерируем, нам их присылают пачками по требованию. Вариант с select for update звучит интересно, надо попробовать, спасибо.

Answer 2

[Максим Тимофеев]

Показывайте промокод юзеру, только после того, как он выдан. Или вообще генерируйте его при выдачи и записывайте в БД:

$secret = "some_secret_phrase";
$cod = md5($secret.Yii::$app->user->id);

Comments

[mitaichik]

Увы, в задаче забыл добавить что мы не генерируем промокоды, нам их присылают пачками по требованию...

[Максим Тимофеев]

mitaichik: Тогда я бы эти пачки складировал где-то (бд, файл и т.д.), а после регистрации выдавал пользователю 1 из них, при этом удаляя из склада и добавляя, как доп поле к таблице с пользователем или в отдельную таблицу.

[mitaichik]

Максим Тимофеев: ну как-то так примерно я и сделал, но при одновременной регистрации нескольких юзеров все равно возможны коллизии. Сейчас, конечно, мысль пришла вообще переписать это все на java (я все равно потихоньку переношу свой проект на Spring) - там подобные проблемы решаются одной строкой synchronized

[Максим Тимофеев]

все равно возможны коллизии

исключено. Если на поле с кодами стоит ключ unique и соответствующий валидатор в правилах.

[mitaichik]

Максим Тимофеев: Да, интересная мысль...

Answer 3

[SagePtr]

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

Answer 4

[Hatik]

Может подойдет триггер Before Update? в промокоде посмотреть наличие юзера, если есть то снова сделать селект и выдать другой промокод