Kafka Streams - Как эффективно объединиться с большим, не разделенным магазином / темой

Question

У нас есть поток веб-событий.

Событие разделено на (домен, uid).

Все описанные здесь события относятся к одному домену. Существуют тысячи доменов с очень неравномерным трафиком (отсюда и разделение).

Допустим, у нас есть события от одного незарегистрированного пользователя (uid1). У нас есть события от одного и того же незарегистрированного пользователя с отдельного устройства, которое создает новый uid (назовем его uid2).

Когда у нас есть регистрация на uid1, она регистрируется по электронной почте (email1). Позже, со второго устройства, он входит в систему - так что мы можем знать, что оба uid от одного пользователя.

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

Однако, поскольку они являются разными идентификаторами, они не будут разделены. Разделение только по доменам вместо (domain, uid) нежелательно.

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

Как это решить?

Answer 1

Что мне приходит в голову, так это то, что если у нас есть uid1, соответствующий uid2, то мы можем сохранить пользовательские данные uid1 в локальной таблице KTable на экземпляре uid2. Поскольку uid2 всегда идет к этому экземпляру, нам нужно только, чтобы uid1 был сохранен в KTable для этого экземпляра (не в глобальном KTable).

Таким образом, вы можете иметь глобальное хранилище за пределами Kafka, возможно, в распределенном хранилище ключей / значений в памяти. Получив uid2 и не зная пользователя, но имея адрес электронной почты, вы проверяете KTable, если его там нет, вы ищете его в глобальном хранилище за пределами Kafka, а затем сохраняете его в KTable для будущего локального доступа. С этого момента у вас всегда будут локальные пользовательские данные uid2 для его экземпляра.

Таким образом, вы оплачиваете стоимость сетевого звонка в хранилище ключей / значений только при первом входе в систему с неизвестного идентификатора пользователя.