Apache Kafka : Brokers y réplica de datos


En el post anterior hablamos sobre el ecosistema de Apache Kafka en el post Apache Kafka: El ecosistema y los conceptos básicos, ahora es el turno de hablar de brokers y replicación de datos.

Brokers

Un cluster de Apache Kafka se compone de multiples brokers (servidores), cada uno de ellos contiene un id y  particiones. Una vez que te conectas a un broker, estarás conectado al cluster completo.

Un cluster de Kafka esta constituido de la siguiente forma:

brokers

Como se puede ver en la imagen tendremos lo siguiente:

  • Un cluster de Kafka puede tener multiples brokers
  • Un topic puede tener multiples particiones
  • Cada partición puede vivir en diferentes brokers
  • Un topic puede vivir el múltiples brokers

Replication factor

La traducción literal de replication factor es factor de replicas, esto se refiere a cuantas copias tendré de mi topic, a continuación se muestran algunos puntos a considerar para asignarlo:

  • Se debe asignar un replication factor mayor que cero
  • El número máximo de replicas es el número máximo de brokers en el servidor
  • Si un nodo está abajo, otro nodo que cuente con una replica puede entregar los datos
  • Las particiones también se replican

Veamos la siguiente imagen:

replication

Analicemos la imagen anterior:

  • Se tienen 3 brokers
  • Se tiene 1 topic llamado Topic 1
  • Topic 1 tiene 2 particiones
  • Topic 1 tiene un replication factor 2

Con lo anterior imaginemos los siguientes escenarios:

  1. Broker 1 se cae

broker1

Si esto sucede aun tendremos funcionando el Topic 1 debido a que la partición 0 se encuentra en broker 2 y la partición 1 se encuentra en el broker 3.

2. Broker 2 se cae

broker2

Si esto sucede el Topic 1 seguiría funcionando de forma correcta debido a que Broker 1 contiene la partición 0 y broker 3 contiene la partición 1.

3. Broker 3 se cae

broker3

Por último si el broker 3 se cae el Topic 1 seguiría funcionando de forma correcta debido a que la partición 0 se encuentra en el broker 1 y la partición 1 se encuentra en el broker 2.

Es importante mencionar que existen sistemas que requieren alta disponibilidad que cuentan hasta con 100 brokers funcionando de forma simultanea, esto nos puede dar una idea del nivel de confianza que les podemos dar.

Partition Leader

Como pueden ver un topic puede tener multiples particiones, esto trae el concepto de partition leader o partición líder. Solo un broker puede ser el líder para una partición en específico y solo ese líder puede enviar y recibir datos, los demás brokers solo se utilizarán para sincronizar los datos.

Si recordamos lo que mencionamos anteriormente si un topic tiene 3 particiones cada partición vivirá en un broker diferente, si a esto agregamos que un topic puede tener un replication factor digamos de 3 entonces tendremos el número de particiones multiplicadas por 3, esto significa que una de esas 3 particiones un broker será el líder y los demás se conocerán como ISR (In sync replica).

Si te gusta el contenido y quieres enterarte cuando realicemos un post nuevo síguenos en nuestras redes sociales https://twitter.com/geeks_mx y https://www.facebook.com/geeksJavaMexico/.

Autor: Alejandro Agapito Bautista

Twitter: @raidentrance

Contacto:raidentrance@gmail.com

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s