【Kafka】Cola de mensajes Kafka Avanzado

Mecanismo de partición Kafka

Política de escritura de partición del productor

El productor escribe el mensaje en el tema y Kafka distribuirá los datos a diferentes particiones de acuerdo con diferentes estrategias.

• Estrategia de partición por turnos
• estrategia de partición aleatoria
• Estrategia de asignación por partición clave
• estrategia de partición personalizada

estrategia de encuesta

  La estrategia predeterminada, que también es la estrategia más utilizada, puede garantizar que todos los mensajes se distribuyan uniformemente en una partición en la mayor medida posible. Si la clave es nula al generar mensajes, se utiliza el algoritmo de turno rotativo para distribuir uniformemente las particiones.

estrategia aleatoria (no utilizada)

  Estrategia aleatoria, que distribuye aleatoriamente mensajes a cada partición cada vez. En versiones anteriores, la estrategia de partición predeterminada es la estrategia aleatoria, que también consiste en escribir mensajes en cada partición de manera equilibrada. Pero la estrategia de sondeo de seguimiento funciona mejor, por lo que rara vez se utiliza la estrategia aleatoria.

Estrategia de asignación por clave

  De acuerdo con la estrategia de asignación de claves, puede haber [sesgo de datos], por ejemplo: una clave contiene una gran cantidad de datos, debido a que el valor de la clave es el mismo, todos los datos se asignarán a una partición, lo que dará como resultado la cantidad de mensajes en esta partición es mucho más grande que otras particiones.

problema fuera de servicio

  La estrategia de sondeo y la estrategia aleatoria causarán un problema.Los datos producidos en Kafka se almacenan fuera de servicio.
  La partición por clave puede lograr un almacenamiento ordenado de los datos hasta cierto punto, es decir, un orden local, pero esto puede generar sesgos en los datos, por lo que en el entorno de producción real, se debe realizar una compensación en función de la situación real.

estrategia de partición personalizada

Cree un particionador personalizado:

public class KeyWithRandomPartitioner implements Partitioner {
    
    
    private Random r;

    @Override
    public void configure(Map<String, ?> configs) {
    
    
        r = new Random();
    }

    @Override
    public int partition(String topic, Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster) {
    
    
        //cluster.partitionCountForTopic 表示获取指定topic的分区数量
        //r.nextInt(1000) 表示从随机数生成器 r 中随机生成一个小于1000的整数，其中参数1000指定了生成的随机数的范围，即生成的随机数是0到999之间的整数。
        //在这段代码中，生成的随机数将被用于计算消息所在的分区编号。由于模运算 % cluster.partitionCountForTopic(topic) 的结果必须小于分区数量，因此这里对1000取模的目的是将随机数的范围缩小到分区数量内，以确保不会选择到超出范围的分区编号。
        return r.nextInt(1000) % cluster.partitionCountForTopic(topic);
    }

    @Override
    public void close() {
    
    }
}

En la configuración del productor de Kafka, personalice el nombre de clase del particionador personalizado:

props.put(ProducerConfig.PARTITIONER_CLASS_CONFIG, KeyWithRandomPartitioner.class.getName());

Mecanismo de reequilibrio del grupo de consumidores

  El reequilibrio en Kafka se denomina reequilibrio. Es un mecanismo en Kafka para garantizar que todos los consumidores del grupo Consumidor lleguen a un consenso y asignen cada partición del tema suscrito.

El momento de la activación del reequilibrio es:

• El número de consumidores en el grupo de consumidores cambia. Por ejemplo: se agrega un nuevo consumidor al grupo de consumidores o un consumidor se detiene.
  

• Si el número de temas suscritos cambia, los consumidores pueden suscribirse a varios temas. Supongamos que el grupo de consumidores actual se ha suscrito a tres temas, pero uno de ellos se elimina repentinamente. En este momento, también es necesario reequilibrar.

• 

• 
  
  Efectos adversos de Rebalance cuando cambia el número de particiones de temas suscritos :

• Cuando se produce el reequilibrio, todos los consumidores del grupo de consumidores se coordinarán y participarán juntos, y Kafka utiliza la estrategia de asignación para lograr la asignación más justa posible.

• El proceso de reequilibrio tendrá un impacto muy grave en el grupo de consumidores.Durante el proceso de reequilibrio, todos los consumidores dejarán de trabajar hasta que se complete el reequilibrio.

Estrategia de asignación de partición de consumidores

• Estrategia de asignación de rango
• Estrategia de sondeo RoundRobin
• Estrategia de asignación pegajosa de Stricky

Estrategia de asignación de rango

La estrategia de distribución de rango es la estrategia de distribución predeterminada de Kafka, que puede garantizar que la cantidad de particiones consumidas por cada consumidor esté equilibrada.

Nota : la estrategia de asignación de rango es para cada tema .

Configurar el consumidor partition.assignment.strategycomo org.apache.kafka.clients.consumer.RangeAssignor:

props.put("partition.assignment.strategy", "org.apache.kafka.clients.consumer.RangeAssignor");

Fórmula del algoritmo :

n = número de particiones / número de consumidores

m = número de particiones % número de consumidores

Los primeros m consumidores consumen n+1

Los consumidores restantes consumen n

Estrategia de sondeo RoundRobin

La estrategia de sondeo RoundRobinAssignor es ordenar las particiones de todos los consumidores en el grupo de consumidores y todos los temas   suscritos por los consumidores en orden lexicográfico (ordenar el código hash del tema y la partición), y luego asignar las particiones a cada consumidor.

Configurar el consumidor partition.assignment.strategycomo org.apache.kafka.clients.consumer.RoundRobinAssignor:

props.put("partition.assignment.strategy", "org.apache.kafka.clients.consumer.RoundRobinAssignor");

Estrategia de asignación pegajosa de Stricky

  A partir de Kafka 0.11.x, se introduce este tipo de estrategia de asignación. Propósito principal: la distribución de la partición es lo más uniforme posible.
  Cuando se produce un reequilibrio, la asignación de particiones sigue siendo la misma que la última asignación tanto como sea posible. Cuando no se produce un reequilibrio, la estrategia de asignación fija Striky es similar a la estrategia de asignación RoundRobin.

Si consumidor2 falla arriba, se debe realizar un reequilibrio en este momento. Si se trata de asignación de rango y asignación por turnos, ambas se reasignarán. Por ejemplo,

se puede encontrar que la mayoría de las particiones consumidas originalmente por consumidor0 y consumidor1 han cambiado. A continuación, veamos la estrategia de asignación rígida.

  La estrategia de asignación fija de Striky conserva los resultados de la asignación antes del reequilibrio. De esta manera, las dos particiones originalmente responsables de consumidor2 se distribuyen uniformemente a consumidor0 y consumidor1. Esto puede reducir significativamente el desperdicio de recursos del sistema.
  Por ejemplo: consumidor0 y consumidor1 consumían ciertas particiones antes, pero debido al reequilibrio, consumidor0 y consumidor1 necesitan volver a consumir las particiones que estaban procesando antes, lo que genera una sobrecarga innecesaria del sistema. (Por ejemplo: una transacción debe cancelarse si está en curso)

Mecanismo de replicación de Kafka

  El propósito de la copia es una copia de seguridad redundante. Cuando se pierden los datos de la partición en un Broker, aún se puede garantizar que los datos estén disponibles. Porque las réplicas en otros Brokers están disponibles.

Parámetro ACK del productor

Lo que es más relevante para la copia es el parámetro acks configurado por el productor.El parámetro acks indica el rigor de   escribir en la copia cuando el productor produce mensajes . Determina cómo los productores hacen concesiones entre rendimiento y confiabilidad .

// 配置ACKs参数
props.put("acks", "all");

acks está configurado como 0

acks = 0: el productor solo escribe, independientemente de si la escritura es exitosa o no, los datos pueden perderse. El rendimiento es de primera categoría.

ACK es 0, punto de referencia:

bin/kafka-producer-perf-test.sh --topic benchmark --num-records 5000000 --throughput -1 --record-size 1000 --producer-props bootstrap.servers=10.211.55.8:9092 acks=0

acks está configurado como 1

El productor esperará hasta que la partición líder se escriba con éxito, devolverá el éxito y luego enviará la siguiente, con un rendimiento medio.

acks está configurado como -1 o todos

Asegúrese de que el mensaje se escriba en la partición líder y que el mensaje se escriba correctamente en la réplica correspondiente, y luego envíe el siguiente. El rendimiento es el peor.

Resultados de referencia:

índice	Copia única de partición única (ack=0)	Copia única de partición única (ack=1)	Copia única de partición única (ack=-1/all)
rendimiento	47359,248314 registros/seg 4,7 W registros por segundo	40763.417279 registros/seg 4W registros por segundo	540,5 /s 7,3 W registro de tonos por segundo
Tasa de rendimiento	45,17 MB/s, aproximadamente 45 MB de datos por segundo	38,88 MB/s, unos 89 MB de datos por segundo	0,52 MB/s
latencia media	Latencia media de 686,49 ms	Latencia media de 799,67 ms	120281,8 ms
tiempo máximo de retardo	latencia máxima de 1444,00 ms	latencia máxima de 1961,00 ms	1884.00ms

  Seleccione el mecanismo de reconocimiento de acuerdo con la situación comercial, que requiere el mayor rendimiento y la pérdida de algunos datos tiene poco impacto, por lo que puede elegir 0/1. Si se requiere que los datos no se pierdan, se debe configurar como -1/todos.

  Existen los conceptos de líder y seguidor en la partición. Para garantizar que los datos consumidos por los consumidores sean consistentes, solo el líder de la partición puede leer y escribir mensajes. Lo que hace el seguidor es sincronizar datos y realizar copias de seguridad.

API de alto nivel y API de bajo nivel

API de alto nivel

• El consumo de mensajes de Kafka es fácil de implementar y relativamente simple de escribir.
• No hace falta ejecutar para gestionar el offset, y se gestiona directamente a través de ZK, no hace falta gestionar particiones y copias, y lo gestiona Kafka.
• Los consumidores seguirán obteniendo datos automáticamente según la última compensación guardada en ZK.
• En ZK, diferentes grupos de consumidores (grupos) registran diferentes compensaciones para un mismo tema, de modo que diferentes programas lean el mismo tema sin verse afectados por la compensación.
• Desventajas de la API avanzada: no puede controlar el desplazamiento, por ejemplo: quiere leer desde una ubicación específica; no puede controlar con precisión particiones, réplicas, ZK, etc.

// 消费者程序：从test主题中消费数据
public class ConsumerTest {
    
    
    public static void main(String[] args) {
    
    
        // 1. 创建Kafka消费者配置
        Properties props = new Properties();
        props.setProperty("bootstrap.servers", "192.168.88.100:9092");
        props.setProperty("group.id", "test");
        props.setProperty("enable.auto.commit", "true");
        props.setProperty("auto.commit.interval.ms", "1000");
        props.setProperty("key.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");
        props.setProperty("value.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");

        // 2. 创建Kafka消费者
        KafkaConsumer<String, String> consumer = new KafkaConsumer<>(props);

        // 3. 订阅要消费的主题
        consumer.subscribe(Arrays.asList("test"));

        // 4. 使用一个while循环，不断从Kafka的topic中拉取消息
        while (true) {
    
    
            // 定义100毫秒超时
            ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(100));
            for (ConsumerRecord<String, String> record : records)
                System.out.printf("offset = %d, key = %s, value = %s%n", record.offset(), record.key(), record.value());
        }
    }
}

API de bajo nivel

  Al usar la API de bajo nivel, podemos controlar el desplazamiento por nosotros mismos y podemos leer desde donde queramos.
  Además, puede controlar la partición de conexión usted mismo y personalizar el equilibrio de carga para la partición. Además, antes de que la compensación se guardara automáticamente en ZK, usando la API de bajo nivel, puede almacenar la compensación sin usar ZK y puede almacenar la compensación usted mismo.
  Por ejemplo: almacenado en un archivo, MySQL o en memoria. Sin embargo, la API de bajo nivel es más complicada, necesita ejecutar el desplazamiento de control, a qué partición conectarse y encontrar el líder de la partición.

Ejemplo de consumo manual de datos particionados:

  Antes de la API de alto nivel (High Level), permitíamos que Kafka asignara dinámicamente las particiones que se consumirían para el tema de acuerdo con los consumidores del grupo de consumo. Pero en algún momento, debe especificar la partición que se consumirá, por ejemplo: si un programa guarda los datos de una partición específica en un almacenamiento externo, como: Redis, MySQL, entonces, al guardar los datos, solo la partición especificada necesita para ser consumido Partición de los datos. Si un programa tiene alta disponibilidad, se reiniciará automáticamente cuando el programa falle (por ejemplo: programa Flink, Spark). En este caso, el programa se reiniciará consumiendo datos de la partición especificada.

Ya no use el método de suscripción anterior para suscribirse al tema, pero use el método de asignación para especificar el mensaje que desea consumir:

String topic = "test";
TopicPartition partition0 = new TopicPartition(topic, 0);
TopicPartition partition1 = new TopicPartition(topic, 1);
consumer.assign(Arrays.asList(partition0, partition1));

Una vez que se especifica la partición, se puede llamar al método de encuesta en un bucle para consumir mensajes como en el ejemplo anterior.

Nota :

Al administrar manualmente las particiones de consumo, incluso si el GroupID es el mismo, el coordinador de grupo de Kafka ya no funcionará.

Tampoco habrá reasignación automática de particiones si un consumidor falla.

Herramienta de monitoreo Kafka-eagle

  En el trabajo de desarrollo, cuando la premisa comercial no es complicada, puede usar los comandos de Kafka para administrar algunos clústeres. Pero si el negocio se complica, por ejemplo, es necesario agregar particiones de grupos y temas, es inconveniente usar la línea de comando en este momento.En este momento, si se usa una herramienta visual para ayudar a completar el trabajo de administración diario , mejorará en gran medida el rendimiento de Kafka, la eficiencia de la gestión de clústeres y el uso de herramientas para monitorear el consumo de los consumidores en Kafka.

  Kafka Eagle es una excelente herramienta de monitoreo de clústeres de Kafka de código abierto y gratuita, rediseñada mediante la combinación de las características de las herramientas de monitoreo de Kafka de big data actuales. Puede monitorear fácilmente el desplazamiento, los cambios de retraso, la distribución de particiones, el propietario, etc. en el entorno de producción. Dirección del sitio web oficial: https://www.kafka-eagle.org/

Instalar Kafka-Eagle

Abra el puerto Kafka JMX:

  JMX (Java Management Extensions) es un marco para incorporar funciones de gestión en las aplicaciones. JMX es un conjunto de agentes y servicios estándar, de hecho, los usuarios pueden utilizar estos agentes y servicios para implementar la gestión en cualquier aplicación Java. Muchos software proporcionan una interfaz JMX para realizar algunas funciones de gestión y supervisión.

Antes de iniciar el script de Kafka, agregue:
【Kafka】Message Queue Kafka Basics --> Se ha agregado la escritura de scripts de inicio/apagado de Kafka con un solo clic

cd ${KAFKA_HOME}
export JMX_PORT=9988
nohup bin/kafka-server-start.sh config/server.properties &

Instale Kafka-Eagle :

La base de datos mysql debe prepararse y crearse con anticipación ke. Instale JDK y configure JAVA_HOME.

# 将kafka_eagle上传，并解压到 /export/server 目录中。
cd cd /export/software/
tar -xvzf kafka-eagle-bin-3.0.1.tar.gz -C ../server/

cd /export/server/kafka-eagle-bin-3.0.1/ 
tar -xvzf efak-web-3.0.1-bin.tar.gz 
cd /export/server/kafka-eagle-bin-3.0.1/efak-web-3.0.1

# 配置 kafka_eagle 环境变量。
vim /etc/profile
export KE_HOME=/export/server/kafka-eagle-bin-1.4.6/kafka-eagle-web-1.4.6
export PATH=$PATH:$KE_HOME/bin
source /etc/profile

Configurar kafka_eagle. Use vi para abrir el directorio confsystem-config.properties

vim conf/system-config.properties
# 修改第4行，配置kafka集群别名
kafka.eagle.zk.cluster.alias=cluster1
# 修改第5行，配置ZK集群地址
cluster1.zk.list=node1.itcast.cn:2181,node2.itcast.cn:2181,node3.itcast.cn:2181
# 注释第6行
#cluster2.zk.list=xdn10:2181,xdn11:2181,xdn12:2181
# 修改第32行，打开图标统计
kafka.eagle.metrics.charts=true
kafka.eagle.metrics.retain=30

# 注释第69行，取消sqlite数据库连接配置
#kafka.eagle.driver=org.sqlite.JDBC
#kafka.eagle.url=jdbc:sqlite:/hadoop/kafka-eagle/db/ke.db
#kafka.eagle.username=root
#kafka.eagle.password=www.kafka-eagle.org

# 修改第77行，开启mysql
kafka.eagle.driver=com.mysql.jdbc.Driver
kafka.eagle.url=jdbc:mysql://10.211.55.8:3306/ke?useUnicode=true&characterEncoding=UTF-8&zeroDateTimeBehavior=convertToNull
kafka.eagle.username=root
kafka.eagle.password=52809329

# 启动脚本`ke.sh`中配置JAVA_HOME：
cd /export/server/kafka-eagle-bin-3.0.1/efak-web-3.0.1/bin

vim ke.sh
# 在第24行添加JAVA_HOME环境配置
export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-arm64

# 修改Kafka eagle可执行权限
cd /export/server/kafka-eagle-bin-3.0.1/efak-web-3.0.1/bin
chmod +x ke.sh

# 启动 kafka_eagle
./ke.sh start

#访问Kafka eagle，默认用户为admin，密码为：123456
http://10.211.55.8:8048/ke

Lista de temas de métricas de Kafka en la interfaz de Kafka eagle :
haga clic en el menú Lista en Tema para mostrar todos los temas en el clúster de Kafka actual.

índice	significado
Propagación de los corredores	Utilización del corredor
Corredores sesgados	Si la partición está sesgada
Sesgo del líder de los corredores	¿Hay alguna inclinación en la partición líder?

principio de kafka

Líder y seguidor de partición

  En Kafka, cada tema se puede configurar con múltiples particiones y múltiples copias.
  Cada partición tiene un líder y cero o más seguidores. Al crear un tema, Kafka distribuirá uniformemente el líder de cada partición a cada intermediario.
  El uso normal de kafka no siente la existencia de líder y seguidor. Pero, de hecho, todas las operaciones de lectura y escritura son manejadas por el líder, y todos los seguidores copian los archivos de datos de registro del líder.Si el líder falla, el seguidor será elegido como líder.

Resumen :

• El líder en Kafka es responsable de procesar las operaciones de lectura y escritura, mientras que el seguidor solo es responsable de la sincronización de los datos de réplica.
• Si el líder falla, otros seguidores serán reelegidos como líder.
• Al igual que un consumidor, el seguidor extrae los datos correspondientes a la partición del líder y los guarda en el archivo de datos de registro.

Compruebe en qué servidor se encuentra el líder de una partición:

Tema de ejemplo llamado prueba con 3 particiones y 3 réplicas.

AR, ISR, OSR

  En el entorno actual, el líder puede tener algunas fallas, por lo que Kafka definitivamente elegirá un nuevo líder.
  En Kafka, los seguidores se pueden dividir en tres categorías según diferentes estados: AR, ISR, OSR.

• Todas las réplicas de una partición se llaman AR( Assigned Replicasréplicas asignadas)
• Todas las réplicas (incluida la réplica líder) que están sincronizadas con la réplica líder hasta cierto punto ISR( In-Sync Replicasréplicas sincronizadas)
• Composición de las réplicas (excluidas las réplicas líderes) debido al retraso en la sincronización de las réplicas seguidoras OSR( Out-of-Sync Replias)
• AR = ISR + OSR
• Normalmente, todas las réplicas de los seguidores deben estar sincronizadas con la réplica del líder, es decir AR = ISR, OSRel conjunto está vacío.

En Kafka, (C) es el LEO más pequeño de la cola ISR.
A. LEO

B. ISR

C. HW

D AR

A: LEO: representa la siguiente entrada en el archivo de registro actual, en referencia al desplazamiento máximo de cada copia

B: ISR: representa la cola de sincronización de copia

C: HW: se refiere al desplazamiento más grande que los consumidores pueden ver, el LEO más pequeño en la cola de ISR, y C es correcto .

D: AR: representa todas las réplicas

Controlador

  Cuando se inicie Kafka, se seleccionará un Controlador entre todos los intermediarios. El líder anterior y el seguidor son para la partición, mientras que el Controlador es para el intermediario.
  El controlador realiza todas las tareas de administración, como la creación de temas, la adición de particiones y la modificación del número de réplicas. La elección del líder de la partición de Kafka también la decide el Contralor.

Elección del controlador

  Cuando se inicia el clúster de Kafka, cada corredor intentará registrarse como controlador (nodo temporal ZK) en ZooKeeper, pero solo uno tiene éxito en la competencia y otros corredores registrarán el monitor del nodo. Una vez que cambia el estado del nodo temporal, se puede realizar el procesamiento correspondiente. El Controlador también tiene una alta disponibilidad. Una vez que un corredor falla, otros corredores se volverán a registrar como Controladores.

Encuentre el controlador del clúster de Kafka actual: vaya al
menú Herramientas de Kafka Tools, busque el navegador ZooKeeper y verifique qué agente es el controlador.

El controlador elige el líder de la partición:

• La elección del líder de todas las particiones la decide el Contralor
• El Controller notificará directamente al Broker que deba responder al cambio de líder a través de RPC
• El controlador lee el ISR de la partición actual y, mientras sobreviva una réplica, selecciona a una de ellas como líder; de lo contrario, selecciona aleatoriamente esta réplica como líder.
• Si todas las réplicas de la partición están inactivas, el nuevo líder es -1

  Específicamente, cuando falla la copia líder de una partición, la copia seguidora lo descubrirá y enviará una solicitud a otros nodos intermediarios para solicitar convertirse en el nuevo líder de la partición. Al mismo tiempo, cada nodo intermediario enviará periódicamente una solicitud de latido al nodo controlador para informar su estado actual e información de disponibilidad. El nodo del controlador seleccionará un nodo intermediario en buen estado y disponible como el nuevo líder de la partición en función de esta información.

En el proceso de elección de un nuevo líder, el nodo Controlador se referirá a los siguientes factores :

• Estado de réplica: solo las réplicas de seguidores en la lista ISR (réplicas sincronizadas) son elegibles para convertirse en el nuevo líder porque sus datos se han sincronizado con el líder.
• Ubicación de la copia: el nodo del controlador elegirá la misma ubicación o una anterior que la copia del líder original como la ubicación del nuevo líder para garantizar una pérdida de datos mínima.
• Estado de salud de la réplica: el nodo del controlador seleccionará preferentemente un nodo de intermediario disponible y en buen estado como el nuevo líder para garantizar una alta disponibilidad y calidad de servicio.

  En resumen, el nodo del controlador considerará múltiples factores y seleccionará el nodo intermediario que sea más adecuado para convertirse en el nuevo líder, a fin de garantizar la alta disponibilidad y estabilidad del clúster de Kafka.

¿Por qué ZK no puede elegir al líder de la partición?

  Si el clúster de Kafka tiene muchos negocios, habrá muchas particiones. Suponiendo que un determinado corredor esté inactivo, muchas particiones necesitarán reelegir al líder. Si se utiliza Zookeeper para elegir al líder, ejercerá una gran presión sobre Zookeeper. Por lo tanto, la elección de líder en Kafka no se puede implementar utilizando ZK.

Cuando la partición previamente fuera de línea vuelve a estar en línea, se debe realizar una elección de líder y la estrategia de elección es ( A ).
A. Elección de líder de partición fuera de línea

B. Reasignación de elección de líder de partición

C. Elección del líder de la partición PreferredReplica

D. Elección del líder de la partición de cierre controlado

La elección de la copia líder de la partición es completamente transparente para el usuario y el Controlador la realiza de forma independiente.

A: Elección de líder de partición fuera de línea: la elección de líder debe realizarse cada vez que una partición se conecta. La denominada partición en línea puede ser la creación de una nueva partición, o puede ser que la partición que antes estaba fuera de línea se haya vuelto a poner en línea.La opción A es correcta.

B: Elección de líder de reasignación de partición: cuando ejecuta manualmente el comando kafka-reassign-partitions, o llama al método alterPartitionReassignments de Admin para realizar la reasignación de copia de partición, este tipo de elección puede activarse.

C: Elección de líder de PreferredReplicaPartition: cuando ejecuta manualmente el comando kafka-preferred-replica-election o activa automáticamente la elección de líder preferido, este tipo de política se activa.

D: Elección de líder de partición de cierre controlado: cuando un bróker se apaga normalmente, todas las copias de líder en el bróker se desconectarán, por lo tanto, es necesario realizar una elección de líder correspondiente para la partición afectada.

La solicitud enviada por el Controlador al Corredor no incluye ( D ).

A. Solicitud de líder e Isr

B. Solicitud de detención de réplica

C. Solicitud de actualización de metadatos

D. Número de controladores activos

El controlador enviará tres tipos de solicitudes al intermediario, a saber, LeaderAndIsrRequest, StopReplicaRequest y UpdateMetadataRequest .
A: LeaderAndIsrRequest: Indíquele al Broker en qué Broker está ubicada la copia del líder de cada partición y en qué Broker están ubicadas las copias en el ISR.

B: StopReplicaRequest: dígale al agente especificado que detenga el objeto de réplica en él, y la solicitud puede incluso eliminar los datos de registro subyacentes de la réplica.

C: UpdateMetadataRequest: esta solicitud actualiza la memoria caché de metadatos en el bróker.

D: ActiveControllerCount es un indicador de monitoreo en el lado del corredor , no una solicitud enviada, por lo que la opción D no está incluida.

equilibrio de carga líder

Réplica preferida

  Kafka introduce un preferred-replicaconcepto llamado , que significa: la réplica preferida está
  en la lista ISR, la primera réplica es la réplica preferida y el agente almacenado en la primera partición debe ser la réplica preferida.

Ejecute el siguiente script para establecer la réplica preferida como líder y distribuir uniformemente los líderes de cada partición.

./kafka-leader-election.sh --bootstrap-server node1.itcast.cn:9092 --topic 主题 --partition=1 --election-type preferred

Asegúrese de que el líder tenga equilibrio de carga entre los corredores:

Mata a un corredor del tema de prueba, para que Kafka reasigne al líder. Después de que Kafka reasigne al líder, vuelva a iniciar el proceso de Kafka. En este punto: Observe la distribución del líder de cada partición del tema de prueba.

En este momento, la distribución del líder será desigual, por lo que se puede ejecutar el siguiente script para redistribuir el líder:

bin/kafka-leader-election.sh --bootstrap-server 10.211.55.8:9092 --topic test --partition=1 --election-type preferred
# Successfully completed leader election (PREFERRED) for partitions test-1

–partición: Especifique el número de partición que necesita reasignar el líder:

Producción de Kafka, flujo de trabajo de datos de consumo

Proceso de escritura de datos de Kafka

• El productor primero encuentra el líder de la partición desde el nodo "/brokers/topics/topic name/partitions/partition name/state" de zookeeper:

• El productor encuentra el ID en ZK para encontrar el corredor correspondiente:

• El líder del proceso del intermediario escribe el mensaje en el registro local.
• El seguidor extrae el mensaje del líder, lo escribe en el registro local y envía un ACK al líder
• Después de que el líder recibe los ACK de todas las réplicas en el ISR, devuelve los ACK al productor.

Proceso de consumo de datos de Kafka

Dos modos de consumo

  Kafka adopta el modelo de extracción , y el consumidor registra el estado de consumo por sí mismo, y cada consumidor extrae los mensajes de cada partición de forma independiente y secuencial. Los consumidores pueden consumir mensajes en cualquier orden. Por ejemplo, los consumidores pueden restablecer la compensación anterior y reprocesar los mensajes que se han consumido anteriormente, o saltar directamente a la ubicación más cercana y comenzar a consumir desde el momento actual.

• Cada consumidor puede obtener la partición a consumir según la estrategia de asignación (RangeAssignor por defecto)
• Obtener la compensación correspondiente al consumidor (por defecto, la compensación del último consumo se obtiene de ZK)
• Encuentre el líder de la partición y extraiga los datos.
• El consumidor envía una compensación
  

Formulario de almacenamiento de datos de Kafka

  Un tema consta de varias particiones. Una partición (partición) consta de varios segmentos (segmentos) y un segmento (segmento) consta de varios archivos (registro, índice, índice de tiempo).

registro de almacenamiento

  Los datos en Kafka se almacenan en /export/server/kafka_2.12-2.4.1/data(instalados en la configuración del archivo de configuración), los mensajes se almacenan en 主题名-分区IDla carpeta con: y la carpeta de datos contiene el siguiente contenido:

Nombre del archivo	ilustrar
00000000000000000000.índice	Archivo de índice, los datos de búsqueda según el desplazamiento se operan a través del archivo de índice
00000000000000000000.log	archivo de registro de datos
00000000000000000000.timeindex	índice de tiempo
líder-época-punto de control	Persistir el LEO correspondiente a cada líder de partición (desplazamiento de final de registro, desplazamiento del siguiente mensaje que se escribirá en el archivo de registro)

• El nombre de archivo de cada archivo de registro es el desplazamiento inicial, porque el desplazamiento inicial de cada partición es 0, por lo que los archivos de registro de la partición comienzan 0000000000000000000.logcon

• El tamaño máximo predeterminado de cada archivo de registro es log.segment.bytes =1024102410241G

• Para simplificar la búsqueda de mensajes basados ​​en el desplazamiento, el nombre del archivo de registro de Kafka está diseñado como el desplazamiento inicial

Prueba: cree un nuevo tema: test_10m, el tamaño máximo de cada archivo de datos de registro para este tema es 10M

bin/kafka-topics.sh --create --zookeeper 10.211.55.8 --topic test_10m --replication-factor 2 --partitions 3 --config segment.bytes=10485760

Utilice el programa productor anterior para producir datos en el tema test_10m:

Escribir mensaje: los mensajes nuevos siempre se escriben en el último archivo de registro y, si el archivo alcanza el tamaño especificado (predeterminado: 1 GB), se transferirá a un archivo nuevo.

leer el mensaje

De acuerdo con el desplazamiento, primero debe encontrar el segmento del segmento que almacena los datos (nota: el desplazamiento especifica el desplazamiento global de la partición )
y luego encontrar el desplazamiento del segmento del segmento en relación con el archivo de acuerdo con el desplazamiento de la partición global

: finalmente lea el mensaje de acuerdo con el desplazamiento del segmento del segmento

borrar mensaje

  En Kafka, los mensajes se limpian periódicamente. Para eliminar archivos de registro de un segmento a la vez, el administrador de registros de Kafka determinará qué archivos se pueden eliminar de acuerdo con la configuración de Kafka.

Sin mecanismo de pérdida de mensajes

• Los datos del corredor no se pierden
• Los datos del productor no se pierden
• Los datos del consumidor no se pierden

Los datos del corredor no se pierden

  Después de que el productor escriba datos a través del líder de la partición, todos los seguidores en el ISR copiarán los datos del líder. De esta manera, se puede asegurar que incluso si el líder falla, los datos de otros seguidores seguirán estando disponibles.

Los datos del productor no se pierden

  Cuando el productor se conecta al líder para escribir datos, puede usar el mecanismo ACK para asegurarse de que los datos se hayan escrito correctamente. El mecanismo ACK tiene tres configuraciones opcionales:

• Al configurar el requisito de respuesta ACK para que sea -1, significa que todos los nodos han recibido los datos (tanto el líder como el seguidor han recibido
  los datos)

• Al configurar el requisito de respuesta ACK para que sea 1, indica que el líder ha recibido datos

• Cuando el requisito de impacto de ACK de configuración es 0, el productor solo es responsable de enviar datos y no le importa si los datos se pierden (en este caso, puede
  ocurrir una pérdida de datos, pero el rendimiento es el mejor)

Los productores pueden enviar datos de dos formas: síncrona y asíncrona:

• Sincronización: después de enviar un lote de datos a kafka, espere a que kafka devuelva el resultado
• Asíncrono: envíe un lote de datos a Kafka, solo proporcione una función de devolución de llamada.

Nota: si el corredor no da confirmación durante mucho tiempo y el búfer está lleno, el desarrollador puede establecer si desea borrar directamente los datos en el búfer.

Los datos del consumidor no se pierden

Cuando los consumidores consumen datos, siempre que cada consumidor registre el valor de compensación, se puede garantizar que los datos no se perderán.

acumulación de datos

  Los consumidores de Kafka consumen datos muy rápido, pero si hay algunos IO externos o congestión de la red al procesar los mensajes de Kafka, se producirán retrasos en los datos (o acumulación de datos) en Kafka. Si los datos se han atrasado, el rendimiento en tiempo real de los datos se verá muy afectado.

Etiqueta de retraso

Resolver el problema de acumulación de datos

Cuando Kafka tiene un problema de acumulación de datos, primero busque la causa de la acumulación de datos. Los siguientes son algunos escenarios de clase en los que se producen retrasos en los datos en una empresa.

Error al escribir datos en MySQL


Descripción del problema :
un día, el personal de operación y mantenimiento encontró al desarrollador y dijo que se había producido una acumulación de datos en una partición de un tema determinado. Este tema era muy importante y los usuarios comenzaron a quejarse. La operación y el mantenimiento estaban muy nerviosos, así que reinicié rápidamente la máquina. Después de reiniciar, todavía no ayuda.

Análisis del problema :

El código para consumir este tema es relativamente simple, principalmente consume datos del tema y luego emite juicios y realiza operaciones de base de datos. La operación y el mantenimiento encontraron el tema de la acumulación a través de kafka-eagle y encontraron que una determinada partición del tema tenía una acumulación de cientos de miles de mensajes.
Finalmente, al verificar los registros, se encuentra que el desplazamiento de la partición de consumo no se envió desde que los datos se escribieron en MySQL y se informó un error, por lo que la acumulación de datos es grave.

Descripción del problema debido a una falla en el consumo de retardo de la red :

El sistema desarrollado en base a Kafka ha estado funcionando sin problemas durante dos meses, de repente, un día, se encuentra que hay una acumulación de mensajes en un tema determinado, y hay alrededor de decenas de miles de mensajes que no se han consumido.

Análisis del problema :

Al verificar el registro de la aplicación, se encuentra que hay una gran cantidad de fallas de tiempo de espera de consumo. Después de averiguar el motivo, porque la red estaba inestable ese día, la configuración del tiempo de espera del consumidor de Kafka se estableció en 50 ms, y luego el problema se resolvió cambiando el tiempo de consumo a 500 ms.

Limpieza de datos en Kafka (Borrado de registro)

  Los mensajes de Kafka se almacenan en el disco.Para controlar el espacio ocupado por el disco, Kafka necesita limpiar constantemente algunos mensajes pasados. Cada partición de Kafka tiene una gran cantidad de archivos de registro, lo que también es conveniente para la limpieza de registros. En Kafka, se proporcionan dos métodos de limpieza de registros:

• Eliminación de registros (Eliminación de registros): elimine directamente los registros no calificados de acuerdo con la política especificada. La eliminación de registros se realiza periódicamente en unidades de segmentos (registros de segmento).

• Log Compaction: Consolida según la clave del mensaje, para aquellos con la misma clave pero valores diferentes, solo se mantiene la última versión.

En la configuración de broker o tema de Kafka:

elemento de configuración	valor de configuración	ilustrar
registro.limpiador.habilitar	verdadero (predeterminado)	Activar la función de limpieza automática de registros
log.cleanup.policy	eliminar (predeterminado)	borrar registro
log.cleanup.policy	compactación	registro comprimido
log.cleanup.policy	eliminar, compactar	Soporta eliminación y compresión al mismo tiempo

Tareas de eliminación de registros programadas

  Habrá una tarea de eliminación de registros dedicada en el administrador de registros de Kafka para detectar y eliminar periódicamente los archivos de segmentos de registros que no cumplen las condiciones de retención. Este ciclo se puede configurar a través de parámetros del lado del intermediario. El valor predeterminado es 300 000, que es de 5 minutos. log.retention.check.interval.ms.

  Existen tres estrategias de retención para los segmentos de registro actuales:

• Política de retención basada en el tiempo

• Política de retención basada en el tamaño del registro

• Política de retención basada en el desplazamiento de inicio de registro

Política de retención basada en el tiempo

  Las siguientes tres configuraciones pueden especificar que si los mensajes en Kafka superan el umbral especificado, el registro se limpiará automáticamente: log.retention.hours, log.retention.minutes, log.retention.ms.
  Entre ellos, la prioridad es log.retention.ms $>$ log.retention.minutes $>$ log.retention.hours。

  Por defecto, en el broker, la configuración es la siguiente: log.retention.hours=168. Es decir, el tiempo de retención de registros predeterminado es de 168 horas, lo que equivale a 7 días.

  Al eliminar segmentos de registro: elimine los segmentos de registro que se eliminarán de la tabla de salto de segmento de registro mantenida en el objeto de archivo de registro, para garantizar que ningún subproceso lea estos segmentos de registro. Agregue el sufijo ".deleted" al archivo de segmento de registro (incluido el archivo de índice correspondiente al segmento de registro)

  La tarea de temporización en segundo plano de Kafka eliminará periódicamente estos archivos con el sufijo ".deleted". El tiempo de ejecución de demora de esta tarea se puede configurar file.delete.delay.msmediante parámetros. El valor predeterminado es 60000, que es 1 minuto.

Establecer tema para eliminar una vez cada 5 segundos :

Para facilitar la observación, establezca el tamaño del archivo de segmento en 1M

y establezca la política de eliminación del tema: key: retention.ms value: 5000

  intente agregar algunos datos al tema, espere un momento y observe la eliminación del registro. Se puede ver que los registros se marcan periódicamente para su eliminación y luego se eliminan.

Política de retención basada en el tamaño del registro

  La tarea de eliminación de registros verificará si el tamaño del registro actual excede el umbral establecido para encontrar la colección de archivos de segmentos de registro que se pueden eliminar. Se puede configurar a través de parámetros del lado del corredor log.retention.bytesy el valor predeterminado es -1, lo que significa infinito. Si se supera este tamaño, el exceso se eliminará automáticamente.

Nota :
log.retention.byteslo que se configura es el tamaño total del archivo de registro, no el tamaño de un solo segmento de registro. Un archivo de registro contiene varios segmentos de registro.

Política de retención basada en el desplazamiento de inicio de registro

  Cada registro de segmento tiene su compensación de inicio, si la compensación de inicio es menor que logStartOffset, estos archivos de registro se marcarán para su eliminación.

Compresión de registro

  Log Compaction es una forma de limpiar datos obsoletos que no sean la eliminación de registros predeterminada. Solo conservará una versión de los datos correspondientes a la misma clave.

• Después de ejecutar la compactación de registros, el desplazamiento ya no será continuo, pero aún se puede consultar el segmento
• Antes y después de ejecutar Log Compaction, el desplazamiento de cada mensaje en el segmento de registro permanece sin cambios. Log Compaction generará un nuevo archivo de segmento
• Log Compaction es para la clave. Al usarlo, preste atención a que la clave de cada mensaje no esté vacía
• Según Log Compaction, se puede conservar la última actualización de la clave y se puede restaurar el estado más reciente de los consumidores según Log Compaction

Con respecto a la declaración de Kafka sobre la limpieza de datos caducados, el error es (B)

A. Las estrategias de limpieza incluyen eliminación y compresión.

B. Después de habilitar la política de compresión, solo se conservan los datos de la versión especificada de cada clave.

C. log.cleanup.policy=delete habilitar política de eliminación

D. log.cleanup.policy=compact habilita la política de compactación.

B. Después de habilitar la política de compresión, solo se conservan los datos de la última versión de cada clave

Mecanismo de límite de velocidad de cuotas de Kafka (Cuotas)

  Los productores y consumidores producen/consumen una gran cantidad de datos o generan solicitudes a una velocidad muy alta, ocupando así todos los recursos del intermediario y provocando la saturación de E/S de la red. Con las cuotas (Cuotas) se pueden evitar estos problemas. Kafka es compatible con la gestión de cuotas, de modo que puede limitar el flujo de operaciones de producción y obtención de Productor y Consumidor para evitar que las empresas individuales saturen el servidor.

Limite la tasa del lado del productor

Establezca el valor predeterminado para todos los ID de cliente. A continuación, se establece el TPS para todos los programas productores en no más de 1 MB/s, es decir, 1048576/s. El comando es el siguiente:

bin/kafka-configs.sh --zookeeper node1.itcast.cn:2181 --alter --add-config 'producer_byte_rate=1048576' --entity-type clients --entity-default

Ejecute un punto de referencia para observar la tasa de mensajes de producción:

bin/kafka-producer-perf-test.sh --topic test --num-records 500000 --throughput -1 --record-size 1000 --producer-props bootstrap.servers=node1.itcast.cn:9092,node2.itcast.cn:9092,node3.itcast.cn:9092 acks=1

# 结果：50000 records sent, 1108.156028 records/sec (1.06 MB/sec)

Limite la tarifa final del consumidor

  El límite de velocidad para el consumidor es similar al del productor, pero el nombre del parámetro es diferente. Para limitar la velocidad del tema especificado, lo siguiente establece que la velocidad del tema para todos los programas de consumo no supere 1 MB/s, es decir, 1048576/s. El comando es el siguiente:

bin/kafka-configs.sh --zookeeper node1.itcast.cn:2181 --alter --add-config 'consumer_byte_rate=1048576' --entity-type clients --entity-default

Ejecute el punto de referencia:

bin/kafka-consumer-perf-test.sh --broker-list node1.itcast.cn:9092,node2.itcast.cn:9092,node3.itcast.cn:9092 --topic test --fetch-size 1048576 --messages 500000

#结果为：MB.sec：1.0743

Cancelar la configuración de Cuota de Kafka

Use el siguiente comando para eliminar la configuración de Cuota de Kafka:

bin/kafka-configs.sh --zookeeper node1.itcast.cn:2181 --alter --delete-config 'producer_byte_rate' --entity-type clients --entity-default

bin/kafka-configs.sh --zookeeper node1.itcast.cn:2181 --alter --delete-config 'consumer_byte_rate' --entity-type clients --entity-default