DT
Разумеется, для гарантий флинк нужно переключать в режим микробатчинга, и заботиться об очереди этих батчей самостоятельно
Size: a a a
2020 February 06
Z
флинк он все же про доставку, сквозной платеж на нем писать на интерцепторах что ли ? те еще приседания ..
DT
Zhenya
флинк он все же про доставку, сквозной платеж на нем писать на интерцепторах что ли ? те еще приседания ..
Да, это плохо прям! Но я чисто про гарантии доставки сейчас:)
Z
хотите гарантий - придумали транзакции, будете юзать велосипеды, будете огребать )
PD
Почему нет? Стейт сохраняется на диск только если транзакция применилась
Хм. Вот у меня нужно принять одно сообщение и положить его в две разные очереди.
Как Флинк обеспечивает атомарность этой операции?
Т.е. что при любых сбоях или сообщение будет в обеих очередях либо ни в одной?
Хотя бы eventual?
Как Флинк обеспечивает атомарность этой операции?
Т.е. что при любых сбоях или сообщение будет в обеих очередях либо ни в одной?
Хотя бы eventual?
DT
А что делать, если в одну очередь написали, а вторая упала?
DT
Это тогда очередь должна поддерживать транзакции, или вся система должна быть идемпотентной
DT
Никогда не работал с очередями с поддержкой транзакций, честно говоря
PD
А что делать, если в одну очередь написали, а вторая упала?
Ну, пытаться писать во вторую какое-то время. Если не получилось - то послать событие отмены первого (по хитрой логике). Если отмена невозможна - то запустить еще какую-то бизнес-логику типа "нотификация оператору".
Примерно так.
Очереди, конечно, без поддержки транзакций. Но события идемпотентны (но это требование и так всегда есть, иначе распределенные системы не сделать)
Примерно так.
Очереди, конечно, без поддержки транзакций. Но события идемпотентны (но это требование и так всегда есть, иначе распределенные системы не сделать)
PD
Проблема в том, что "текущее состояние выполнения транзакции" нужно хранить в каком-то персистансе, иначе ничего не гарантировано.
DT
Ну, если под транзакцией подразумевается написать в n очередей, то можно хранить это в стейте флинка на уровне микробатча. Если флинк падает — перепосылать весь микробатч
DT
А если какая-то распределённая кросс-системная транзакция, тогда можно стейт в аэроспайке или редисе хранить
PD
Меня интересует атомарность. Через повтор микробатчей, наверно, можно решить, но тогда кто-то должен орекстрировать повтор этого батча (с учетом требований по идемпотентности всего батча, что гораздо сложнее идемпотентности отдельных событий из батча на конкретные системы).
А для решения с редисом-аероспайком проще уже становится без флинка )
А для решения с редисом-аероспайком проще уже становится без флинка )
PD
Т.е. флинк - для других задач, не для сложных OLTP запросов со сложной оркестрациии.
Для ETL он должен быть хорош )
Для ETL он должен быть хорош )
DT
Полностью поддерживаю 🙂
DT
Я с такими задачами не сталкивался, поэтому интересно было поразмышлять
PD
Ну, а у меня как раз все такое в жизни. Финтех...
PD
Но тоже с хорошим универсальным решением из коробки все сложно, приходится руками...
DT
Где-то об этом пишете?
PD
Рассказывал на Highload, но еще про старый вариант просто на акторах поверх PG.