Поддерживает ли Kafka обмен ответами на запросы
Я исследую Кафку 9 как хобби-проект и завершил несколько примеров типа "Hello World".
Я задумался о реальных приложениях Кафки, основанных на обмене ответами на запрос в целом и более конкретно, как связать сообщение запроса Кафки с его ответным сообщением.
Я думал об использовании сгенерированного UUID в качестве ключа сообщения запроса и использовать этот UUID запроса в качестве связанного ключа сообщения ответа. Так же тип механизма, для которого WebSphere MQ имеет идентификатор корреляции сообщений.
мой конец 2 конец процесса.
1). Клиент Kafka генерирует случайный UUID и отправляет одно сообщение запроса Kafka. 2). Сервер будет использовать это сообщение запроса извлечь и сохранить значение UUID запроса 3). выполните бизнес-процесс, используя полезную нагрузку сообщения. 4). Ответьте с ответным сообщением, которое использует сохраненное значение UUID из сообщения запроса в качестве ключа сообщения ответа. 5). Кафка клиент опрашивает тему ответа, пока не истекает время ожидания или не извлекается сообщение с исходным значением UUID запроса.
меня беспокоит то, что опрос потребителей Кафки удалит другие сообщения клиентов из темы ответа и увеличит смещения, заставляющие других клиентов терпеть неудачу.
Я пытаюсь применить Кафку в случае использования, для которого он никогда не был предназначен?
возможно ли реализовать обмен запросами/ответами в Kafka?
4 ответов
несмотря на то, что Кафка предоставляет удобные методы для сохранения зафиксированных смещений для данной группы потребителей, вы не обязаны использовать это поведение и можете написать свое собственное, если почувствуете необходимость. Тем не менее, использование Кафки так, как вы его описали, немного неудобно для прецедента, поскольку каждому клиенту необходимо повторно искать тему для конкретного ответа. Это в лучшем случае неэффективно.
вы можете разбить проблему на две части, продолжая использовать Кафку для доставки запросы и ответы от сервера. Единственное, что вам нужно добавить,-это какой-то уровень API, с которым разговаривают ваши клиенты и который инкапсулирует логику Кафки от ваших клиентов. Этому слою потребуется локальная БД (реляционная или NoSQL), которая может хранить ответы uuid, что делает его очень быстрым и легким для API, чтобы ответить, доступен ли ответ для конкретного uuid.
легче! Вы можете только написать на zookeeper, что UUID X должен быть отвечен на разделе Y, и заставить производителя, отправившего этот UUID, использовать раздел Y... Это имеет смысл?
Я никогда не пробовал это, но теоретически, если вы перед запуском любого продукта производите некоторые сообщения с номерами от 0 до количества разделов из темы ответа, и ваши производители уже являются потребителями этой темы, поэтому каждый производитель получит хотя бы одно из этих сообщений. Таким образом, вы можете сохранить этот ключ на каждом производителе и опубликовать его с помощью uuid... После процесса на потребителе он может опубликовать ответ (по теме ответа) с помощью uuid и с тем же ключом ключ отправлен с ним, поэтому он будет получен тем же производителем, который его отправил... Как только все сообщения с одним ключом будут опубликованы в одном разделе...
Я думаю, вам нужен хорошо определенный ключ осколка службы, которая вызывает запрос. Ваш запрос должен содержать этот ключ осколка и имя темы, в которой следует опубликовать ответ. Также вы должны создать какую-то государственную машину, и когда приходит сообщение о вашей задаче, вы переходите в какое-то состояние... это было бы для строгого асинхронного дизайна