¿Quieres conocer la configuración dinámica de Kafka de Alibaba Daniel?
Antes de comenzar a compartir, primero revisemos el método para configurar los parámetros de Kafka, especialmente los parámetros del lado del Broker.
En la ruta de configuración del directorio de instalación de Kafka, hay un archivo server.properties. Normalmente, especificaremos la ruta de este archivo para iniciar Broker. Si queremos establecer algún parámetro en el lado del Broker, debemos agregar explícitamente una línea de configuración correspondiente a este archivo y luego iniciar el proceso del Broker para que los parámetros surtan efecto. Nuestro enfoque común es configurar todos los parámetros a la vez y luego iniciar el Broker. Cuando sea necesario cambiar algún parámetro más adelante, debemos reiniciar el Broker. Pero, ¿cómo se puede reiniciar a voluntad un servidor en un entorno de producción? Por lo tanto, modificar los parámetros del lado del corredor es actualmente un proceso muy doloroso.
Basándose en este problema, la comunidad introdujo oficialmente los parámetros dinámicos del Broker (Dynamic BrokerConfigs) en la versión 1.1.0. La llamada dinámica significa que después de modificar el valor del parámetro, entrará en vigor inmediatamente sin reiniciar el Broker. Los parámetros configurados previamente en server.properties se denominan parámetros estáticos (Configuraciones estáticas). Obviamente, ajustar dinámicamente los valores de los parámetros sin reiniciar el servicio es una función muy práctica. Si desea experimentar parámetros dinámicos del Broker, actualice a la versión 1.1 lo antes posible.
Por supuesto, hay más de 200 parámetros del lado del corredor en la última versión 2.3. La comunidad no ha actualizado todos los parámetros a parámetros dinámicos, solo algunos parámetros se pueden ajustar dinámicamente. Entonces, ¿cómo deberíamos saber qué parámetros son parámetros dinámicos?
Si abre el sitio web oficial de Kafka después de la versión 1.1 (incluida la 1.1), encontrará que la columna Modo de actualización dinámica se ha agregado a la tabla Configuraciones del corredor. Esta columna tiene 3 tipos de valores: de solo lectura, por corredor y para todo el clúster. Déjame explicarte lo que significan.
Permítanme dar un ejemplo para ilustrar la diferencia entre por corredor y en todo el clúster. Debe estar familiarizado con los oyentes de parámetros del lado del Broker. Es un parámetro por corredor, lo que significa que solo puede ajustar dinámicamente los oyentes de un único Broker y no puede ajustar directamente los oyentes de un lote de Brokers. El parámetro log.retention.ms está en el nivel de todo el clúster. Kafka le permite establecer de manera uniforme un valor de tiempo de retención de registros para todos los corredores del clúster. Por supuesto, también puedes modificar este valor para un único Broker.
Quizás se pregunte, ¿cuáles son los escenarios de uso de los parámetros dinámicos del Broker? De hecho, debido a que no es necesario reiniciar el Broker, los escenarios de uso de los parámetros dinámicos del Broker son muy amplios y generalmente incluyen, entre otros, los siguientes:
En estos escenarios de uso, ajuste dinámico del grupo de subprocesos El tamaño debe considerarse como la función más práctica. Muchas veces, cuando el tráfico entrante de KafkaBroker (datos entrantes) aumenta, provocará una acumulación de solicitudes en el lado del Broker (acumulación de pedidos). Con parámetros dinámicos, podemos aumentar dinámicamente la cantidad de subprocesos de red y subprocesos de E/S para consumir rápidamente parte del trabajo pendiente. Cuando pasa la ráfaga de tráfico, también podemos ajustar la cantidad de subprocesos para reducir el desperdicio de recursos. Todo el proceso no requiere reiniciar el Broker. Incluso puede encapsular este conjunto de acciones para ajustar la cantidad de subprocesos en tareas programadas para lograr la expansión y contracción automática.
Debido a la particularidad de la configuración dinámica, esta debe tener un mecanismo de guardado diferente al de los parámetros ordinarios de solo lectura. Permítanme presentarles cómo Kafka guarda la configuración dinámica.
Primero, Kafka guarda los parámetros dinámicos del Broker en ZooKeeper. La ruta específica del znode se muestra en la siguiente figura.
Déjame explicarte lo que hay en la imagen. Los cambios se usan para monitorear cambios dinámicos de parámetros en tiempo real y no guardan valores de parámetros. Se usan para guardar parámetros a nivel de tema de Kafka. Aunque no son parámetros dinámicos del lado del Broker, en realidad se pueden cambiar dinámicamente.
los usuarios y clientes son nodos znode que se utilizan para ajustar dinámicamente las cuotas de clientes (Cuota). La llamada cuota se refiere a que el personal de operación y mantenimiento de Kafka limita el rendimiento de los clientes conectados al clúster o limita los recursos de CPU que utilizan.
Después de analizar esto, encontraremos que /config/brokers znode es el lugar donde realmente se guardan los parámetros dinámicos del Broker. Hay dos tipos principales de nodos secundarios en este znode. Sólo hay un nodo secundario del primer tipo, que tiene un nombre fijo llamado
Echemos un vistazo a una imagen que muestra los parámetros dinámicos del lado del Broker en uno de mis entornos de clúster Kafka.
En esta imagen, primero miré los subnodos en /config/brokers. Podemos ver que hay nodos
A continuación, muestro la configuración de los parámetros para el alcance de todo el clúster y el alcance por corredor, respectivamente. Tomando el parámetro num.io.threads como ejemplo, su valor en todo el clúster se ajusta dinámicamente a 12 y se establece en 16 en el Broker 0 y en 8 en el Broker 1. Los valores que configuro individualmente para el Broker 0 y el Broker 1 anularán el valor de todo el clúster, pero en otros Brokers, el valor predeterminado de este parámetro aún se calcula como 12.
Si agregamos parámetros estáticos y los analizamos juntos, la prioridad de los parámetros estáticos, por intermediario y de todo el clúster es la siguiente: parámetros por intermediario > parámetros de todo el clúster > parámetros estáticos > valor predeterminado de Kafka .
Además, si observas detenidamente los campos ephemeralOwner en la imagen de arriba, encontrarás que sus valores son 0x0. Esto significa que estos znodes son nodos persistentes y siempre existirán. Incluso si se reinicia el clúster de ZooKeeper, estos datos no se perderán, asegurando así que los valores de estos parámetros dinámicos siempre serán efectivos.
Después de hablar sobre el principio de guardar, hablemos de cómo configurar los parámetros dinámicos del Broker. Actualmente, solo existe un comando de línea de herramientas para configurar parámetros dinámicos, que es el script kafka-configs que viene con Kafka. A continuación, permítanme tomar el parámetro unclean.leader.election.enable como ejemplo para demostrar cómo ajustarlo dinámicamente.
El siguiente comando muestra cómo establecer valores globales a nivel de clúster, es decir, establecer valores de rango para todo el clúster.
En general el comando es muy sencillo, pero hay una cosa a tener en cuenta. Si desea establecer parámetros dinámicos para todo el clúster, debe especificar explícitamente la entidad predeterminada. Ahora, usamos el siguiente comando para verificar si la configuración de ahora es exitosa.
Desde la salida, configuramos con éxito el valor del parámetro en verdadero a nivel global. Tenga en cuenta la palabra sensible = falso, que indica que el parámetro que queremos ajustar no son datos confidenciales. Si ajustamos parámetros como las contraseñas, este campo será verdadero, indicando que se trata de datos sensibles.
Ok, después de ajustar los parámetros de todo el clúster, permítanme demostrarles cómo configurar los parámetros de rango por corredor. Sigamos tomando el parámetro unclean.leader.election.enable como ejemplo. Ahora establezco un valor diferente para el Broker con ID 1. El comando es el siguiente:
De manera similar, usamos el siguiente comando para verificar si la configuración acaba de surtir efecto.
La salida de este comando es mucha información. Centrémonos en dos puntos.
Si queremos eliminar el parámetro de rango de todo el clúster o el parámetro de rango por corredor, también es muy simple: simplemente ejecute los siguientes comandos respectivamente.
Para eliminar parámetros dinámicos, se debe especificar delete-config. Después de eliminar la configuración de los parámetros dinámicos, ejecute el comando de vista nuevamente y los resultados son los siguientes:
En este momento, todos los parámetros dinámicos recién configurados se han eliminado con éxito.
Acabo de dar un ejemplo de parámetros. Si desea saber cuáles son los parámetros dinámicos del Broker, una forma es ver la lista de parámetros del lado del Broker en el sitio web oficial de Kafka y la otra es ejecutar. directamente Kafka-configs script sin parámetros La documentación de este script le indicará cuáles son los parámetros dinámicos actuales del Broker. Primero podemos echar un vistazo a las dos imágenes siguientes.
Al ver que hay tantos parámetros dinámicos del Broker, puedes preguntarte: ¿Necesito ajustarlos todos? ¿Puedes decirme cuáles son los más utilizados? Según mi experiencia de uso real, permítanme compartir con ustedes algunos parámetros que tienen mayores posibilidades de ajustarse dinámicamente.
1.log.retention.ms.
La modificación del tiempo de retención de registros debe considerarse una operación de frecuencia relativamente alta. Después de todo, es imposible para nosotros estimar perfectamente el tiempo de retención de mensajes para todas las empresas. Aunque este parámetro tiene parámetros correspondientes a nivel de tema que se pueden configurar, la capacidad de cambiarlo dinámicamente a nivel global sigue siendo una buena característica destacada.
2.num.io.threads y num.network.threads.
Estos son los dos conjuntos de grupos de subprocesos que mencionamos anteriormente. Personalmente, creo que este es el escenario más práctico para los parámetros dinámicos del Broker. Después de todo, en entornos de producción reales, las capacidades de procesamiento de solicitudes del Broker a menudo deben ampliarse según la demanda. No podemos hacer esto sin los parámetros dinámicos del Broker.
3. Parámetros relacionados con SSL.
Principalmente 4 parámetros (ssl.keystore.type, ssl.keystore.location, ssl.keystore.password y ssl.key.password). Al permitir que se ajusten dinámicamente en tiempo real, podemos crear certificados SSL que tienen tiempos de vencimiento muy cortos.
Cada vez que realizamos ajustes, la base de Kafka reconfigura el canal de conexión del Socket y actualiza el almacén de claves. Las nuevas conexiones utilizarán un nuevo almacén de claves y este conjunto de parámetros se ajustará periódicamente para aumentar la seguridad.
4.num.replica.fetchers.
En mi opinión, este también es uno de los parámetros dinámicos del Broker más prácticos. Las réplicas de seguidores tardan en extraerse, lo que siempre ha sido un problema de larga data en el entorno Kafka en línea. Para resolver este problema, un enfoque común es aumentar el valor del parámetro para garantizar que haya suficientes subprocesos para realizar la transferencia de la copia del seguidor a la copia del líder. Ahora que existen parámetros dinámicos, no es necesario reiniciar el Broker para que surta efecto inmediatamente en el lado del Seguidor, por lo que digo que este es un escenario de aplicación muy práctico.
Este artículo se centra en los parámetros dinámicos del Broker introducidos en la versión Kafka 1.1.0. La mayor ventaja de este tipo de parámetros es que los cambios pueden surtir efecto sin reiniciar el Broker, reduciendo así en gran medida los costos de operación y mantenimiento. Además, también se proporcionan el mecanismo de guardado y el método de configuración de los parámetros dinámicos.