Size: a a a

Архитектура данных

2020 February 06

DT

Denis Troyan in Архитектура данных
Разумеется, для гарантий флинк нужно переключать в режим микробатчинга, и заботиться об очереди этих батчей самостоятельно
источник

Z

Zhenya in Архитектура данных
флинк он все же про доставку, сквозной платеж на нем писать на интерцепторах что ли ? те еще приседания ..
источник

DT

Denis Troyan in Архитектура данных
Zhenya
флинк он все же про доставку, сквозной платеж на нем писать на интерцепторах что ли ? те еще приседания ..
Да, это плохо прям! Но я чисто про гарантии доставки сейчас:)
источник

Z

Zhenya in Архитектура данных
хотите гарантий - придумали транзакции, будете юзать велосипеды, будете огребать )
источник

PD

Phil Delgyado in Архитектура данных
Denis Troyan
Почему нет? Стейт сохраняется на диск только если транзакция применилась
Хм. Вот у меня нужно принять одно сообщение и положить его в две разные очереди.
Как Флинк обеспечивает атомарность этой операции?
Т.е. что при любых сбоях или сообщение будет в обеих очередях либо ни в одной?
Хотя бы eventual?
источник

DT

Denis Troyan in Архитектура данных
А что делать, если в одну очередь написали, а вторая упала?
источник

DT

Denis Troyan in Архитектура данных
Это тогда очередь должна поддерживать транзакции, или вся система должна быть идемпотентной
источник

DT

Denis Troyan in Архитектура данных
Никогда не работал с очередями с поддержкой транзакций, честно говоря
источник

PD

Phil Delgyado in Архитектура данных
Denis Troyan
А что делать, если в одну очередь написали, а вторая упала?
Ну, пытаться писать во вторую какое-то время. Если не получилось - то послать событие отмены первого (по хитрой логике). Если отмена невозможна - то запустить еще какую-то бизнес-логику типа "нотификация оператору".
Примерно так.
Очереди, конечно, без поддержки транзакций. Но события идемпотентны (но это требование и так всегда есть, иначе распределенные системы не сделать)
источник

PD

Phil Delgyado in Архитектура данных
Проблема в том, что "текущее состояние выполнения транзакции" нужно хранить в каком-то персистансе, иначе ничего не гарантировано.
источник

DT

Denis Troyan in Архитектура данных
Ну, если под транзакцией подразумевается написать в n очередей, то можно хранить это в стейте флинка на уровне микробатча. Если флинк падает — перепосылать весь микробатч
источник

DT

Denis Troyan in Архитектура данных
А если какая-то распределённая кросс-системная транзакция, тогда можно стейт в аэроспайке или редисе хранить
источник

PD

Phil Delgyado in Архитектура данных
Меня интересует атомарность. Через повтор микробатчей, наверно, можно решить, но тогда кто-то должен орекстрировать повтор этого батча (с учетом требований по идемпотентности всего батча, что гораздо сложнее идемпотентности отдельных событий из батча на конкретные системы).
А для решения с редисом-аероспайком проще уже становится без флинка )
источник

PD

Phil Delgyado in Архитектура данных
Т.е. флинк - для других задач, не для сложных OLTP запросов со сложной оркестрациии.
Для ETL он должен быть хорош )
источник

DT

Denis Troyan in Архитектура данных
Полностью поддерживаю 🙂
источник

DT

Denis Troyan in Архитектура данных
Я с такими задачами не сталкивался, поэтому интересно было поразмышлять
источник

PD

Phil Delgyado in Архитектура данных
Ну, а у меня как раз все такое в жизни. Финтех...
источник

PD

Phil Delgyado in Архитектура данных
Но тоже с хорошим универсальным решением из коробки все сложно, приходится руками...
источник

DT

Denis Troyan in Архитектура данных
Где-то об этом пишете?
источник

PD

Phil Delgyado in Архитектура данных
Рассказывал на Highload, но еще про старый вариант просто на акторах поверх PG.
источник