У меня есть приложение с загрузочной пружиной (скажем, оно называется app-1), которое подключено к кластеру kafka и потребляет от специфицированного c topi c, скажем, topi c называется "foo ». Topi c foo всегда получает сообщение, когда другое приложение (скажем, называется app-2) импортирует новый элемент foo в базу данных. Topi c в первую очередь предназначен для использования в третьем приложении (скажем, оно называется app-3), которое рассылает уведомления по электронной почте людям, которые могут быть заинтересованы в этом новом элементе foo. Приложение 3 кластеризовано, то есть одновременно запущено несколько его экземпляров. Kafka автоматически балансирует сообщения foo-topi c между всеми этими экземплярами, поскольку они используют один и тот же идентификатор потребителя. Это хорошо, и в случае с app-3 это действительно желательно.
В случае приложения 2, однако, сообщения из foo-topi c используются для удаления кэша. Логика c в основном заключается в том, что если есть новый элемент foo, то, вероятно, следует очистить существующие кэши, поскольку их содержимое зависит от элементов foo. Проблема в том, что app-2 также кластеризована, что означает, что по умолчанию kafka-logi c, каждый экземпляр будет получать только некоторые сообщения, отправленные в foo-topi c. Это не работает корректно для этого конкретного c приложения, хотя всякий раз, когда появляется новый элемент foo, все экземпляры должны знать об этом, потому что все они должны очистить свои локальные кэши.
Из того, что я понимаю, у меня есть эти два варианта, если я хочу сохранить текущие логи c:
- Ввести распределенный кеш для всех экземпляров app-2, чтобы они все совместно использовали один и тот же кеш. Тогда не имеет значения, получает ли foo-элемент только один экземпляр, потому что удаление кеша также повлияет на кеш других экземпляров; хотя они так и не узнали о предмете foo. Я бы хотел избежать этого решения, так как распределенный кеш привел бы к заметному усложнению, а также накладным расходам.
- Каким-то образом удается использовать разные идентификаторы потребителей для каждого экземпляра приложения-2. Тогда kafka будет считать их разными потребителями, и все они получат каждое сообщение foo-topi c. Тем не менее, я даже не знаю, как программно сделать это. Код приложения не знает о реплицированных экземплярах, нет способа получить доступ к какой-либо информации о том, что это за узел. Если я использую случайно сгенерированную строку при запуске, то каждый раз, когда такой экземпляр перезапускается, он будет считаться новым потребителем и должен будет повторно обрабатывать все предыдущие сообщения. Это было бы неправильным поведением.
Вот мой последний вопрос: можно ли заставить все экземпляры app-2 получать все сообщения из foo-topi c, не нарушая полностью принцип работы кафки? Я знаю, что, вероятно, очень необычно использовать kafka-сообщения для удаления кэша, и я вполне могу найти альтернативный механизм для логики удаления кэша c, который не зависит от сообщений kafka-topi c. Тем не менее, приложения предназначены для демонстрационных целей, и я подумал, что было бы здорово, если бы из этого топи c читалось более одного приложения. Но если мне придется взломать грязный обходной путь, чтобы он заработал, то это также плохо для демонстрационных целей, и я бы предпочел реализовать альтернативный способ удаления кэша.