ThunderCat, спасибо большое за развернутый ответ. Очень помогли с наводкой и расшевелить мозг. Пожалуй так и сделаю, таблицу с очередью. А баланс будет списываться уже непосредственно при записи в эту очередь.
ThunderCat, дело в том, что у пользователя списываются баллы и он получает покупку за баллы, поэтому это должна быть неделимая операция. А из-за того что СУБД отваливается от нагрузки, операция может сохраниться не полностью. Поэтому и делал этот костыль здесь.
10 из 10 за написание текста. Вундервафля не является секретным орудием массового поражения. Не описывал ее, так как не хотел чтобы это выглядело из оперы "сделайте за меня". Если сама суть, то это что-то вроде сетевого маркетинга в интернете. Когда наступает 19:00 как в примере, то все жмакают на кнопку, чтобы оказаться как можно выше по структуре. В момент этой "активации" когда человек занимает место, вышестоящему переводятся баллы(ага, баллы, точно точно).
Транзакции здесь вопхнул, чтобы это все была одна неделимая операция, так как если спишутся баллы и не активируется тариф, то будет неправильно и наоборот.
Суть задачи заключается в том, чтобы под одним человеком не могло быть больше N человек(на картинке 3) И тот скрипт который выполняется 0.1-0.6 секунд бегает каждый раз по структуре и ищет куда встать следующему, после того как нашел, начинает делать переводы. (но это уже лишняя информация, так для полного понимания).
Антон Антон, слушай, а скажи, допустим если в одном запросе 10 записей в базу, это считается как один запрос или 10? Просто тогда их может быть вообще не 2к, а больше
Кстати очень крутая идея. Пусть будет не так моментально, но стоит подумать об этом. По сути те же queues получаются.
Как думаешь, если писать туда micro_time() есть вероятность совпадений? Хотя, даже если они будут, мы же перебираем по порядку. Попробую додумать. Благодарю вас за наводку.
Пробовал локи, но mysql выдает ошибку mysql что таблица залочена, попробуйте снова, может он и стоит в очереди но до определенного момента. Может в таймауте дело.
Очередь имеются ввиду Queues? Думаете они будут уместны здесь? Просто я натыкался на них и решения в них не нашел. Попробую еще почитать по внимательнее.
От себя еще добавлю к этому решению, чтобы было полноценное
$users = User::whereDoesntHave('phones', function (Builder $query) {
$query->where('model', 'Nokia');
})->where('money', '>=', 100)
->get();
// в User
public function phones()
{
return $this->hasMany('App\Models\Phone');
}
3@jazzus, Я привел просто пример, у Васи было 5 яблок, 3 груши отдал Пете. Просто на примере реального проекта это показалось бы запутанным.
Если описать ее в двух словах, то мне нужно получить список пользователей, которые не купили тариф под определенным номером.
Как же я не отличил транзакции sql от фактических. Гениально, спасибо за совет. Больше не надо.
Сами бы осведомились в вопросе, перед глумлением, а то вдвойне получается.
Был баг, то что пользователь если одновременно жмет вывод с двух устройств, то выводилось две суммы а списывалась одна. И погуглив везде утверждалось что для этих случаев придуманы транзакции. Это не так? Или я чего-то не понимаю