Kafka guía autorizada para aprender y configuración de producción kafka

0. Comandos comunes de Kafka

Kafka es una plataforma de procesamiento de flujo distribuido, que es altamente escalable y tolerante a fallas. Aquí hay algunos comandos que se usan comúnmente en la última versión de Kafka:

1. Crea un tema:

   bin/kafka-topics.sh --create --topic my-topic --partitions 3 --replication-factor 3 --bootstrap-server localhost:9092

2. Ver la lista de temas:

   bin/kafka-topics.sh --list --bootstrap-server localhost:9092

3. Ver detalles del tema:

   bin/kafka-topics.sh --describe --topic my-topic --bootstrap-server localhost:9092

4. Enviar un mensaje a un tema:

   bin/kafka-console-producer.sh --topic my-topic --bootstrap-server localhost:9092

5. Consumir mensajes de un tema:

   bin/kafka-console-consumer.sh --topic my-topic --from-beginning --bootstrap-server localhost:9092

6. Ver la compensación del grupo de consumidores (compensación):

   bin/kafka-consumer-groups.sh --describe --group my-group --bootstrap-server localhost:9092

7. Inicie el servicio Kafka:

   bin/kafka-server-start.sh config/server.properties

1. Configuración óptima de Kafka

Hay varios nodos para escribir varios nodos

vim /srv/app/kafka/config/server.properties 

Recuerde cambiar broker.id

broker.id=0
listeners=PLAINTEXT://10.53.32.126:9092
advertised.listeners=PLAINTEXT://10.53.32.126:9092
num.network.threads=3
num.io.threads=8
socket.send.buffer.bytes=102400
socket.receive.buffer.bytes=102400
socket.request.max.bytes=104857600
log.dirs=/srv/data/kafka-data
num.partitions=3
num.recovery.threads.per.data.dir=3
offsets.topic.replication.factor=3
transaction.state.log.replication.factor=3
transaction.state.log.min.isr=3
log.retention.hours=4
log.segment.bytes=1073741824
log.retention.check.interval.ms=300000
zookeeper.connection.timeout.ms=6000
zookeeper.connect=10.53.32.126:2181,10.53.32.153:2181,10.53.32.134:2181
group.initial.rebalance.delay.ms=0
default.replication.factor=2

2 mejores configuraciones de zookeeper

Hay varios nodos para escribir varios nodos

vimconf/zoo.cfg

tickTime=2000
initLimit=10
syncLimit=5
dataDir=/srv/data/zookeeper-data
dataLogDir=/srv/data/zookeeper-datalog
clientPort=2181
autopurge.snapRetainCount=10
autopurge.purgeInterval=1
maxClientCnxns=1200
leaderServes=yes
minSessionTimeout=4000
maxSessionTimeout=40000
server.1=10.53.32.126:2888:3888
server.2=10.53.32.153:2888:3888
server.3=10.53.32.134:2888:3888
## Metrics Providers
# https://prometheus.io Metrics Exporter
metricsProvider.className=org.apache.zookeeper.metrics.prometheus.PrometheusMetricsProvider
metricsProvider.httpPort=7000
metricsProvider.exportJvmInfo=true

1. Si es un solo nodo zk

1. Descarga e inicia zk              http://bit.ly/2sDWSgJ.  El siguiente ejemplo de servicio independiente demuestra cómo instalar Zookeeper con una configuración básica, el directorio de instalación es /usr/local/zookeeper y el directorio de datos es /var/lib/zookeeper.
2. empezar zk

3. # tar -zxf zookeeper-3.4.6.tar.gz
   # mv zookeeper-3.4.6 /usr/local/zookeeper
   # mkdir -p /var/lib/zookeeper
   # cat > /usr/local/zookeeper/conf/zoo.cfg << EOF
   tickTime=2000
   dataDir=/var/lib/zookeeper
   clientPort=2181
   > EOF
   # export JAVA_HOME=/usr/java/jdk1.8.0_51
   # /usr/local/zookeeper/bin/zkServer.sh start
   JMX enabled by default
   Using config: /usr/local/zookeeper/bin/../conf/zoo.cfg
   Starting zookeeper ... STARTED

4.  Confirme que el puerto 2181 está abierto

telnet localhost 2181


ss -luntp|grep 2181

2. Si es un clúster zk

Generalmente elige 3 o 5 nodos base

Modifique el archivo de configuración del grupo, agregue el archivo my.id y los elementos de configuración

vim  /usr/local/zookeeper/conf/zoo.cfg

myid=1
tickTime=2000
dataDir=/var/lib/zookeeper
clientPort=2181
initLimit=20
syncLimit=5
server.1=zoo1.example.com:2888:3888
server.2=zoo2.example.com:2888:3888
server.3=zoo3.example.com:2888:3888

Entre ellos, initLimit indica el límite superior del tiempo utilizado para establecer una conexión inicial entre el nodo esclavo y el nodo maestro, y syncLimit indica el límite superior del tiempo permitido para que el nodo esclavo y el nodo maestro estén desincronizados. Ambos valores son múltiplos de tickTime, por lo que initLimit es 20*2000ms, que es 40s

La configuración también enumera las direcciones de todos los servidores del grupo. La dirección del servidor sigue server.X=hostname:peerPort:leaderPort

Además del archivo de configuración pública, cada servidor debe crear un archivo llamado myid en el directorio de datos Dir, que debe contener la ID del servidor, que debe ser coherente con la ID configurada en el archivo de configuración Atentamente. Después de completar estos pasos, es hora de iniciar los servidores y dejar que se comuniquen entre sí.

3. Instalar kafka

Descarga kafka Apache Kafka Descarga la última versión de Kafka https://downloads.apache.org/kafka/3.5.1/kafka_2.12-3.5.1.tgz

# tar -zxvf kafka_2.12-3.5.1.tgz

mv kafka_2.12-3.5.1 /usr/local/kafka

 mkdir /tmp/kafka-logs
# export JAVA_HOME=/usr/java/jdk1.8.0_51
/usr/local/kafka/bin/kafka-server-start.sh -daemon 
 /usr/local/kafka/config/server.properties

Comprobar si se ha iniciado kafka

Comprobar si kafka informa de un error

ps -ef|grep kafka

Pruebe si la instalación es normal, tenga en cuenta que la nueva versión no necesita depender de zook

La versión kafka es demasiado alta. La versión 2.2+ = no necesita depender de zookeeper para ver/crear temas . La nueva versión usa --bootstrap-server para reemplazar la versión anterior  --zookeeper-server .

crear tema

老版本kafka
/usr/local/kafka/bin/kafka-topics.sh --create --zookeeper localhost:2181  --replication-factor 1 --partitions 1 --topic test

新版本kafka
[root@kafka bin]# /usr/local/kafka/bin/kafka-topics.sh  --bootstrap-server  172.18.207.104:9092 --create --replication-factor 1 --partitions 1 --topic test
Created topic test.

lista de temas

[root@kafka bin]# /usr/local/kafka/bin/kafka-topics.sh --list --bootstrap-server 172.18.207.104:9092
test

4 Iniciar al consumidor a recibir mensajes

Orden:

bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic test

Ejecute el comando anterior rojo no cierre la ventana, continúe y ejecute el siguiente comando de producción

5 El productor envía un mensaje

Orden:

bin/kafka-console-producer.sh --broker-list localhost:9092 --topic test

Ingrese el mensaje del lado de la producción: Soy guapo y presione Enter, y encontrará que el consumo se implementa cuando lo verifica del lado del consumidor 4, siempre que sea bajo el mismo tema

3. Configuración del clúster de Kafka

Configuración del broker 3.1 (fíjate bien)

3.1.1 intermediario.id

Cada corredor debe tener un identificador, representado por broker.id. Su valor predeterminado es 0 y también se puede establecer en cualquier otro número entero. Este valor debe ser único en todo el clúster de Kafka . Este valor se puede seleccionar arbitrariamente y estos ID se pueden intercambiar entre los nodos del servidor con fines de mantenimiento. Se recomienda establecerlos en números enteros relacionados con el nombre de la máquina, de modo que sea menos problemático asignar números de ID a nombres de máquinas durante el mantenimiento. Por ejemplo, si el nombre de la máquina contiene números únicos (como host1.example.com, host2.example.com), entonces es bueno usar estos números para establecer broker.id.

02. puerto Si la muestra de configuración se usa para iniciar Kafka, escuchará en el puerto 9092. Modifique el parámetro de configuración del puerto para establecerlo en cualquier otro puerto disponible. Cabe señalar que si usa un puerto inferior a 1024, debe iniciar Kafka con privilegios de root, pero esto no se recomienda.

03 zookeeper.connect La dirección de Zookeeper utilizada para guardar los metadatos del intermediario se especifica a través de zookeeper.connect. localhost:2181 indica que Zookeeper se está ejecutando en el puerto local 2181. Este parámetro de configuración es un conjunto de listas de nombre de host:puerto/ruta separadas por dos puntos. El significado de cada parte es el siguiente: nombre de host es el nombre de la máquina o dirección IP del servidor de Zookeeper; puerto es el puerto de conexión del cliente de Zookeeper; /ruta es opcional La ruta de Zookeeper, como el entorno chroot del clúster de Kafka. Si no se especifica, la ruta raíz se utiliza de forma predeterminada. Si la ruta chroot especificada no existe, el intermediario la creará al inicio.

Es una buena práctica usar la ruta chroot en el clúster de Kafka. El grupo Zookeeper se puede compartir con otras aplicaciones, incluso si hay otros clústeres de Kafka, no habrá conflictos. Es mejor especificar un conjunto de servidores Zookeeper en el archivo de configuración, separándolos con punto y coma. Una vez que un servidor Zookeeper deja de funcionar, el intermediario puede conectarse a otro nodo en el grupo Zookeeper.

04. log.dirs Kafka guarda todos los mensajes en el disco y log.dirs especifica el directorio para almacenar estos fragmentos de registro. Es un conjunto de rutas del sistema de archivos local separadas por comas. Si se especifican varias rutas, el intermediario guardará los segmentos de registro de la misma partición en la misma ruta de acuerdo con el principio de "uso mínimo". Tenga en cuenta que el intermediario agrega particiones a la ruta con la menor cantidad de particiones, no a la ruta con menos espacio en disco.

05. num.recovery.threads.per.data.dir Para las tres situaciones siguientes, Kafka utilizará un grupo de subprocesos configurable para procesar los segmentos de registro: el servidor se inicia normalmente y se utiliza para abrir segmentos de registro para cada partición, reiniciar después de un servidor bloqueo, utilizado para verificar y truncar segmentos de registro para cada partición; Apagado normal del servidor, utilizado para cerrar segmentos de registro. De forma predeterminada, solo se utiliza un subproceso por directorio de registro. Debido a que estos subprocesos solo se usan cuando el servidor se inicia y se apaga, es completamente posible configurar una gran cantidad de subprocesos para lograr el propósito de la operación en paralelo. Especialmente para servidores con una gran cantidad de particiones, en caso de falla, el uso de operaciones paralelas durante la recuperación puede ahorrar horas. Al configurar este parámetro, debe tenerse en cuenta que el número configurado corresponde al directorio de registro único especificado por log.dirs. Es decir, si num.recovery.threads.per.data.dir se establece en 8 y log.dir especifica 3 rutas, se requieren un total de 24 subprocesos.

06. auto.create.topics.enable De manera predeterminada, Kafka creará automáticamente temas en las siguientes situaciones: cuando un productor comienza a escribir mensajes en el tema, cuando un consumidor comienza a leer el mensaje del tema, cuando cualquier cliente envía una solicitud de metadatos a El tema. Muchas veces, estos comportamientos no son los esperados. Además, según el protocolo de Kafka, si un tema no se crea primero, no hay forma de saber si ya existe. Si está creando temas explícitamente, ya sea manualmente o mediante algún otro sistema de configuración, puede establecer auto.create.topics.enable en false.

3.1.2 La configuración predeterminada del tema (entender)

01. núm.particiones

El parámetro num.partitions especifica cuántas particiones contendrá el tema recién creado y el valor predeterminado de este parámetro es 1. Tenga en cuenta que podemos aumentar la cantidad de particiones de temas, pero no disminuir la cantidad de particiones. Por lo tanto, si desea tener un tema con menos particiones que el valor especificado por num.partitions, debe crear manualmente el tema

Cómo elegir el número de particiones

Seleccionar el número de particiones para un tema no es opcional Al seleccionar el número, se deben considerar los siguientes factores.

Si no conoce esta información, como regla general, puede obtener mejores resultados limitando el tamaño de la partición a 25 GB.

02. registro.retención.ms

Kafka generalmente usa el tiempo para determinar cuánto tiempo se pueden conservar los datos. De forma predeterminada, el parámetro log.retention.hours se usa para configurar el tiempo y el valor predeterminado es 168 horas, que es una semana. Además, existen otros dos parámetros log.retention.minutes y log.retention.ms. Las funciones de estos tres parámetros son las mismas, todos determinan cuánto tiempo se eliminará el mensaje, pero se recomienda usar log.retention.ms. Si se especifica más de un parámetro, Kafka preferirá el de menor valor

03. log.retention.bytes Otra forma es juzgar si el mensaje caduca por el número de bytes de mensaje retenidos. Su valor está especificado por el parámetro log.retention.bytes y actúa en cada partición. Es decir, si hay un tema con 8 particiones y log.retention.bytes está configurado en 1 GB, este tema puede retener hasta 8 GB de datos. Por lo tanto, cuando aumenta el número de particiones de un tema, también aumentan los datos que puede retener todo el tema.

Si se especifican tanto log.retention.bytes como log.retention.ms (u otro parámetro de tiempo), el mensaje se eliminará tan pronto como se cumpla cualquiera de las dos condiciones.

04. La configuración anterior de log.segment.bytes se aplica a los segmentos de registro, no a los mensajes individuales. A medida que los mensajes llegan a los intermediarios, se agregan al segmento de registro actual de la partición. Cuando el tamaño del segmento de registro alcance el límite superior especificado por log.segment.bytes (el valor predeterminado es 1 GB), el segmento de registro actual se cerrará y se abrirá un nuevo segmento de registro. Si un segmento de registro está cerrado, comienza a esperar el vencimiento. Cuanto menor sea el valor de este parámetro, con mayor frecuencia se cerrarán y asignarán nuevos archivos, lo que reducirá la eficiencia general de la escritura en disco.

El tamaño del segmento de registro afecta el uso de marcas de tiempo para obtener compensaciones. Al usar la marca de tiempo para obtener el desplazamiento del registro, Kafka verificará el segmento de registro (que se ha cerrado) cuya hora de última modificación sea mayor que la marca de tiempo especificada en la partición, y el archivo anterior del segmento de registro La hora de última modificación es menor que la marca de tiempo especificada. Luego, Kafka devuelve el desplazamiento del comienzo de ese segmento de registro (es decir, el nombre del archivo). Para las operaciones que utilizan marcas de tiempo para obtener compensaciones, cuanto más pequeño sea el segmento de registro, más preciso será el resultado.

3.2 Cuántos corredores se necesitan

La cantidad de intermediarios que necesita un clúster de Kafka depende de los siguientes factores. En primer lugar, cuánto espacio en disco se necesita para almacenar los datos y cuánto espacio hay disponible para un único intermediario. Si todo el clúster necesita retener 10 TB de datos y cada agente puede almacenar 2 TB, se requieren al menos 5 agentes. Si la replicación de datos está habilitada, se requiere al menos el doble de espacio, pero esto depende del factor de replicación configurado (descrito en el Capítulo 6). En otras palabras, si la replicación de datos está habilitada, el clúster necesita al menos 10 intermediarios.

El segundo factor a considerar es la capacidad del clúster para manejar solicitudes. Esto suele estar relacionado con la capacidad de la interfaz de red para manejar el tráfico del cliente, especialmente cuando hay múltiples consumidores o el tráfico fluctúa durante la retención de datos (como ráfagas de tráfico durante las horas pico). Si la interfaz de red de un solo corredor puede alcanzar el 80 % de uso durante las horas pico y hay dos consumidores, entonces el consumidor no puede mantener el pico a menos que haya dos corredores. Este consumidor adicional se tiene en cuenta si el clúster tiene habilitada la replicación. Los problemas de rendimiento causados ​​por el bajo rendimiento del disco y la memoria insuficiente del sistema también se pueden resolver mediante la expansión de múltiples intermediarios.

 3.2.1 configuración del intermediario

Para agregar un intermediario al clúster, solo es necesario modificar dos parámetros de configuración. En primer lugar, todos los agentes deben configurarse con el mismo zookeeper.connect , que especifica el grupo y la ruta de Zookeeper utilizados para guardar los metadatos.

En segundo lugar, cada corredor debe establecer un valor único para el parámetro broker.id .

3.2.2 ¿Por qué no establecer vm.swappiness en cero?

Anteriormente, se recomendaba intentar establecer vm.swapiness en 0, lo que significa que "a menos que se produzca un desbordamiento de memoria, no realice el intercambio de memoria". No fue hasta el lanzamiento del kernel de Linux 3.5-rc1 que cambió el significado de este valor. Este cambio se transfirió a otras distribuciones, incluido el kernel 2.6.32-303 de Red Hat Enterprise. Después de un cambio, 0 significa "no intercambiar bajo ninguna circunstancia". Así que ahora se recomienda establecer este valor en 1.

3.2.3 Páginas sucias

Las páginas sucias se descargan en el disco y podemos beneficiarnos ajustando cómo el kernel maneja las páginas sucias. Kafka se basa en el rendimiento de E/S para proporcionar tiempos de respuesta rápidos a los productores. Esta es la razón por la que los fragmentos de registro generalmente se guardan en discos rápidos, ya sea un único disco rápido (como SSD) o un subsistema de disco con caché NVRAM (como RAID). De esta forma, antes de que el proceso de vaciado en segundo plano escriba páginas sucias en el disco, se puede reducir la cantidad de páginas sucias. Esto se puede lograr configurando vm.dirty_background_ratio en un valor inferior a 10. Este valor se refiere al porcentaje de memoria del sistema y, en la mayoría de los casos, es suficiente establecerlo en 5 . No debe establecerse en 0, ya que eso haría que el kernel volcara las páginas con frecuencia, lo que reduciría la capacidad del kernel para almacenar escrituras de disco en el dispositivo subyacente.

La cantidad de páginas sucias antes de que el proceso del kernel las vacíe en el disco se puede aumentar configurando el parámetro vm.dirty_ratio , que se puede configurar en un valor superior a 20 (esto también es un porcentaje de la memoria del sistema). Este valor se puede configurar en un amplio rango, y 60~80 es un intervalo razonable. Sin embargo, el ajuste de este parámetro conlleva algunos riesgos, incluido el número de operaciones de disco sin vaciar y largas esperas de E/S provocadas por vaciados sincrónicos. Si este parámetro se establece en un valor alto, se recomienda habilitar la función de replicación de Kafka para evitar la pérdida de datos debido a fallas del sistema. Para establecer valores adecuados para estos parámetros, es mejor verificar la cantidad de páginas sucias mientras se ejecuta el clúster de Kafka, tanto en entornos reales como simulados. Puede ver el número actual de páginas sucias en el archivo /proc/vmstat

cat /proc/vmstat | egrep "dirty|writeback"

3.2.4 Sistema de archivos

Independientemente del sistema de archivos que se utilice para almacenar segmentos de registro, es mejor establecer correctamente el parámetro noatime del punto de montaje. Los metadatos del archivo incluyen tres marcas de tiempo: hora de creación (ctime), hora de la última modificación (mtime) y hora del último acceso (atime). Por defecto, atime se actualiza cada vez que se lee un archivo, lo que resulta en muchas escrituras en disco, y el atributo atime no es muy útil a menos que alguna aplicación quiera saber que un archivo ha sido accedido desde la última modificación (use realtime en este caso). Kafka no utiliza esta propiedad, por lo que se puede desactivar por completo. Establecer el parámetro noatime para el punto de montaje evita que se actualice atime, pero no afecta a ctime y mtime

3.2.5 Red, ¿qué debo hacer si uso Chaha?

Red De forma predeterminada, el kernel del sistema no está optimizado para una transmisión de red rápida y de gran tráfico, por lo que para las aplicaciones, generalmente es necesario ajustar la pila de red del sistema Linux para lograr soporte de alto tráfico. De hecho, ajustar la configuración de red para Kafka es lo mismo que ajustar la configuración de red para la mayoría de los demás servidores web y aplicaciones de red. En primer lugar, puede ajustar el tamaño de la memoria asignada a los búferes de lectura y escritura del socket, lo que puede mejorar significativamente el rendimiento de transmisión de la red. Los parámetros correspondientes al búfer de lectura y escritura del socket son net.core.wmem_default y net.core.rmem_default, y el valor razonable es 131 072 (es decir, 128 KB). Los parámetros correspondientes al valor máximo del búfer de lectura y escritura son net.core.wmem_max y net.core.rmem_max respectivamente, y el valor razonable es 2 097 152 (es decir, 2 MB). Cabe señalar que el valor máximo no significa que cada socket deba tener un espacio de búfer tan grande, solo significa que se alcanzará este valor cuando sea necesario. Además de configurar el socket, también debe configurar el búfer de lectura y escritura del socket TCP, y sus parámetros son net.ipv4.tcp_wmem y net.ipv4.tcp_rmem. Los valores de estos parámetros constan de 3 enteros separados por espacios, que representan los valores mínimo, predeterminado y máximo. El valor máximo no puede ser mayor que el tamaño especificado por net.core.wmem_max y net.core.rmem_max. Por ejemplo, "4096 65536 2048000" indica que el valor mínimo es 4 KB, el valor predeterminado es 64 KB y el valor máximo es 2 MB. Según el tráfico real recibido por el servidor Kafka, es posible que deba establecer un valor máximo más alto para proporcionar más espacio de búfer para las conexiones de red. También hay otros parámetros de red útiles. Por ejemplo, establecer net.ipv4.tcp_window_scaling en 1 y habilitar la escala de la ventana de tiempo de TCP puede mejorar la eficiencia de la transmisión de datos del cliente, y los datos transmitidos pueden almacenarse en búfer en el lado del servidor. Establezca net.ipv4.tcp_max_syn_backlog en un valor mayor que el valor predeterminado de 1024 para aceptar más conexiones simultáneas. poner net.core.

Todavía se recomienda usar la última versión de Kafka para permitir que los consumidores envíen compensaciones al servidor de Kafka y eliminen la dependencia de Zookeeper.

Aunque varios clústeres de Kafka pueden compartir un grupo de Zookeeper, no se recomienda compartir Zookeeper con otras aplicaciones si es posible. Kafka es sensible a los retrasos y tiempos de espera de Zookeeper, y una anomalía de comunicación con el grupo de Zookeeper puede provocar un comportamiento impredecible del servidor de Kafka. Esto facilita que varios corredores se desconecten al mismo tiempo, y si están desconectados de Zookeeper, también hará que la partición se desconecte.

4. Productor de Kafka: escribir datos en Kafka

En un sistema de procesamiento de transacciones con tarjeta de crédito, existe una aplicación cliente, que puede ser una tienda en línea, que se encarga de enviar la transacción a Kafka cada vez que se produce un pago. Otra aplicación compara la transacción con un motor de reglas y decide si aprobarla o rechazarla. Los mensajes de respuesta de aprobación o rechazo se escriben en Kafka y luego se envían a la tienda en línea que inició la transacción. Una tercera aplicación lee el estado de transacción y auditoría de Kafka, los guarda en la base de datos y los analistas pueden analizar los resultados y quizás mejorar el motor de reglas.

En este capítulo, comenzaremos con el diseño y los componentes de los productores de Kafka y aprenderemos a usar los productores de Kafka . Mostraremos cómo crear objetos KafkaProducer y ProducerRecords, enviar registros a Kafka y manejar los errores devueltos por Kafka, luego presentaremos opciones de configuración importantes para controlar el comportamiento del productor y, finalmente, profundizaremos en cómo usar diferentes El método de partición y el serializador, y cómo para personalizar el serializador y el particionador.

Además del cliente integrado del cliente de terceros, Kafka también proporciona un protocolo de conexión binario , es decir, podemos enviar directamente la secuencia de bytes adecuada al puerto de red de Kafka para leer mensajes de Kafka o escribir mensajes en Kafka. También hay muchos clientes de Kafka implementados en otros lenguajes, como C ++, Python, Go, etc., todos los cuales implementan el protocolo de conexión de Kafka, lo que hace que Kafka no se limite al uso en Java. Estos clientes no forman parte del proyecto Kafka, pero hay una lista de todos los clientes disponibles en la wiki del proyecto Kafka.

4.1 Descripción general del productor

Utilice escenarios para diferenciar las necesidades

Una aplicación necesita escribir mensajes en Kafka en muchos casos: registrar actividades de usuario (para auditoría y análisis), registrar métricas, guardar mensajes de registro, registrar información sobre electrodomésticos inteligentes y comunicarse con otras aplicaciones. para ser escrito en la base de datos, y así sucesivamente. Diversos escenarios de uso significan diversos requisitos: ¿Todos los mensajes son importantes? ¿Es aceptable perder una pequeña fracción de mensajes? ¿Es aceptable tener mensajes duplicados ocasionales? ¿Existen requisitos estrictos de latencia y rendimiento? En el sistema de procesamiento de transacciones de tarjetas de crédito mencionado anteriormente, no se permite la pérdida o duplicación de mensajes, y el retraso aceptable es de hasta 500 ms, lo que requiere un alto rendimiento; esperamos procesar un millón de noticias por segundo.

Guardar información de clics para sitios web es otro caso de uso. En este escenario, se permite que se pierda o se repita una pequeña cantidad de mensajes, y la demora puede ser mayor, siempre que la experiencia del usuario no se vea afectada. En otras palabras, no nos importa que el mensaje tarde unos segundos en llegar al servidor de Kafka, siempre que la página se cargue inmediatamente después de que el usuario haga clic en el enlace. El rendimiento depende de la frecuencia con la que los usuarios del sitio web utilizan el sitio web. Los diferentes escenarios de uso tendrán un impacto directo en el uso y la configuración de la API del productor.

proceso

Enviar objeto ProducerRecord ------ serialización ------>> particionador --->> lanzar al tema -->>

Si el mensaje se escribe correctamente en Kafka, se devuelve un objeto RecordMetaData, que contiene información sobre el tema y la partición, así como el desplazamiento del registro en la partición. Si la escritura falla, se devuelve un error. El productor intentará reenviar el mensaje después de recibir un error, y si sigue fallando después de varias veces, devolverá un mensaje de error.