Kafka supporta la richiesta di messaggistica di risposta

Question

Sto indagando su Kafka 9 come progetto per hobby e ho completato alcuni esempi di tipo "Hello World".

Ho dovuto pensare alle applicazioni di Real World Kafka basate sulla richiesta di messaggistica di risposta in generale e in particolare su come collegare un messaggio di richiesta di Kafka al suo messaggio di risposta.

Stavo pensando a utilizzare un UUID generato come chiave del messaggio di richiesta e utilizzare questo UUID di richiesta come chiave del messaggio di risposta associata. Molto lo stesso tipo di meccanismo con cui WebSphere MQ ha un ID di correlazione dei messaggi.

Il mio processo di fine 2 sarebbe.

1). Il client Kafka genera un UUID casuale e invia un singolo messaggio di richiesta Kafka. 2). Il server consumerebbe questo estratto messaggio richiesta & memorizzare il valore UUID richiesta 3). completare un processo aziendale utilizzando il payload del messaggio. 4). Rispondere con un messaggio di risposta che utilizza il valore UUID memorizzato dal messaggio di richiesta come messaggio di risposta Chiave. 5). il client Kafka esegue il polling dell'argomento della risposta fino a quando non esaurisce il timeout o recupera un messaggio con il valore UUID della richiesta originale.

Quello che mi preoccupa è che il polling di Kafka Consumer rimuoverà altri messaggi dei client dall'argomento di risposta e incrementerà gli offset facendo fallire altri client.

Sto tentando di applicare Kafka in un caso d'uso per il quale non è mai stato progettato?

È possibile implementare la messaggistica di richiesta/risposta in Kafka?

Answer 1

Anche se Kafka fornisce metodi convenienti per mantenere gli offset commessi per un determinato gruppo di consumatori, non è necessario utilizzare tale comportamento e può scrivere il proprio se ne senti la necessità. Anche così, l'uso di Kafka nel modo in cui l'hai descritto è un po 'imbarazzante per il caso d'uso poiché ogni cliente ha bisogno di cercare ripetutamente l'argomento per una risposta specifica. Questo è inefficiente nel migliore dei casi.

È possibile suddividere il problema in due parti, continuando a utilizzare Kafka per inviare richieste e risposte dal server. L'unico pezzo che avresti bisogno di aggiungere sarebbe una sorta di livello API a cui i tuoi clienti parlano e che incapsula la logica specifica di Kafka dai tuoi clienti. Questo strato avrebbe bisogno di un DB locale (relazionale o NoSQL) in grado di memorizzare le risposte uuid rendendo molto veloce e facile per l'API di rispondere se una risposta è disponibile per un uuid specifico.

Answer 2

Non l'ho mai provato, ma in teoria, se prima di iniziare qualsiasi produzione, produci alcuni messaggi con numeri da 0 a numero di partizioni dall'argomento risposta e i tuoi produttori sono già consumatori di tale argomento, quindi ogni produttore riceverebbe almeno uno di quei messaggi. Quindi è possibile memorizzare quella chiave su ciascun produttore e pubblicarla con lo uuid ... Dopo il processo sul consumatore, può pubblicare la risposta (sull'argomento della risposta) con lo uuid e digitata con la stessa chiave inviata con esso, quindi sarà ottenuto dallo stesso produttore che lo ha inviato ... Una volta che tutti i messaggi con la stessa chiave sono pubblicati nella stessa partizione ...

Answer 3

Più facile! Puoi scrivere su zookeeper solo che l'UUID X dovrebbe avere una risposta sulla partizione Y, e fare in modo che il produttore che ha inviato quell'UUID consumi la partizione Y ... Ha senso?

Answer 4

Penso che sia necessaria una chiave shard ben definita del servizio che richiama la richiesta. La tua richiesta dovrebbe contenere questa chiave shard e il nome dell'argomento in cui inserire la risposta.Dovresti anche creare una sorta di macchina a stati e quando un messaggio riguardante il tuo compito ti porta in qualche stato ... questo sarebbe per il rigoroso design asincrono