Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitchesKafka sí intercambia peticiones y respuestas entre clientes y brokers; lo que no proporciona automáticamente es el request/reply de aplicación entre dos servicios que se comunican publicando records. Para asociar una respuesta con una petición, la aplicación debe acordar dónde responder, cómo correlacionar ambos mensajes y qué hacer si la respuesta no llega a tiempo.
Dos significados distintos de request-response
En el protocolo de Kafka 4.3, un cliente envía peticiones al broker y recibe respuestas por una conexión TCP. El protocolo permite canalizar peticiones; en una misma conexión, el broker conserva el orden de procesamiento y de las respuestas.
As an Amazon Associate I earn from qualifying purchases.
Ese intercambio no es una conversación de negocio entre aplicaciones. Publicar un record en un topic no hace que Kafka devuelva automáticamente otro record con el resultado del consumidor. Los topics están repartidos en partitions, y los clientes controlan la asignación y lectura de mensajes. Si la respuesta también es un record, los dos extremos necesitan definir su destino y su relación con la petición original.
Qué debe acordar una aplicación
Un contrato request/reply sobre records necesita, como mínimo, tres decisiones:
#1 Best Overall
- Destino: qué topic recibirá la respuesta y, si corresponde, qué partition.
- Correlación: qué identificador permite reconocer qué petición originó una respuesta.
- Recepción y espera: quién escucha las respuestas, cuánto tiempo espera el solicitante y cómo trata la ausencia de una respuesta.
Sin ese contrato, el consumidor puede procesar la petición y publicar una respuesta, pero el solicitante no dispone de una regla fiable para encontrarla y vincularla a su propia operación.
Cómo implementarlo con Spring for Apache Kafka
Spring for Apache Kafka ofrece ReplyingKafkaTemplate para el lado solicitante. Su método sendAndReceive devuelve un RequestReplyFuture: el future se completa de forma asíncrona con la respuesta o con una excepción, por ejemplo, si vence el tiempo de espera. También expone el resultado del envío, para que la aplicación pueda distinguir el estado de publicación del resultado de reply.
La documentación de Spring 4.0-SNAPSHOT consultada describe estos headers predeterminados:
KafkaHeaders.CORRELATION_ID: identifica la petición para asociarla con su respuesta.KafkaHeaders.REPLY_TOPIC: indica al servidor el topic al que debe publicar el reply.KafkaHeaders.REPLY_PARTITION: opcional; señala la partition de respuesta.
Los nombres de los headers se pueden personalizar, algo útil si uno de los extremos no está implementado con Spring. En ese caso, ambos servicios deben acordar el contrato: el servidor ha de leer la información de destino y devolver el identificador de correlación que el solicitante espera.
Rank #3
Una respuesta frente a varias
ReplyingKafkaTemplate cubre el caso de una petición y una respuesta. Si una petición debe producir varias respuestas, Spring ofrece AggregatingReplyingKafkaTemplate: reúne records hasta que una release strategy determina que se ha completado la operación. La opción returnPartialOnTimeout permite devolver una colección parcial cuando ya se recibió al menos una respuesta antes del timeout. La aplicación tiene que definir cuándo considera completo el conjunto; no basta con esperar indefinidamente a que aparezcan más records.
Elegir cómo enrutar las respuestas
La guía de Spring describe varias opciones de aislamiento para los reply listeners. La elección afecta al routing y al volumen de mensajes que cada instancia debe examinar.
| Diseño | Cómo funciona | Coste o condición |
|---|---|---|
| Topic compartido | Varias instancias escuchan el mismo topic de respuestas; la guía indica configurar un group.id distinto por instancia. Cada una recibe los replies y solo trata como propio el que coincide con su correlation ID. |
Hay tráfico adicional: las instancias reciben y descartan respuestas destinadas a otras. |
| Topic dedicado por instancia | Cada instancia recibe replies en un topic propio. | Evita que todas examinen las respuestas ajenas, pero exige gestionar los destinos individuales. |
| Partition de respuesta dedicada | Las respuestas se enrutan a una partition asignada a la instancia solicitante. | Requiere routing y configuración fija de las partitions del contenedor de respuesta conforme a las condiciones de la guía de Spring. |
Un topic compartido puede simplificar el número de destinos, pero no elimina la correlación: cada instancia necesita distinguir las respuestas que le corresponden. Las alternativas dedicadas aumentan el trabajo de configuración y routing, a cambio de limitar la recepción de replies ajenos.
Free tools Windows power users keep installed
One-click scans. No signup required.
Configurar el timeout sin confundirlo con una cancelación
La página consultada de Spring 4.0-SNAPSHOT indica un timeout predeterminado de cinco segundos cuando no se especifica otro; también documenta que se puede configurar uno y que hay una sobrecarga para establecerlo por operación. No es una recomendación universal: el valor apropiado depende de la latencia esperada y de la versión de Spring Kafka que use la aplicación. Como la referencia es una snapshot, comprueba el comportamiento y la API de la versión concreta desplegada.
Un timeout solo indica que el solicitante no obtuvo la respuesta dentro del plazo configurado. Por sí solo no demuestra si el servidor no procesó la petición, si aún la está procesando o si la respuesta no llegó a ser consumida. La documentación citada describe la espera y la excepción, no un protocolo que cancele el trabajo remoto. Por eso, una aplicación debe decidir qué hacer ante el timeout y considerar que el procesamiento podría continuar.
Cuándo encaja este patrón
Request/reply sobre Kafka resulta útil cuando el transporte basado en topics y la respuesta asociada a una petición forman parte del diseño. Pero no debe tratarse como una llamada directa que Kafka completa por sí solo: la aplicación debe mantener el contrato de respuesta, correlación y espera, incluso si Spring automatiza parte del intercambio.
Quick Recap
- Para una única respuesta, usa una abstracción como
ReplyingKafkaTemplatey define un timeout adecuado a tu caso. - Para varias respuestas, define una estrategia de liberación y decide si una colección parcial tras el timeout es aceptable.
- Para varias instancias solicitantes, elige conscientemente entre topic compartido, topic por instancia o partition dedicada, valorando el tráfico de descarte frente a la complejidad de routing.
- Si los dos extremos usan tecnologías distintas, acuerda los headers y el formato del contrato en ambos lados; los nombres predeterminados de Spring no son un requisito del protocolo de Kafka.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
