Вариант использования: у нас есть сжатая тема, которая будет использовать UUID для отслеживания жизненного цикла заказа.
Некоторые из наших служб должны знать, сколько заказов имеет одна учетная запись за один раз, чтобы предоставлять оповещения и метрики (используя Kafka Streams KTables). Но так как мы набираем UUID, записи будут создаваться по тематическим разделам, а не совместно.
Предложение моей команды заключается в использовании пользовательского класса раздела, чтобы мы могли использовать UUID для ключа записи, но использовать значение идентификатора учетной записи для алгоритма хеширования для создания записей.
Но наша команда разработчиков DevOps / Support обеспокоена тем, что инструменты поддерживают пользовательский класс разбиения (например, Mirror Maker), чтобы выяснить, в каких разделах находятся записи.
Для служб, которым нужны эти данные, мы могли бы использовать логику смены ключей потоков Kafka, которая перенаправит данные во внутренней теме на эту службу, но, насколько я понимаю, это влияет на производительность , Есть ли какой-нибудь четкий способ узнать, какое это будет влияние? Значит ли это, что время обработки каждой записи удваивается?