Noticias Programación

Kafka reemplaza al cuidador del zoológico con el quórum

Apache Kafka se ha actualizado a la versión 2.8, con mejoras que incluyen la versión de acceso temprano de KIP-500, que permite que los corredores de Kafka se ejecuten sin Apache ZooKeeper, dependiendo en cambio de una implementación interna de Raft.

Esta mejora de la arquitectura permite admitir más particiones por clúster, operaciones más simples y una seguridad más estricta. Apache Kafka es una plataforma de transmisión distribuida que se puede utilizar para crear canales de transmisión de datos en tiempo real entre sistemas o aplicaciones.

Kafka nació en LinkedIn, desde donde fue contratado como proyecto Apache. Es un sistema de mensajería de publicación-suscripción rápido, escalable, duradero y tolerante a errores que se puede utilizar en lugar de los intermediarios de mensajes tradicionales.

La versión de Kafka que no es ZooKeeper se logra cambiando a un quórum autogestionado. Esto se incluye como una implementación de acceso temprano que aún no tiene todas las funciones y no debe usarse en producción, pero puede iniciar nuevos clústeres sin ZooKeeper y pasar por casos de uso básicos de producción y consumo.

En un nivel alto, KIP-500 funciona moviendo metadatos y configuraciones de temas de ZooKeeper a un nuevo tema interno llamado @metadata. Este tema lo maneja una serie de quórum interno de «controladores» y se replica en todos los intermediarios del clúster. El líder del quórum de Raft tiene el mismo rol que el controlador en los clústeres en la actualidad.

Otras mejoras en la nueva versión incluyen una nueva API Describe Cluster. Hasta ahora, AdminClient de Kafka ha utilizado la API de metadatos del intermediario para obtener información del clúster, pero se desarrolló para respaldar al cliente consumidor y productor. La nueva API agrega la capacidad de consultar directamente a los intermediarios para obtener información del clúster y significa que será más fácil agregar nuevas funciones de administración en el futuro.

Otras mejoras incluyen soporte para autenticación TLS mutua en oyentes SASL_SSL, mejorando así la capacidad de proteger sus propios entornos; y una mejor gestión de la jerarquía registral. Log4j utiliza un modelo jerárquico para configurar los registradores dentro de una aplicación, pero hasta ahora las API del intermediario de Kafka para ver los niveles de registro no respetaban esta jerarquía.

La administración de registros también se ha mejorado con la capacidad de generar JSON con un nuevo esquema generado automáticamente. Los registros de solicitud / respuesta de nivel de depuración de los corredores de Kafka se estructurarán en adelante en JSON para que puedan ser analizados y utilizados más fácilmente por las cadenas de herramientas de registro.

kafka

Publicidad:

Publicidad:

También puede gustarte...

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *