но ведь если нет изоляции между транзакциями, то баланс может измениться уже после проверки, ведь так? Предположу, что эти случаи как-то детектируются (поправьте меня) и происходит что-то вроде ошибки «оптимистик лока», либо же это обнаруживается тем чекером который спустя 12 часов обнаружит что транзакция прошла некорректно, но вот юзер уже это купил
Да, сагу строим с помощью оптимистичных локов
я пытаюсь понять — в чем отличие от NoSql субд, которые тоже не консистентны и не предоставляют ACID. Можете прокомментировать?
NOSQL субд разные есть — в том числе с ACID :) И части саги (шаги) у нас реализованы в том числе и на NOSQL. Отличие в том, что это архитектурный паттерн, который мы реализовали для бизнес транзакций между микросервисами, написанными на разных языках и с разными хранилищами. А кому-то этот паттерн может понадобится в рамках 1 сервиса и 1 СУБД, как в первоисточнике ftp.cs.princeton.edu/reports/1987/070.pdf (у нас такая потребность тоже была и мы ее реализовали с помощью PgQ и defproc)
ну Сага тоже вроде не такая уж простая
Речь идет о проблемах, связанных с монолитной архитектурой. Многие проекты живут с монолитной архитектурой, не испытывая сложностей и не планируют перехода на микросервисную архитектуру, например.
На какую нагрузку рассчитан движок PGSaga? Сколько «шагов» в секунду на сервер?
тут есть несколько блоков
— api масштабируется линейно
— executor
— хранилище
— и др
В нашей текущей реализации на 1 инстансе хранилища мы выполняем ~ 3000 шагов в секунду, можно больше в несколько раз, но мы оставляем запас на случай внезапного роста нагрузки.
Как определяется логика шага для executor — это просто какой-то RCP вызов или что-то сложнее?
1) если Сага не даёт гарантий атомарности и изоляции, то как быть с операциями которые чувствительны к изоляции? Скажем, юзер вполне может купить два товара за 50 $ при балансе в 20.
Проектирование саги ( начинать с резерва денег и проверки баланса в вашем примере)
2) чем это лучше чем NoSql базы (MongoDB или там Cassandra — не суть важно), которые тоже не дают этих гарантий, но с ними хоть мороки меньше — это слой абстракции, а для Саги нужно делать самодельный rollback.
Как я писал выше — если можно без саг — лучше без саги — все должно быть обосновано. На определенном этапе роста вы можете
— упереться в производительность 1 СУБД
— сложная логика и неочевидные зависимости монолита будут очень сильно замедлять доставку изменений в продакшн
Он отличается тем, что вы, например, стресс-тестируете «целевые» сервисы, а не сервис саг, на который как раз в вашей реализации и приходится большая наргрузка
Сервис саг покрыт тестами. Емкость и NFR известны
Database per service
Так вот как раз у сервисов многих хранилище работет в режиме асинхронной репликации
Кроме того, кто запрещает всем компонентам использовать одну БД?
Антипаттерн
У вас сервис саг должен обновляться при изменении контракта, например, сервиса Биллинга?
Создается новый класс саг — который использует новый контракт ( я писал про это выше)
Один и тот же инстанс сервиса саг может использоваться другими с другими сагами?
Не ясно тогда, чем этот компонент от сервиса саг отличается?
Второй момент у каждого сервиса появляется +1 хранилище.
На мой взгляд — выглядит ещё сложнее
В нашей реализации — одно из требований соблюсти 100% консистентность. Гарантию сохранности состояния обеспечивает сервис саг с синхронной репликацией (для исключения потери данных). А у сервиса инициатора саги может быть хранилище, которое способно терять данные при аварии.
GENERATED { ALWAYS | BY DEFAULT } AS IDENTITY [ ( sequence_options ) ]
This clause creates the column as an identity column. It will have an implicit sequence attached to it and the column in new rows will automatically have values from the sequence assigned to it.
The clauses ALWAYS and BY DEFAULT determine how the sequence value is given precedence over a user-specified value in an INSERT statement. If ALWAYS is specified, a user-specified value is only accepted if the INSERT statement specifies OVERRIDING SYSTEM VALUE. If BY DEFAULT is specified, then the user-specified value takes precedence. See INSERT for details. (In the COPY command, user-specified values are always used regardless of this setting.)
The optional sequence_options clause can be used to override the options of the sequence. See CREATE SEQUENCE for details.
blogs.microsoft.com/blog/2019/01/24/microsoft-acquires-citus-data-re-affirming-its-commitment-to-open-source-and-accelerating-azure-postgresql-performance-and-scale/?fbclid=IwAR0kMXMioMqZiSecsW1_dbPNWlAw0BRZXVdMv_iT7QBdhavltVEWGTpNH8k
http://amp.gs/eZ07 размышления на тему монолитных приложений
Речь идет о проблемах, связанных с монолитной архитектурой. Многие проекты живут с монолитной архитектурой, не испытывая сложностей и не планируют перехода на микросервисную архитектуру, например.
— api масштабируется линейно
— executor
— хранилище
— и др
В нашей текущей реализации на 1 инстансе хранилища мы выполняем ~ 3000 шагов в секунду, можно больше в несколько раз, но мы оставляем запас на случай внезапного роста нагрузки.
Просто вызов API
Как я писал выше — если можно без саг — лучше без саги — все должно быть обосновано. На определенном этапе роста вы можете
— упереться в производительность 1 СУБД
— сложная логика и неочевидные зависимости монолита будут очень сильно замедлять доставку изменений в продакшн
Так вот как раз у сервисов многих хранилище работет в режиме асинхронной репликации Антипаттерн
Создается новый класс саг — который использует новый контракт ( я писал про это выше)
да
Отличная презентация!
Не ясно тогда, чем этот компонент от сервиса саг отличается?
Второй момент у каждого сервиса появляется +1 хранилище.
На мой взгляд — выглядит ещё сложнее