Несогласованное состояние в дебет счета - Кредитное приложение с использованием транзакции Kafka

Question

Вариант использования: учетная запись A отправляет 500 баксов на учетную запись B, мы используем одну тему: «учетная запись» , имеющая несколько разделов для записи этих событий

Производитель -> 1.Транзакцияначинается
2. Аккаунт A BalanceA (-) 500 к теме Аккаунт, раздел p0
3. Аккаунт B BalanceB (+) 500 к теме Аккаунт, раздел p1
4. Концы транзакций

на стороне потребителя у нас есть поток с одним потоком, который обрабатывает эти разделы, и соответственно обновляет свое глобальное хранилище состояний (глобальная таблица K), потребители, потребляющие эти разделы, получают эти сообщения при другом опросе, и возникает несогласованное состояние

1.Subtract500 из учетной записи A в глобальном государственном хранилище в каком-то опросе 2. потребляя некоторые нетранснациональные данные из других разделов 3. Добавьте 500 к учетной записи B в глобальном государственном хранилище - в другом опросе

В промежутке между шагами 1 и 3,У нас есть несогласованное состояние, в котором счет A списывается, но счет B не зачисляется

Как мы можем потреблять транснациональные платежи?l атомарные данные в приложении с использованием низкоуровневого API-интерфейса Kafka Stream для обновления своего глобального хранилища состояний (Global K Table) во избежание противоречивого состояния в любой момент времени.

Answer 1

Обновление записи хранилища состояний по записи для транзакции может привести к непоследовательному просмотру в течение доли времени, тогда как обновление приложения хранилища состояний должно записывать всю транзакцию атомарно (пакетное принятие).Используя потоковое приложение или потребителя, невозможно получить маркеры начала / конца транзакции для выполнения пакетной фиксации.Используя простой приемник в режиме READ_COMMITTED, вы можете задавать конечные смещения (LSO) перед опросом, буферизировать все записи во временной карте до тех пор, пока вы не достигнете конечных смещений (LSO), а затем атомарно записать временную карту в фактическое хранилище состояний (пакетное принятие / сброс)).Этот процесс обеспечит согласованность хранилища состояний и частичных обновлений в случае транзакции не будет.