slava-a Dec 6 2021 at 13:58

SAGA на golang

9 min

12K

Karuna corporate blogProgramming*Go*Microservices*

Comments 15

crocodile2u Dec 6 2021 at 14:19

INSERT INTO statuses (id, name) VALUES (1, 'PENDING'), (2, 'CREATED');

Для двух статусов табличка, конечно, совершенно необходима.

KislyFan Dec 7 2021 at 19:04

Почему нет? C точки зрения поддержки целостности тут есть только одна альтернатива, это postgresql enums. Но это ни разу не серебрянная пуля, особенно если список значений надо будет расширять..

crocodile2u Dec 7 2021 at 19:34

Я за ENUM. Нагляднее, проще, на один JOIN меньше.
Но я придрался скорее к тому, что такая табличка используется в примере, который не должен отвлекать от главного.

host13 Dec 6 2021 at 14:25

Что делать, если не удалось выполнить компенсирующую транзакцию?

alexg-nn Dec 6 2021 at 14:44

Великая тайна сия есть. Но вообще компенсирующая операция должна быть идемпотентной, так что её можно повторять до упора, пока не получится хоть что-то в ответ получить.

marshinov Dec 6 2021 at 15:33

угу и за DDOS-ить себя этим "повторным выполнением". @host13 Вам вот [типа этого](https://getakka.net/articles/concepts/supervision.html) надо. В оригинальной Akka тоже эти концепты есть, но в .NET с картинками.

alexg-nn Dec 6 2021 at 15:51

В общем случае там логика, конечно, сложнее простого retry. Вот тут интересно про это написано https://habr.com/ru/company/oleg-bunin/blog/418235/

marshinov Dec 6 2021 at 15:54

Нормально так сложнее. В целом, saga работает примерно так, как работают распределенные транзакции, т.е. в общем случае не работает.

slava-a Dec 6 2021 at 14:48

Как вариант, сохранять в бд «неудачу». Демоном уже обрабатывать отдельно неудавшиейся компенсирующие транзакции

PrinceKorwin Dec 6 2021 at 15:47

Это только половина дела. Нужно уметь пока они наказываются как-то ведь фильтровать данные которые "на половину" верны.

Так называемое грязное чтение избежать.

slava-a Dec 6 2021 at 15:59

Один из вариантов решения такой проблемы как раз в описанном примере. А именно статусы, по которым можно осуществлять фильтрацию

OlegStrekalovsky Dec 6 2021 at 18:58

В ваших примерах обработчик CreateOrderV1 и обработчик события order_created_v1 совершенно не готовы к повторам операций, которые кажется должны случиться когда вы закроете транзакцию, но не сможете отправить сообщение: в базе будут задваиваться и заказы и товары.

slava-a Dec 6 2021 at 19:04

да, вы правы, много чего нет т.к пример чисто концептуальный

со всеми деталями он бы был раза 3 больше

OlegStrekalovsky Dec 6 2021 at 19:29

Можете хотя бы словами описать как вы эти проблемы решали? Это достаточно важные детали, чтобы даже этот более простой пример саги, когда можно положиться на надёжный транспорт сообщений, стал более похож на то, что можно реально использовать.

slava-a Dec 7 2021 at 11:39

1) использовать паттерн дроссельная заслонка (throttle), чтобы избежать одинаковых запросов в единицу времени
2) формировать ключ идемпотентности (включить в него ip и метку времени, например) для каждого запроса. проверяя его, можно отсеить лишние запросы