KeyedMessage<String, byte[]> keyedMessage = new KeyedMessage<String, byte[]>(request.getRequestTopicName(),SerializationUtils.serialize(message)); producer.send(keyedMessage);
В настоящее время я отправляю сообщение без какого-либо ключа, который поддерживается как часть сообщения с ключом, будет ли он работать с delete.retention.ms, мне нужно отправить ключ как часть сообщения? Хорошо ли сделать ключ как часть сообщения.
Ключи в основном полезны/необходимы, если вам нужен сильный порядок для ключа и разрабатываются нечто вроде конечного автомата. Если вам нужны сообщения с одним и тем же ключом (например, уникальный идентификатор), всегда отображаются в правильном порядке, прикрепление ключа к сообщениям гарантирует, что сообщения с одним и тем же ключом всегда переходят к одному разделу в теме. Kafka гарантирует заказ в пределах раздела, но не через разделы в теме, поэтому альтернативно не предоставление ключа, что приведет к циклическому распределению между разделами, не будет поддерживать такой порядок.
В случае конечного автомата ключи могут использоваться с log.cleaner.enable для дедупликации записей с тем же ключом. В этом случае Kafka предполагает, что ваше приложение заботится только о последнем экземпляре заданного ключа, а очиститель журнала удаляет старые дубликаты заданного ключа, только если ключ не является нулевым. Эта форма уплотнения журнала управляется свойством log.cleaner.delete.retention и требует наличия ключей.
В качестве альтернативы более общее свойство log.retention.hours, которое включено по умолчанию, работает, удаляя полные сегменты журнала, устаревшие. В этом случае ключи не обязательно должны предоставляться. Kafka просто удалит куски журнала, которые старше указанного периода хранения.
Чтобы все сказанное, если вы включили сбой в журналах или требуете строгого порядка для сообщений с одним и тем же ключом, то вы определенно должны использовать ключи. В противном случае нулевые ключи могут обеспечить лучшее распределение и предотвратить возможные проблемы с горячим пятном в тех случаях, когда некоторые ключи могут отображаться больше, чем другие.