Red de conocimiento informático - Material del sitio web - 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.