Size: a a a

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

2020 February 06

PD

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

DT

Denis Troyan in Архитектура данных
Например?
источник

PD

Phil Delgyado in Архитектура данных
Ну, например, сквозной платеж )
источник

PD

Phil Delgyado in Архитектура данных
Или какой-нибудь хитрый онбординг.
источник

DT

Denis Troyan in Архитектура данных
А можно поконкретнее?:)
источник

PD

Phil Delgyado in Архитектура данных
Т.е. каждый сценарий - это сложная стейт-машинка (ну или актор) с гарантиями на сообщения другим акторам и гарантиями сохранения состояния.
источник

DT

Denis Troyan in Архитектура данных
Ах, ну да. У Флинка нет обратной связи по сообщениям. Нет гарантии получения. Написал в очередь — и всё. Кто-нибудь прочитает. А может и не прочитает
источник

PD

Phil Delgyado in Архитектура данных
Denis Troyan
А можно поконкретнее?:)
Процесс сквозного платежа - это где-то 10-15 шагов (иногда больше) - с циклами, условиями и т.п. При этом при любом падении чего угодно нужно оставаться в консистентном состоянии.
источник

PD

Phil Delgyado in Архитектура данных
Denis Troyan
Ах, ну да. У Флинка нет обратной связи по сообщениям. Нет гарантии получения. Написал в очередь — и всё. Кто-нибудь прочитает. А может и не прочитает
Ну, тогда придется делать очередь между флинком и всеми получателями, а это может быть долго (и точно дорого).
источник

PD

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

PD

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

DT

Denis Troyan in Архитектура данных
Phil Delgyado
Ну и там вроде-бы inmemory state, т.е. если сам сценарий "получил сообщение, отправил в три разных точки" умрет вместе с сервисом - то может быть неконсистентность.
Ну да. Распределённого стейта нет. Но джоб умеет падать с сохранением стейта, и связывать транзакции с сохранением стейта.
источник

PD

Phil Delgyado in Архитектура данных
А где он этот стейт хранит?
источник

PD

Phil Delgyado in Архитектура данных
С какой гарантией,
источник

DT

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

DT

Denis Troyan in Архитектура данных
Phil Delgyado
А где он этот стейт хранит?
Сначала в памяти, потом на диске
источник

PD

Phil Delgyado in Архитектура данных
Ну, интересно гарантировать, что транзакция таки применилась. Этого там нет, как я понимаю. Если упал сервер - то опаньки.
источник

DT

Denis Troyan in Архитектура данных
Почему нет? Стейт сохраняется на диск только если транзакция применилась
источник

DT

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

DT

Denis Troyan in Архитектура данных
Ну, и офсеты Кафки можно хранить как в Кафке, так и во флинке для большей гарантии.
источник