Cómo ver la información del consumidor de KafkaEn el grupo QQ de la comunidad china de Kafak, esta pregunta se ha mencionado con mucha frecuencia y también es uno de los problemas más comunes que encuentra Kafka. usuarios. Este artículo combina el código fuente de Kafka para intentar explorar los factores relacionados con este problema. Espero que ayude a todos. ¿Cómo determinar el número de particiones? "¿Cuántas particiones debo elegir?" - Si pertenece a la comunidad china de Kafka, a menudo se encontrará con esta pregunta. Desafortunadamente, todavía no parecemos tener una respuesta muy autorizada. Esto no es sorprendente, después de todo, normalmente no existe una respuesta fija para este tipo de preguntas. El sitio web oficial de Kafka se promociona a sí mismo como un "sistema de mensajería distribuida de alto rendimiento", es decir, un motor de mensajería distribuida de alto rendimiento. Entonces, ¿cómo lograr un alto rendimiento? Kafka abandona el mecanismo de almacenamiento en caché del montón de Java en la capa inferior y adopta el almacenamiento en caché de páginas a nivel del sistema operativo. Al mismo tiempo, convierte operaciones de escritura aleatoria en escrituras secuenciales y, combinado con la función Zero-Copy, mejora enormemente el rendimiento de IO. Sin embargo, este es sólo un aspecto, después de todo, la capacidad de optimizar de forma independiente tiene un límite superior. Cómo mejorar aún más el rendimiento mediante la expansión horizontal o incluso la expansión lineal, Kafka adopta un método de partición para lograr el procesamiento de mensajes dividiendo los mensajes temáticos en múltiples particiones y almacenándolos en diferentes intermediarios, independientemente de la producción. Tanto los desarrolladores como los consumidores pueden lograr un alto rendimiento. Los productores y consumidores de Kafka pueden operar en paralelo con múltiples subprocesos, y cada subproceso procesa una partición de datos. Por lo tanto, una partición es en realidad la unidad más pequeña para ajustar el paralelismo de Kafka. Para el productor, en realidad utiliza varios subprocesos para iniciar simultáneamente conexiones de socket a diferentes particiones del intermediario y enviar mensajes a estas particiones para el consumidor. Todos los subprocesos del consumidor en el mismo grupo de consumidores están todos asignados a un tema específico en un determinado; partición para consumo. Más adelante se explicará en detalle cómo determinar el número de subprocesos de consumo. Por lo tanto, si un tema tiene más particiones, en teoría todo el clúster puede lograr un mayor rendimiento. ¿Pero son mejores más particiones? Aparentemente no, ya que cada partición tiene su propia sobrecarga: primero, el cliente/servidor necesita usar más memoria. Kafka082 presenta el nuevo productor después de la versión de Java. El productor tiene un parámetro de tamaño de lote, cuyo valor predeterminado es 16 KB. Almacena en caché los mensajes para cada partición y, una vez que está llena, empaqueta los mensajes y los envía en lotes. Este diseño parece mejorar el rendimiento. Pero obviamente, dado que este parámetro está en el nivel de partición, cuantas más particiones, más memoria se necesitará para el caché. Suponiendo que tiene 10.000 particiones, este caché ocupará aproximadamente 157 MB de memoria según la configuración predeterminada. ¿Qué pasa con el lado del consumidor? Dejemos de lado la memoria necesaria para recuperar los datos y hablemos únicamente de la sobrecarga del subproceso. Si aún asumimos que hay 10,000 particiones, y la cantidad de subprocesos consumidores que coinciden con la cantidad de particiones es en la mayoría de los casos la configuración óptima para el rendimiento del consumidor, entonces en el lado del cliente consumidor tendremos que crear 10,000 subprocesos y aproximadamente 10,000 sockets. Es necesario crear un archivo para obtener los datos de la partición. No se puede subestimar la sobrecarga del cambio de subprocesos. La sobrecarga en el lado del servidor no es pequeña. Si lee el código fuente de Kafka, puede encontrar que muchos componentes en el lado del servidor mantienen cachés a nivel de partición en la memoria, como el controlador, FetcherManager, etc. cuanto mayor sea el tiempo, mayor será el costo de este tipo de caché. En segundo lugar, la sobrecarga del procesamiento de archivos. Cada partición del sistema de archivos subyacente tiene su propio directorio. Este directorio suele tener dos archivos: base_offsetlog y base_offsetindex. El controlador de Kafak y ReplicaManager guardan estos dos controladores de archivos para cada agente. Cuantos más identificadores de archivos deban mantenerse abiertos, es posible que eventualmente se supere el límite de ulimit-n.
En tercer lugar, reduzca la alta disponibilidad de Kafka mediante el mecanismo de replicación para garantizar una alta disponibilidad. El método específico es guardar una cierta cantidad de réplicas para cada partición, y replica_factor especifica la cantidad de réplicas. Cada copia se guarda en un corredor diferente. Una de las réplicas actúa como réplica líder y es responsable de procesar las solicitudes de productores y consumidores. Las otras réplicas actúan como réplicas seguidoras y el Kafkacontroller es responsable de garantizar la sincronización con la réplica líder. Si el agente donde se encuentra el líder se cuelga, el controlador lo detectará y volverá a seleccionar un nuevo líder con la ayuda del cuidador del zoológico; habrá una breve ventana de indisponibilidad, pero en la mayoría de los casos es posible solo unos pocos milisegundos. Pero si tiene 10.000 particiones y 10 corredores, eso significa que hay un promedio de 1.000 particiones en cada corredor. En este punto, después de que el agente se cuelga, el cuidador del zoológico y el controlador deben realizar la elección del líder para estas 1000 particiones inmediatamente. Inevitablemente, esto llevará más tiempo que un número muy pequeño de elecciones de líderes de partición y, por lo general, no es linealmente acumulativo. La situación es aún peor si el agente es también el responsable del tratamiento. Creo que mucha gente está impaciente con estas "tonterías". Entonces te preguntarás, ¿cómo determinar el número de particiones? La respuesta es: depende. Básicamente, todavía necesitas pasar por una serie de experimentos y pruebas para descubrirlo. Por supuesto, las pruebas deben basarse en el rendimiento. Aunque este artículo de LinkedIn realiza una prueba comparativa de Kafka, los resultados en realidad significan poco para usted, porque los resultados de diferentes pruebas de hardware, software y carga seguramente serán diferentes. A menudo encuentro problemas similares. El sitio web oficial dice que es 10 MB por segundo. ¿Por qué mi productor solo tiene 1 MB por segundo? Sin mencionar las condiciones del hardware, finalmente descubrí que el cuerpo del mensaje que usó es 1 KB. el sitio web oficial utiliza Se midió en 100B, por lo que no hay comparación alguna. Sin embargo, aún puede intentar determinar la cantidad de particiones siguiendo ciertos pasos: Cree un tema con solo 1 partición y luego pruebe el rendimiento del productor y el rendimiento del consumidor del tema. Supongamos que sus valores son Tp y Tc (unidad: MB/s) respectivamente. Luego, suponiendo que el rendimiento objetivo total es Tt, entonces el número de particiones = Tt/maxTp, y TcTp representa el rendimiento del productor. Probar un productor suele ser muy sencillo porque su lógica es muy simple, basta con enviar mensajes directamente a Kafka. La prueba de Tc suele ser más específica de la aplicación, porque el valor de Tc depende de lo que haga después de recibir el mensaje, por lo que probar Tc suele ser complicado. Además, Kafka no escala realmente linealmente y, de hecho, ningún sistema puede hacer esto, por lo que es mejor tener esto en cuenta al planificar el número de particiones para que sea más fácil escalar en el futuro. Asignación de particiones de mensajes De forma predeterminada, Kafka asigna particiones según la clave utilizada para entregar el mensaje (es decir, la clave hash)