Оптимизация тем State Store для последующей подписки - PullRequest
0 голосов
/ 05 февраля 2019

У меня есть микросервис, использующий Streams 1.1.1 (в ближайшее время планируется обновление до 2.1), который публикует сводные записи в сжатой теме («события клиента»), которые будут использоваться нижестоящими микросервисами в качестве входных данных KTable.

В итоге создаются две темы с точными копиями одной и той же информации.«Клиент-события» - это одно;другой - внутренний, созданный за кулисами для поддержки государственного хранилища.Оба имеют одинаковые ключи и значения.

Есть ли способ либо -

A) Оптимизировать соглашение о присвоении имен внутренней теме, чтобы мы могли просто использовать тему журнала изменений поддержки хранилища состояний кактема ввода для наших микросервисов, но не страх, что управление версиями нарушит соглашение об именах?

ИЛИ

B) Отключить ведение журнала для хранилища состояний и, если хранилище состояний необходимо восстановить, принудительноиспользовать в качестве входных данных тему «клиентские события».(Предпочтительно)

1 Ответ

0 голосов
/ 08 февраля 2019

Единственное, что вы можете сделать, - это не записывать данные в тему приемника через to() и позволить нижестоящему потребителю читать непосредственно из созданной в любом случае темы журнала изменений.Если вы назовете параметр KTable через Materialized.as(...), имя раздела журнала изменений будет использовать его как компонент имени раздела журнала изменений (указать полное имя раздела журнала изменений невозможно).Присвоение имени KTable обеспечивает совместимость, поэтому имя не меняется при обновлении приложения.

Повторное использование темы вывода и пропуск темы журнала изменений - это оптимизация, которую мы планируем добавить в Kafka Streams в будущем (см. https://issues.apache.org/jira/browse/KAFKA-6035).

Если вы отключите ведение журнала, вы будете использовать гарантии отказоустойчивости, поэтому, похоже, это не вариант.

...