В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

Scala User Group

1789 membersпожаловаться на группу
2020 March 25

A

Alexey in Scala User Group
Vladimir Sam
если в процессе обработки и записи нового стейта стало ясно, что ктото записал конкурентно, пытаемся выполнить команду заново
сейчас так. обработка некоторых команд неидемпотентая, так что есть гемор с тем чтобы такие вещи как-то разруливать. иногда это совсем не просто и не очевидно.

так что в итоге хочется конкурентность убрать вообще, и все действия по сущности выполнять строго линейно.
источник
15:32пожаловаться#1

VS

Vladimir Sam in Scala User Group
трюк в том, чтобы не выполнять какие-то сайдэффекты "вне" сущности если команда не удалась

т.е. если результат успешный - пошли эффекты
если результат неуспешный - повтор команды
источник
15:35пожаловаться#2

VS

Vladimir Sam in Scala User Group
от того, что команды выстраиваются в очередь в кафке, базе или очереди актора принцип не меняется
источник
15:35пожаловаться#3

Y

Yevhen in Scala User Group
Юрий Бадальянц
Делай на кафке без акки
кафка ведь не решает все те проблемы что делает акка, ето обычная очередь
источник
15:35пожаловаться#4

λ

λoλdog in Scala User Group
а какие проблемы решает акка?
источник
15:37пожаловаться#5

Y

Yevhen in Scala User Group
с аккой как минимум можно выбросить зукипер
источник
15:38пожаловаться#6

λ

λoλdog in Scala User Group
что?
источник
15:38пожаловаться#7

λ

λoλdog in Scala User Group
а причем тут зукипер?
источник
15:38пожаловаться#8

ЮБ

Юрий Бадальянц in Scala User Group
Yevhen
кафка ведь не решает все те проблемы что делает акка, ето обычная очередь
На базе Кафки можно решить проблему, я только об этом. Она даёт нужные гарантии. Да, надо пописать код руками. Таков путь.
источник
15:43пожаловаться#9

GP

Grigory Pomadchin in Scala User Group
λoλdog
а причем тут зукипер?
¯\_(ツ)_/¯ ну знаешь эти кафки зукиперы
источник
15:44пожаловаться#10

ЮБ

Юрий Бадальянц in Scala User Group
Локи на базе тоже решение, чёуж. Правда под нагрузкой далеко не уедешь - плохо масштабируется. Но на практике есть куча задач, где постгри хватит за глаза.
источник
15:45пожаловаться#11

Oℕ

Oleg ℕizhnik in Scala User Group
да
источник
15:45пожаловаться#12

Oℕ

Oleg ℕizhnik in Scala User Group
лучше всего использовать микросервисную архитектуру, запускать 10 сервисов, по 10 нод каждый, каждый по 10 тредов, но разрешать одновременно выполняться только одной операции на одной машине из одного треда
источник
15:46пожаловаться#13

Oℕ

Oleg ℕizhnik in Scala User Group
ditstributed GIL
источник
15:47пожаловаться#14

Oℕ

Oleg ℕizhnik in Scala User Group
а пока всё это работает можно заняться оптимизицией аллокаций
источник
15:47пожаловаться#15

Y

Yevhen in Scala User Group
λoλdog
а причем тут зукипер?
ты просто актера поднимешь вместо зукипера
источник
15:52пожаловаться#16

ЮБ

Юрий Бадальянц in Scala User Group
Олег, ну если там нагрузки мало, и лок происходит редко, то почему бы и нет? Если уже есть пг, например. Конечно, я бы лучше на кафке сделал, и скорее всего это даже проще бы вышло, но вариант с базой тоже рабочий
источник
15:53пожаловаться#17

ЮБ

Юрий Бадальянц in Scala User Group
"прагматичный"
источник
15:53пожаловаться#18

Oℕ

Oleg ℕizhnik in Scala User Group
Если нагрузки мало и лок происходит редко можно использовать оптимистичную блокировку
источник
15:54пожаловаться#19

ЮБ

Юрий Бадальянц in Scala User Group
Ну так об этом и речь
источник
15:54пожаловаться#20