Manejo de consumers

Autor Olivera Lucas.

Producers y Consumers

Los productores y consumidores envían y reciben mensajes (publicar y suscribir) a través de los brokers. Los mensajes comprenden una clave (Key) opcional y un valor que contiene los datos del mensaje (Content), además de encabezados y metadatos relacionados (Headers). La key se utiliza para identificar el asunto del mensaje o una propiedad del mensaje. Los mensajes se entregan en batch, y los batches y registros contienen encabezados y metadatos que brindan detalles que son útiles para el filtrado y el enrutamiento por parte de los clientes, como la marca de tiempo y la posición de desplazamiento del registro (timestamp, offset, partition).

Producers y Consumers

• Producer

  Un producer envía mensajes a un topic de un broker para que se escriba en el ultimo offset de la partición. Un productor escribe los mensajes en las particiones en forma de round robin o en una partición especifica basado en la key del mensaje.

• Consumer

  Un consumer se subscribe a el topic y lee los mensajes según el topic, la partition y el offset

• Consumer group

  Consumer groups se utilizan para compartir, habitualmente, grandes cantidades de datos generados por multiples productores en determinados topics. Los consumers son agrupados usando un group.id, permitiendo distribuir los mensajes en todos los miembros del grupo. Los consumers dentro de un grupo no leen datos de la misma partición, pero pueden recibir datos de una o más particiones.

• Offsets

  Los Offsets describen la posición de los mensajes dentro de una partición. Cada mensaje en una partición determinada tiene un offset único, que ayuda a identificar la posición de un consumidor dentro de la partición para rastrear la cantidad de registros que se han consumido.

  Los Committed offsets se escriben en un offset commit log. Un __consumer_offsets topic almacena información sobre los committed offsets, la posición de la última y la próxima offset, según el consumer group.

Producing and consuming data

Estandar

• Nombre de consumerGroup: para nombrar al consumer gruop utilizamos la siguiente nomenclatura: {proyect}-{appname} Ej: sce-altapedido spp-geocerca
• Configuración: el nombre se carga en el campo GroupId, en caso de no disponer de este campo las librerías de AMQStream toman el campo AplicationName como contingencia.
• Offset Incial: se debe configurar en Earliest o Latest dependiendo de la necesidad.
  • Earliest: comienza a consumir desde el primer offset disponible del topic.
  • Latest: comienza a consumir desde el ultimo offset en adelante.

Tip

Para saber como consumir o publicar ver la documentación especifica de las librerías de AMQStream .NET o Go

Asignación de partición

El consumerGroup posee un coordinador, el coordinador es el encargo de asignar a cada consumer del grupo a una partición del topic basado en una estrategia de asignación

Nota

Para saber más sobre la estrategia de asignación ver el siguiente post, por defecto las aplicaciónes de .NET y GO utilizando las librerias de AMQStream utilizan la estrategia de StickyAssignor

La asignación de las particiones ocurre de la siguiente manera:

1. Los consumer solicitan y se declaran dentro de un consumer Group
2. Se le asigna un coordinador a ese consumerGroup.
3. El coordinador balancea y asigna las particiones a cada consumer.
   1. Una partición solo puede estar asignada a un consumer del grupo.
   2. Un consumer puede tener asignadas varias particiones
   3. Como cada partición es asignada únicamente a un consumir, si poseemos más consumer que particiones, algunos consumers quedaran ociosos a la espera de una asignación.
4. El coordinador cuando asigna una partición, le suministra el ultimo offset confirmado que tiene almacenado para que el consumer comience a procesar. En caso de no contener un último offset conocido, se aplica la estrategia de consumo de offset, que se encuentra configurada en auto.offset.reset.

Re balanciamiento.

Cuando se incluye o excluye consumers del grupo, el coordinador comienza un proceso de rebalanceo.

1. El coordinador desasigna todas las particiones de los consumidores, haciendo que estos no puedan consumir mientras ocurre el movimiento.
2. Detecta y asigna las particiones dependiendo del nuevo número de miembros.
3. Para esto utiliza la estrategia configurada de asignación de partición.
4. En este proceso un consumer puede perder particiones o ganarlas, es decir, si un consumer poseía 3 particiones, el resultado del rebalanceo puede que solo se le asigne una de esas 3 que poseía.
5. El coordinador cuando asigna una partición, le suministra el ultimo offset confirmado que tiene almacenado para que el consumer comience a procesar. En caso de no contener un ultimo offset conocido, se aplica la estrategia de consumo de offset, que se encuentra configurada en auto.offset.reset.

Tip

Para entender cómo funciona el rebalanceo pueden leer el siguiente post

Tip

Continuar leyendo Schema Registry