[Cola de mensajes] Diseño e implementación de la arquitectura de caché de la capa de aplicación de Kafka basada en SSD (Meituan)

El siguiente artículo es una reproducción del " Equipo técnico de Meituan "

El estado actual de Kafka en la plataforma de datos Meituan

La excelente optimización de E / S de Kafka y los múltiples diseños asíncronos tienen un rendimiento más alto que otros sistemas de cola de mensajes, al tiempo que garantizan una buena latencia, que es muy adecuada para su aplicación en todo el ecosistema de big data.

Actualmente en la plataforma de datos Meituan, Kafka asume el papel de almacenamiento y distribución de datos. Como se muestra en la figura siguiente, los registros comerciales, los registros de Nginx de la capa de acceso o los datos de la base de datos en línea se envían a Kafka a través de la capa de recopilación de datos, y las operaciones en tiempo real del usuario consumen y calculan los datos posteriores, o la capa ODS de El almacén para la producción del almacén de datos. Otra parte ingresará al centro de registro unificado de la empresa para ayudar a los ingenieros a solucionar problemas en línea.

La escala actual de Kafka en Meituan Online:

Tamaño del clúster : más de 6000 nodos y más de 100 clústeres.
Portador del clúster : Tema número 60.000+, Número de partición 410.000+.
La escala de mensajes procesados : actualmente, la cantidad total de mensajes procesados por día es de 8 billones y el tráfico máximo es de 180 millones de mensajes por segundo.
La escala de los servicios prestados : actualmente, la plataforma informática en tiempo real de bajada ejecuta más de 30.000 trabajos, y la mayoría de estas fuentes de datos provienen de Kafka.

Análisis de puntos débiles en línea de Kafka y objetivos principales

Actualmente, Kafka admite una gran cantidad de trabajos en tiempo real y una gran cantidad de temas y particiones en una sola máquina. El problema que suele aparecer en este escenario es que diferentes particiones en la misma máquina compiten por los recursos de PageCache y se afectan entre sí, lo que da como resultado un aumento en la demora de procesamiento de todo el Broker y una disminución en el rendimiento.

A continuación, analizaremos los puntos débiles de Kafka en línea en función del flujo de procesamiento de las solicitudes de lectura y escritura de Kafka y las estadísticas en línea.

Análisis de principios

Kafkaå¤çè¯ »åæµç¨çç¤ºæå¾

Para solicitudes de producción : el subproceso de E / S en el lado del servidor escribe uniformemente los datos solicitados en el PageCache del sistema operativo y regresa inmediatamente. Cuando el número de mensajes alcanza un cierto umbral, la aplicación Kafka en sí o el kernel del sistema operativo se activará una operación de disco flash forzada (como se muestra en el diagrama de flujo de la izquierda).
Para solicitudes de consumo: se utiliza principalmente el mecanismo ZeroCopy del sistema operativo. Cuando Kafka Broker recibe una solicitud de lectura de datos, enviará una llamada al sistema de envío de archivos al sistema operativo. Después de recibirla, el sistema operativo primero intentará obtener datos de PageCache (como se muestra en el diagrama de flujo del medio). Si los datos no existen, activará una interrupción de excepción de falla de página para leer los datos del disco en el búfer temporal (como se muestra en el diagrama de flujo a la derecha), y luego directamente copie los datos al búfer de la tarjeta de red a través de la operación DMA para esperar la transmisión TCP de seguimiento.

En resumen, Kafka tiene un buen rendimiento y latencia para una sola solicitud de lectura y escritura. Al procesar una solicitud de escritura, los datos se devuelven inmediatamente después de escribirse en PageCache y los datos se vacían en el disco en lotes de forma asíncrona, lo que no solo garantiza que la mayoría de las solicitudes de escritura tengan una latencia más baja, sino que también el vaciado secuencial por lotes es más amigable. al disco. Al procesar solicitudes de lectura, los trabajos de consumo en tiempo real pueden leer datos directamente desde PageCache, con un pequeño retraso de solicitud. Al mismo tiempo, el mecanismo ZeroCopy puede reducir el cambio entre el modo de usuario y el modo de kernel durante la transmisión de datos, mejorando en gran medida la eficiencia de transmisión de datos.

Pero cuando hay varios Consumidores en el mismo Broker, es posible que se retrasen debido a que varios Consumidores compiten por los recursos de PageCache. Tomemos dos consumidores como ejemplo para explicar en detalle:

Como se muestra en la figura anterior, el productor envía los datos al corredor y PageCache almacenará en caché esta parte de los datos. Cuando la capacidad de consumo de todos los consumidores sea suficiente, todos los datos se leerán de PageCache y la latencia de todas las instancias de consumidores será baja. En este momento, si uno de los Consumidores tiene un retraso de consumo (Proceso de Consumidor 2 en la figura), de acuerdo con el flujo de procesamiento de la solicitud de lectura, la lectura del disco se activará en este momento y parte de los datos se leerán previamente. a PageCache mientras se leen los datos del disco. Cuando el espacio de PageCache es insuficiente, los datos se eliminarán de acuerdo con la estrategia LRU. En este momento, los datos leídos por el consumidor que retrasan el consumo reemplazarán los datos de la caché en tiempo real en el PageCache. Más tarde, cuando llegue la solicitud de consumo en tiempo real, debido a que se reemplazaron los datos en PageCache, se producirán lecturas de disco inesperadas. Esto tiene dos consecuencias:

Los consumidores con suficiente poder adquisitivo perderán la bonificación de rendimiento de PageCache cuando consuman.
Varios consumidores se influyen entre sí, y aumentan las lecturas de disco inesperadas y aumenta la carga del disco duro.

Realizamos pruebas de gradiente sobre el rendimiento del disco duro y el impacto de la concurrencia de lectura y escritura, como se muestra en la siguiente figura:

Se puede ver que con el aumento de la concurrencia de lectura, el IOPS y el ancho de banda del HDD disminuirán significativamente, lo que afectará aún más el rendimiento y la demora de procesamiento de todo el Broker.

Estadísticas online

En la actualidad, el tráfico TP99 del clúster Kafka es de 170 MB / s, el tráfico de TP95 es de 100 MB / sy el tráfico de TP50 es de 50-60 MB / s; el PageCache de una sola máquina se asigna uniformemente a 80 GB y el tráfico de TP99 se toma como Una referencia Bajo esta asignación de tráfico y PageCache, el intervalo de tiempo máximo de datos almacenables en caché de PageCache es 80 * 1024/170/60 = 8min, lo que muestra que el servicio Kafka actual en su conjunto tiene una tolerancia extremadamente baja para las operaciones de consumo retrasado. En este caso, una vez que se retrasa el consumo de algunos trabajos, los trabajos de consumo en tiempo real pueden verse afectados.

Al mismo tiempo, hemos contado la distribución de demora en el consumo de los trabajos en línea en tiempo real. Los trabajos con un rango de demora de 0 a 8 minutos (consumo en tiempo real) representaron solo el 80%, lo que indica que actualmente hay un 20% de los trabajos en línea. en estado de consumo retardado.

Resumen del análisis de los puntos de dolor

Resumiendo el análisis de principios y las estadísticas de datos en línea mencionados anteriormente, Kafka actualmente en línea tiene los siguientes problemas:

Los trabajos de consumo en tiempo real y de consumo retrasado compiten en el nivel de PageCache, lo que genera lecturas de disco inesperadas debido al consumo en tiempo real.
El rendimiento del disco duro tradicional disminuye drásticamente a medida que aumenta la concurrencia de lectura.
Hay un 20% de retrasos en las operaciones de los consumidores en línea.

De acuerdo con la asignación de espacio actual de PageCache y el análisis de tráfico de clústeres en línea, Kafka no puede proporcionar una garantía de calidad de servicio estable para las operaciones de los consumidores en tiempo real, y este punto débil debe resolverse con urgencia.

Objetivo esperado

Con base en el análisis anterior de los puntos débiles, nuestro objetivo esperado es garantizar que los trabajos de consumo en tiempo real no se vean afectados por trabajos de consumo retrasados debido a la competencia de PageCache, y asegurar que Kafka proporcione garantías de calidad de servicio estable para trabajos de consumo en tiempo real. .

solución

Por que elegir SSD

Con base en el análisis de las razones anteriores, podemos ver que resolver los puntos débiles actuales se puede considerar desde las siguientes dos direcciones:

Elimine la competencia de PageCache entre el consumo en tiempo real y el consumo retrasado, como evitar que los datos leídos por los trabajos de consumo retrasados se vuelvan a escribir en PageCache o aumentar la asignación de PageCache.
Agregue un nuevo dispositivo entre el disco duro y la memoria, que tiene mejor ancho de banda de lectura y escritura e IOPS que el disco duro.

Para la primera dirección, debido a que PageCache es administrado por el sistema operativo, si se modifica su estrategia de eliminación, será más difícil de implementar y destruirá la semántica externa del propio kernel. Además, el costo de los recursos de memoria es alto y no es posible una expansión ilimitada, por lo que se debe considerar la segunda dirección.

El desarrollo de SSD se está volviendo cada vez más maduro.En comparación con HDD, las IOPS y el ancho de banda de SSD tienen una mejora de orden de magnitud, lo que es muy adecuado para participar del tráfico de lectura después de la competencia de PageCache en el escenario anterior. También probamos el rendimiento del SSD y los resultados se muestran en la siguiente figura:

Se puede encontrar en la figura que a medida que aumenta la concurrencia de lectura, el IOPS y el ancho de banda del SSD no disminuirán significativamente. A partir de esta conclusión, podemos saber que podemos usar SSD como capa de almacenamiento en caché entre PageCache y HDD.

Decisión arquitectónica

Después de introducir SSD como la capa de almacenamiento en caché, los problemas clave que se resolverán en el siguiente paso incluyen la sincronización de datos entre PageCache, SSD, HDD y enrutamiento de datos para solicitudes de lectura y escritura. Al mismo tiempo, nuestra nueva arquitectura de caché debe coincidir completamente el motor Kafka lee y escribe Las características de la solicitud. Esta sección presentará cómo la nueva arquitectura resuelve los problemas de selección y diseño antes mencionados.

El motor Kafka tiene las siguientes características en el comportamiento de lectura y escritura:

La frecuencia del consumo de datos cambia con el tiempo y cuanto mayor es la frecuencia de consumo de datos, menor.
Cada partición (Partición) solo Leader proporciona servicios de lectura y escritura.
Para un cliente, el comportamiento de consumo es lineal y los datos no se consumirán repetidamente.

A continuación se dan dos alternativas, y nuestra base de selección y decisión arquitectónica se darán a continuación para las dos alternativas.

Alternativa 1: Implementación basada en la capa de kernel del sistema operativo

Actualmente, las tecnologías de almacenamiento en caché de código abierto incluyen FlashCache, BCache, DM-Cache, OpenCAS, etc. Entre ellas, BCache y DM-Cache se han integrado en Linux, pero existen requisitos para la versión del kernel y están limitados por la versión del kernel. solo puede elegir FlashCache / OpenCAS.

Como se muestra en la siguiente figura, las ideas centrales de diseño de FlashCache y OpenCAS son similares. La base teórica central de las dos arquitecturas es el principio de "localidad de datos". El SSD y el HDD se dividen en unidades de administración fijas con la misma granularidad, y luego se instala el SSD El espacio se asigna a múltiples dispositivos de capa HDD (mapeo lógico o mapeo físico). En el proceso de acceso, similar al proceso en el que la CPU accede a la caché y la memoria principal, primero intente acceder a la capa Cache. Si aparece CacheMiss, se accederá a la capa HDD. Al mismo tiempo, de acuerdo con el principio de localidad de datos , esta parte de los datos se volverá a escribir en la capa Cache. Si el espacio de la caché está lleno, algunos datos se reemplazarán mediante la estrategia LRU.

FlashCache / OpenCAS proporciona cuatro estrategias de almacenamiento en caché: WriteThrough, WriteBack, WriteAround, WriteOnly. Dado que el cuarto tipo no hace el almacenamiento en caché de lectura, aquí solo miramos los primeros tres tipos.

Escribir:

WriteThrough : la operación de escritura de datos se escribirá en el almacenamiento de fondo al mismo tiempo que se escribe en el SSD.
WriteBack : la operación de escritura de datos regresa solo después de escribir en el SSD, y la estrategia de caché se descarga en el almacenamiento en segundo plano.
WriteAround : las operaciones de escritura de datos se escriben directamente en el almacenamiento de back-end y la caché correspondiente al SSD dejará de ser válida.

Leer:

WriteThrough / WriteBack / WriteAround : primero lea el SSD, y el almacenamiento de back-end se leerá nuevamente si falla , y los datos se descargarán en el caché del SSD.

Para obtener detalles de implementación más detallados, consulte los documentos oficiales de los dos:

Alternativa dos: implementación interna de la aplicación Kafka

En el primer tipo de alternativas mencionado anteriormente, la base teórica principal del principio de "localidad de datos" y las características de lectura y escritura de Kafka no son completamente consistentes. La característica de "retroceso de datos" aún presentará el problema de la contaminación del espacio de la caché. Al mismo tiempo, la estrategia de eliminación basada en LRU de la arquitectura anterior también contradice las características de lectura y escritura de Kafka. Cuando varios consumidores consumen al mismo tiempo, la estrategia de eliminación de LRU puede eliminar por error algunos datos casi en tiempo real, lo que da como resultado fluctuaciones de rendimiento en valores reales. -Tiempo de las operaciones del consumidor.

Se puede ver que la solución alternativa no puede resolver por completo los puntos débiles actuales de Kafka y debe transformarse desde dentro de la aplicación. La idea general del diseño es la siguiente. Los datos se distribuyen en diferentes dispositivos de acuerdo con la dimensión de tiempo, y la parte de los datos casi en tiempo real se almacena en caché en el SSD, de modo que cuando se produce la competencia de PageCache, el trabajo del consumidor en tiempo real lee los datos del SSD para asegurarse de que el trabajo en tiempo real no se verá afectado Impacto de las operaciones de consumo retrasado. La siguiente figura muestra el proceso de procesamiento de solicitudes de lectura en función de la arquitectura implementada en la capa de aplicación:

Cuando llega una solicitud de consumo al Kafka Broker, Kafka Broker obtiene directamente los datos del dispositivo correspondiente de acuerdo con la relación entre el desplazamiento del mensaje (Offset) que mantiene y el dispositivo y lo devuelve, y los datos leídos del HDD no son incluido en la solicitud de lectura. Vuelva a descargar en SSD para evitar la contaminación de la memoria caché. Al mismo tiempo, la ruta de acceso está despejada y no habrá una sobrecarga de acceso adicional debido a Cache Miss.

La siguiente tabla proporciona una comparación más detallada de diferentes soluciones candidatas:

Finalmente, considerando el grado de coincidencia con las funciones de lectura y escritura de Kafka, la carga de trabajo general y otros factores, usamos la capa de aplicación de Kafka para implementar esta solución, porque la solución está más cerca de las funciones de lectura y escritura de Kafka en sí, y puede ser más completa resolver los puntos débiles de Kafka.

Nuevo diseño de arquitectura

Visión general

Basándonos en el análisis anterior de las características de lectura y escritura de Kafka, proporcionamos los objetivos de diseño de la arquitectura de caché basada en SSD en la capa de aplicación:

Los datos se distribuyen en diferentes dispositivos de acuerdo con la dimensión del tiempo, y los datos casi en tiempo real se distribuyen en el SSD y se eliminan en el HDD con el tiempo.
Todos los datos de la partición líder se escriben en el SSD.
Los datos leídos desde el HDD no se devuelven al SSD.

De acuerdo con los objetivos anteriores, damos la implementación de la arquitectura de caché de Kafka basada en SSD en la capa de aplicación:

Una partición en Kafka consta de varios segmentos de registro, y cada segmento de registro contiene dos archivos de índice y archivos de mensajes de registro. Varios segmentos de registro de una partición se organizan en orden de acuerdo con la dimensión de Desplazamiento (tiempo relativo).

De acuerdo con las ideas de diseño en la sección anterior, primero marcamos diferentes LogSegments como diferentes estados, como se muestra en la figura (la parte superior de la figura), según la dimensión de tiempo, se divide en tres estados residentes: OnlyCache, Cached y sin caché. La transición de los tres estados y el procesamiento de las operaciones de lectura y escritura por la nueva arquitectura se muestran en la parte inferior de la figura. El segmento de registro marcado como OnlyCached solo se almacena en el SSD, y el subproceso de fondo almacenará periódicamente los inactivos ( sin tráfico de escritura) LogSegment Sincronizado con el SSD, el LogSegment completado se marca como en caché. Finalmente, el subproceso en segundo plano verificará periódicamente el espacio utilizado en el SSD. Cuando el espacio alcance el umbral, el subproceso en segundo plano eliminará el segmento de registro con la distancia más larga del SSD de acuerdo con la dimensión de tiempo, y esta parte del segmento de registro será marcado como el estado Sin caché.

Para las solicitudes de escritura, la solicitud de escritura aún escribe los datos en PageCache primero y el SSD se vaciará después de que se cumpla la condición de umbral. Para una solicitud de lectura (cuando el PageCache no ha obtenido los datos), si el estado del segmento de registro correspondiente al desplazamiento de lectura es Cached o OnlyCache, los datos se devuelven desde el SSD (LC2-LC1 y RC1 en la figura). es WithoutCache, los datos se devuelven desde el SSD. El HDD vuelve (LC1 en la figura).

Para la sincronización de datos de la copia del seguidor, puede decidir si escribir en SSD o HDD a través de la configuración de acuerdo con los requisitos de latencia y estabilidad de Topic.

Puntos clave de optimización

Lo anterior introdujo el esquema de diseño y las ideas de diseño centrales de la arquitectura de caché de la capa de aplicación Kafka basada en SSD, incluido el proceso de lectura y escritura, la administración del estado interno y la función de subproceso en segundo plano recién agregada. Esta sección presenta los puntos clave de optimización de la solución, y estos puntos de optimización están estrechamente relacionados con el rendimiento del servicio. Incluye principalmente la sincronización de LogSegment y la optimización de la estrategia de flasheo Append, que se presentarán por separado a continuación.

Sincronización de segmento de registro

La sincronización de segmento de registro se refiere al proceso de sincronización de datos en el SSD con el HDD. El mecanismo está diseñado con los siguientes dos puntos clave:

Método de sincronización : el método de sincronización determina la puntualidad visible de los datos del SSD en el HDD, lo que afectará la puntualidad de la recuperación de fallos y la limpieza del segmento de registro.
Límite de velocidad de sincronización : el proceso de sincronización de LogSegment utiliza un mecanismo de límite de velocidad para evitar que las solicitudes normales de lectura y escritura se vean afectadas durante el proceso de sincronización

Sincrónicamente

En cuanto al método de sincronización de LogSegment, hemos dado tres alternativas. La siguiente tabla enumera la introducción de los tres esquemas y sus respectivas ventajas y desventajas:

Al final, consideramos exhaustivamente el costo de mantenimiento de la coherencia, la complejidad de la implementación y otros factores, y elegimos la forma de sincronizar el segmento de registro inactivo en segundo plano.

Límite de velocidad sincrónico

El comportamiento de sincronización de LogSegment es esencialmente la transmisión de datos entre dispositivos, lo que generará tráfico adicional de lectura y escritura en los dos dispositivos al mismo tiempo, ocupando el ancho de banda de lectura y escritura del dispositivo correspondiente. Al mismo tiempo, dado que hemos optado por sincronizar los datos en la parte Inactiva, necesitamos sincronizar toda la sección. Si el proceso de sincronización no está restringido, tendrá un mayor impacto en el retraso general del servicio, que se manifiesta principalmente en los siguientes dos aspectos:

Desde la perspectiva del rendimiento de un solo disco, dado que el rendimiento de SSD es mucho mayor que el de HDD, el ancho de banda de escritura de HDD estará completo durante la transmisión de datos. En este momento, otras solicitudes de lectura y escritura tendrán fallas. Si hay un retraso en consumo de HDD en este momento La lectura de datos o el seguidor está sincronizando datos con HDD, lo que provocará inestabilidad en el servicio.
Desde la perspectiva de la implementación independiente, una sola máquina implementa 2 SSD y 10 HDD. Por lo tanto, durante el proceso de sincronización, 1 SSD debe soportar el volumen de escritura de 5 HDD. Por lo tanto, el SSD también tendrá fallas de rendimiento durante el proceso de sincronización. , lo que afecta la normalidad La respuesta a la solicitud se retrasa.

Con base en los dos puntos anteriores, necesitamos agregar un mecanismo de límite de velocidad en el proceso de sincronización de LogSegment. El principio general del límite de velocidad es sincronizar lo más rápido posible sin afectar el retraso de las solicitudes normales de lectura y escritura. Debido a que la velocidad de sincronización es demasiado lenta, los datos SSD no se pueden limpiar a tiempo y eventualmente se llenan. Al mismo tiempo, para poder ajustar de manera flexible, la configuración también se establece como un único parámetro de configuración de granularidad del Broker.

Estrategia de limpieza de registros optimizada

Además del problema de sincronización, el mecanismo de parpadeo durante el proceso de escritura de datos también afecta la latencia de lectura y escritura del servicio. El diseño de este mecanismo no solo afectará el rendimiento de la nueva arquitectura, sino que también afectará a Kafka nativo.

La siguiente figura muestra el flujo de procesamiento de una sola solicitud de escritura:

En el proceso de procesamiento de la solicitud de producción, primero determine si el segmento de registro debe transferirse de acuerdo con la ubicación actual del segmento de registro y la información de datos en la solicitud, luego escriba los datos solicitados en PageCache, actualice el LEO y la información estadística, y finalmente determine ya sea de acuerdo con la información estadística o no. La operación de flasheo debe activarse, si es necesario, mediante fileChannel.forceparpadeo forzado; de lo contrario, la solicitud se devuelve directamente.

En todo el proceso, a excepción de las operaciones de desplazamiento y parpadeo de registros, otras operaciones son operaciones de memoria, que no causarán problemas de rendimiento. La transferencia de registros implica el funcionamiento del sistema de archivos. En la actualidad, Kafka proporciona parámetros de perturbación para la transferencia de registros para evitar que varios segmentos activen la operación de transferencia al mismo tiempo para ejercer presión sobre el sistema de archivos. Para las operaciones de descarga de registros, el mecanismo actual proporcionado por Kafka es activar la descarga forzada con un número fijo de mensajes (actualmente 50.000 en línea). Este mecanismo solo puede garantizar que los mensajes se descarguen con la misma frecuencia cuando el tráfico entrante es constante. Sin embargo, , es imposible limitar la cantidad de datos que se transmiten al disco cada vez y no puede proporcionar un límite efectivo para la carga del disco.

Como se muestra en la siguiente figura, es el valor instantáneo de write_bytes de un disco durante la hora pico del mediodía. Durante la hora pico del mediodía, debido al aumento en el tráfico de escritura, se generará una gran cantidad de rebabas durante el proceso de cepillado, y el valor de las rebabas está casi cerca del valor máximo del disco, lo que provocará que la demora de las solicitudes de lectura y escritura fluctúe.

En respuesta a este problema, modificamos el mecanismo de los discos de flasheo y cambiamos el límite original basado en el número de barras al límite de velocidad de parpadeo real. Para un solo segmento, la velocidad de parpadeo está limitada a 2 MB / s. Este valor tiene en cuenta el tamaño medio real del mensaje en la línea. Si la configuración es demasiado pequeña, el tema con un solo mensaje grande se actualizará con demasiada frecuencia, lo que aumentará la demora promedio cuando el tráfico sea alto. En la actualidad, el mecanismo tiene un pequeño rango de escalas de grises en línea. La imagen de la derecha muestra el índice write_bytes correspondiente al mismo período de tiempo después de la escala de grises. Se puede ver que en comparación con la imagen de la izquierda, la tasa de descarga de datos es significativamente más suave que antes de la escala de grises, y la velocidad máxima es de solo 40 MB / s.

Para la nueva arquitectura de caché SSD, también existen los problemas antes mencionados, por lo que en la nueva arquitectura la velocidad de flasheo también está restringida en la operación de flasheo.

Prueba de solución

Objetivo de prueba

Se verifica que la arquitectura de almacenamiento en caché SSD basada en la capa de aplicación puede evitar que los trabajos en tiempo real se vean afectados por trabajos retrasados.
Se verifica que en comparación con la arquitectura de capa de caché basada en la capa de kernel del sistema operativo, la arquitectura SSD basada en la capa de aplicación tiene menor latencia de lectura y escritura bajo diferentes tráficos.

Descripción del escenario de prueba

Construya 4 clústeres: clúster de nueva arquitectura, clúster HDD ordinario, clúster FlashCache, clúster OpenCAS.
Cada grupo tiene 3 nodos.
Flujo de escritura fijo, relativamente lento para leer y escribir.
Configuración de consumo retrasado: solo consuma los datos de 10 ~ 150 minutos en relación con la hora actual (superando el área de transporte de PageCache, sin exceder el área de transporte de SSD).

Prueba de contenido e indicadores clave

Caso 1: Cuando solo hay consumo retrasado, observe el desempeño de producción y consumo del clúster.
- Indicadores clave: escritura que requiere mucho tiempo y lectura, estos dos indicadores reflejan la latencia de lectura y escritura.
- Indicadores de tasa de aciertos: volumen de lectura de HDD, volumen de lectura de HDD (volumen de lectura de HDD / volumen total de lectura), tasa de aciertos de lectura de SSD, estos tres indicadores reflejan la tasa de aciertos de la caché de SSD.
Caso 2: Cuando hay consumo retrasado, observe el comportamiento del consumo en tiempo real.
- Indicadores clave: la proporción de SLA (Quality of Service) para operaciones en tiempo real en 5 áreas de tiempo diferentes.

Resultados de la prueba

Desde la perspectiva del retraso de la solicitud de un solo agente:

Antes de la optimización del mecanismo de flasheo, la nueva arquitectura de caché SSD tiene ventajas obvias sobre otras soluciones en todos los escenarios.

Una vez optimizado el mecanismo de descarga del disco, la calidad del servicio de las otras soluciones se ha mejorado en términos de retraso. Con un volumen de tráfico reducido, debido a la optimización del mecanismo de descarga, las ventajas de la nueva arquitectura y otras soluciones se han reducido . Cuando el tráfico de escritura de un solo nodo es grande (más de 170 MB), la ventaja es obvia.

Desde la perspectiva del impacto de las operaciones demoradas en las operaciones en tiempo real:

En todos los escenarios involucrados en la prueba, la nueva arquitectura de caché no afecta las operaciones en tiempo real debido a operaciones demoradas, lo cual está en línea con las expectativas.

Resumen y perspectivas de futuro

Kafka asume el papel de almacenamiento en caché y distribución de datos unificados en la plataforma de datos de Meituan. Con el objetivo de que los puntos débiles actuales de las operaciones en tiempo real se vean afectadas por operaciones demoradas debido a la contaminación mutua de PageCache y provocando la competencia de PageCache, desarrollamos el almacenamiento en caché de la capa de aplicaciones de Kafka. Arquitectura basada en SSD. Este artículo presenta principalmente las ideas de diseño de la nueva arquitectura de Kafka y su comparación con otras soluciones de código abierto. En comparación con los clústeres ordinarios, la nueva arquitectura de caché tiene ventajas muy obvias:

Reduzca el tiempo de lectura y escritura : en comparación con los clústeres normales, el tiempo de lectura y escritura de los nuevos clústeres de arquitectura se reduce en un 80%.
El consumo en tiempo real no se ve afectado por el consumo retrasado : en comparación con los clústeres normales, el nuevo clúster de arquitectura tiene un rendimiento estable de lectura y escritura en tiempo real y no se ve afectado por el consumo retrasado.

En la actualidad, este conjunto de arquitectura de caché se ha verificado y se encuentra en la etapa gris, y se implementará en clústeres de alta calidad en el futuro.