#apache-kafka #kafka-consumer-api #apache-kafka-streams
#apache-kafka #kafka-consumer-api #apache-kafka-streams
Вопрос:
Пример использования: Учетная запись A отправляет 500 долларов на учетную запись B, мы используем одну тему: «учетная запись», имеющую несколько разделов для записи этих событий
Производитель -> 1. Транзакция начинается
2. Баланс счета A (-) 500 для учетной записи темы, раздел p0
3. Баланс счета B ( ) 500 для учетной записи темы, раздел p1
4. Транзакция завершается
на стороне потребителя у нас есть поток с одним потоком, который обрабатывает эти разделы и обновляет его глобальное хранилище состояний (глобальная таблица K) соответственно, потребители, использующие эти разделы, получают эти сообщения при другом опросе, и создается несогласованное состояние
1. Вычтите 500 из учетной записи A в глобальном хранилище состояний при каком-либо опросе 2. используйте некоторые нетрадиционные данные из других разделов 3. Добавьте 500 к учетной записи B в глобальном хранилище состояний — при другом опросе
Между этапами 1 и 3 мы имеем несогласованное состояние, при котором счет A списывается, но счет B не зачисляется
Как мы можем атомарно использовать транснациональные данные в приложении, используя низкоуровневый API Kafka Stream для обновления его хранилища глобального состояния (глобальная таблица K), чтобы избежать несогласованного состояния в любой момент времени.
Комментарии:
1. Это видео может помочь: youtube.com/watch?v=v2RJQELoM6Y
Ответ №1:
обновление записи в хранилище состояния за записью для транзакции может привести к несогласованному представлению на некоторое время, в то время как приложение для обновления хранилища состояния должно записывать всю транзакцию атомарно (пакетная фиксация). Используя потоковое приложение или потребителя, невозможно получить маркеры начала / окончания транзакции для выполнения пакетной фиксации. Используя simple consumer в режиме READ_COMMITTED, вы можете запросить конечные смещения (LSO) перед опросом, буферизовать все записи во временной карте, пока не нажмете конечные смещения (LSO), а затем записать временную карту в фактическое состояние -хранить атомарно (пакетная фиксация / сброс). Этот процесс гарантирует, что хранилище состояний является согласованным и в случае транзакции не будет частичных обновлений.