Un servidor de Kafka es un Broker y un closter es un conjunto de Brokers.
Para correr estos brokers se utiliza Zookeper.
El puerto 2181 es por defecto tanto para Zookeper como Kafaka.
Para iniciar kafka : sh bin/kafka-server-start.sh config/server.properties
Para iniciar Zookeper : sh bin/zookeeper-server-start.sh config/zookeeper.properties
Es un flujo de mensajes, cada topic se compone de mas de una particion y cada mensaje se colocan estas particiones y son ordenados por un offset
Un topic de kafka es donde pongo mis mensajes, compuestas por "n" particiones, los mensajes entran a estas particiones donde cada mensaje tiene un identificador denominada offset.
sh bin/kafka-topics.sh --bootstrap-server localhost:9092 --create topic ian-topic -partitions 5 --replication-factor 1
Con : "sh bin/kafka-topics.sh --bootstrap-server localhost:9092" Decimos que queremos crear un topic en el 9092 justo donde tenemos el broker de kafka
Con : "--create topic ian-topic -partitions 5 --replication-factor 1" Decimos que queremos crear un topic de 5 particiones un 1 replicacion
Si yo quisiera 3 replicaciones, no voy a poder porque solo tengo un broker, si quiero 3 replicaciones minimo necesito 3 brokers en mi cluster
sh bin/kafka-topics.sh --list --bootstrap-server localhost:9092
sh bin/kafka-topics.sh --describe --topic ian-topic --bootstrap-server localhost:9092
Si queremos aumentar la cantidad de particiones
sh bin/kafka-topics.sh --bootstrap-server localhost:9092 --alter --topic ian-topic --partitions 40
DATO : Podemos modificar aumentando la cantidad de particiones pero nunca reduciendolo
sh bin/kafka-topics.sh --bootstrap-server localhost:9092 --delete --topic ian-topic
Con esto es posible conocer cuantas particiones y replicas tenia mi topic
Multiple particiones permite tener consumidore de mensajes trabajando concurrentemente, mientras más consumidores afectará a la velocidad de envio de mensajes.
Para incrementar la disponibilidad de la informacion los topics se deben replicar en multiples brokers.
Como vemos aquí tenemos un cluster de tres brokers, lo que nos posibilita a tener como maximo 3 replicas de un topic. En este caso se asignan 2 replicas de un mismo topic, generando un lider y un seguidor, si tengo 3 replicas tendré un lider y dos seguidores, asi sucesivamente. Como vemos la replica del topic es exacta incluso en la cantidad de particiones de estos.
Se dice que si una replica se encuentra totalmente actualizada, se encuentra en un estado "in-sync", si por alguna razón un lider se cae, deja de estar actualizado, otra replica seguidora podría tomar su lugar de lider.
Un mensaje es una unidad de datos en kafka, compuesto por una llave y valor. Un mensaje es generador por un productor y recibido por un consumidor.
Publica mensajes en uno o mas TOPICS y es el que indica en que particion colocar ese mensaje
sh bin/kafka-console-producer.sh --topic ian-topic --bootstrap-server localhost:9092
Como vemos nos permite escribir un mensaje.
Lee mensajes de uno o más TOPICS y los procesa. El consumidor siempre tendrá una posicion, la posicion es el ultimo mensaje que leyó el consuimdor. La diferencia entre la posicion del consumidor y el mensaje más nuevo que ingresó en la partición se conoce como offset lag. El offset lag es muy importante porque es una medida que me indica que tan rapido está procesando los mensajes el consumidor. Aquel periodo de tiempo que se mantienen los mensajes sin leer se llama rentention period.
En Kafka los mensajes se almacenan por un periodo de tiempo, si este periodo es igual al offset lag estamos ante un gran problema.
sh bin/kafka-console-consumer.sh --topic ian-topic --bootstrap-server localhost:9092
El consumidor queda esperando mensajes del productor.
Hasta que el productor genera el mensaje y le llega al consumidor
Si detengo mi consumidor y mi productor sigue mandando mensajes
Ahora si creo nuevamente un consumidor y en ese instante envio un mensaje, vamos a ver que el consumidor comienza a leer los mensajes pero a partir de los mensajes que se enviaron desde que él estuvo en linea.
Se perdió de 2 mensajes
Solucionamos este problema, con la bandera --from-beginning
sh bin/kafka-console-consumer.sh --topic ian-topic --from-beginning --bootstrap-server localhost:9092
Cada uno de los consumidores pertenece a un grupo. Un consumer group puede tener uno o mas de un consumidor. Un consumidor puede leer más de una particion, pero una particion solo puede ser leida por un consumidor de un mismo grupo, es decir, pueden haber mas de un consumidor que lea de una particion pero estos tienen que ser de grupos distintos.
Puede darse el caso en tener más consumidores que particiones, en este caso puede ocurrir que hayan consumidores osciosos, es decir, que no leen nada.