daminik00, да
тебе важно понять, что транзакция это блок, в котором будет выполнено или "всё успешно" или "всё откатили"
то есть если ты внутри транзакции изменил один документ, второй, пятый и так далее, но потом сделал abortTransaction по какой-то причине (условие баланса не подошло), то все документы откатятся, очень грубо говоря транзакции выполняются друг за другом (но это немного не так, читать про causal consistency)
daminik00, нет, я же пишу, что транзакционно, как они одновременно начнут?
10 запросов на начало прилетает на сервер, транзакционно: транзакция началась
1) выбрали задание
2) выбрали исполнителя
3) списали деньги если есть на счету
4) зачислили на вирт счет транзакция закончилась
таким образом транзакция выполнится успешно только для одного исполнителя, для других она упадет на шаге 3
сделать 2 фазы у задания: начать выполнение, закончить выполнение
на фазе 1 - "начать выполнение" деньги замораживаются и списываются на виртуальный счет, это происходит транзакционно, таким образом начать сможет только один из исполнителей, остальные получат ошибку, что задание уже в процессе
на фазе 2 - "закончить выполнение" деньги или переходит исполнителю или отзываются
в случае провала задания или таймаута
названия фаз можно поменять: "начать просмотр задания", "выполнить задание". Сути это не меняет
а как транзакционно делается запись в БД и взаимодействие с 3ми АПИ (например апи платежек)? интересует кейс, когда где-то что-то зафейлилось как это откатить?
а что если при открытии каждого файла возвращать канал, в который пишутся операции над файлом, в которые этот файл прокидывается?
операции исполняются одна за другой синхронно
Губернатор, проблема в том, что это кажется только тебе. Покорение высот происходит командами. В большинстве своем этот язык неудобен: плохой пример ООП, легкость выстрелить себе в ногу. Он проверен временем и занял свою нишу. Для веба много других удобных и шустрых инструментов
Сергей, с RPC пока не укладывается в голове как реализовать, сервер не хранит ответ (а только состояние игрока и комнаты).
Это игра: клиент сделал запрос, {списалась сумма, посчиталось текущее текущее состояние и сгенерировался ответ}(транзакционно), отправилось игровое состояние.
Если уходить в RPC, то придётся и на сервере реализовывать логику повторного запроса (но без списания суммы, иначе двойная ставка спишется) и клиент меня. По этой причине (как одной из) несколько лет назад первая версия с RPC была заменена на однонаправленный поток данных сервер-клиент
Евгений Самсонов, классный видос, спасибо, теперь смотрю в сторону "отказаться от рэбита" и заменить на редис. Мной, кстати, задавался вопрос про Centrifugo в телеге и Саша ответил, что невозможно дисконнекты отлавливать, - это сразу заставляет писать используя либу Centrifuge =/
идентификатор сервиса (экземпляра), к которому он подключен
возможен такой кейс: команда отправлена в брокер, сервис_1 умер или перезапускается, пользователь отвалился и переподключился уже к новому (поскольку был disconnect на веб-клиенте), бизнес-логика произвела действия и положила данные в очередь. данные не будут вычитаны нужным экземпляром по его идентификатору
Сергей,
- пользователь может отключаться по своей воле, тогда при этом событии данные из очереди очищаются и сервисы websocket отписываются
- пользователь может отключаться временно (на короткий срок, разрывы по причине перезагрузки nginx(edge), плохая связь)
- пользователь подключается к случайному websocket сервису (hash балансировку не планируется), то есть даже в момент разрыва он может переподключиться к уже другой ноде
- сохранность данных-некритичный показатель, поскольку все действия - результат бизнес-логики и операций с базой данных (то есть на каждую команду данные уже в базе), восстановление состояния при долгом разрыве происходит через сервис бизнес-логики и считывание из базы данных