GlobalKTable Refre sh Логика

Question

При обновлении базового topi c из GlobalKTable, каков logi c для всех экземпляров KStream приложений, чтобы получить самые свежие данные? Ниже приведены мои последующие вопросы:

1. Будет ли GlobalKTable заблокирован на уровне записи или на уровне таблицы, когда происходят обновления?
2. Согласно этому блогу: Kafka Проблема с задержкой GlobalKTable , может ли задержка go до 0,5 с ?! Если да, то есть ли альтернатива для уменьшения задержки?
3. Поскольку GlobalKTable по умолчанию использует RocksDB в качестве хранилища состояний, доступны ли все функции RocksDB для использования?

I поймите, что GlobalKTable не следует использовать в случаях, когда требуется частое обновление данных поиска. Есть ли другое хранилище ключей и значений, которое мы можем использовать для сценариев использования, которые могут потребовать обновления табличных данных - например, Redis?

Я не смог найти много документации по GlobalKTable и его внутренним компонентам. Есть ли доступная документация?

Answer 1

GlobalKTables - это асинхронные обновления c. Следовательно, нет никакой гарантии, когда разные экземпляры обновляются.

Кроме того, «глобальный поток» использует выделенного «глобального потребителя», которого вы можете настроить индивидуально для уменьшения задержки: https://docs.confluent.io/current/streams/developer-guide/config-streams.html#naming

RocksDB интегрирован через JNI, и интерфейс JNI не раскрывает все возможности RocksDB. Более того, абстракции «таблицы» «скрывают» RocksDB, поэтому некоторые расширяются. Однако вы можете настроить RocksDB v ie rocksdb.config.setter (https://docs.confluent.io/current/streams/developer-guide/config-streams.html#rocksdb -config-setter ).

Answer 2

Документация Javadoc для KStream#join() довольно ясно показывает, что соединения с GlobalKTable происходят только при обработке записей в потоке. Поэтому, чтобы ответить на ваш вопрос, не существует автоматических c обновлений, которые происходят с базовыми KStream s: в них необходимо будет обрабатывать новые сообщения, чтобы они могли видеть обновления.

«Соединение поиска по таблице» означает, что результаты вычисляются только при обработке записей KStream. Это делается путем поиска совпадающих записей во внутреннем состоянии GlobalKTable current . Напротив, обработка входных записей GlobalKTable обновит только внутреннее состояние GlobalKTable и не создаст никаких записей результатов.

1. Если GlobalKTable материализуется как хранилище значений ключей , большинство методов для перебора и изменения реализаций KeyValueStore используют ключевое слово synchronized, чтобы предотвратить вмешательство нескольких потоков, одновременно обновляющих хранилище состояний.

2. Возможно, вы сможете уменьшить задержка с использованием хранилища ключей и значений в памяти или с помощью реализации настраиваемого хранилища состояний.

3. Взаимодействие с хранилищами состояний контролируется через набор интерфейсов в Kafka Streams, , например KeyValueStore, поэтому в этом смысле вы не взаимодействуете напрямую с API RocksDB.