Cómo entender el trabajo pendiente, el TTL, la retención y el tamaño de almacenamiento en Pulsar
Este artículo es el segundo artículo de la serie /p/31e7d4e5aa42. Presenta principalmente los principios de diseño de Pulsar y el método de almacenamiento en BookKeeper.
En la comunidad, a menudo vemos confusión de los usuarios sobre los trabajos pendientes, los tamaños de almacenamiento y las políticas de retención, así como algunas preguntas más comunes como:
Primero, echemos un vistazo a Pulsar. modelo de paso de mensajes
Como se muestra en la figura anterior, Pulsar proporciona el modelo de procesamiento pub-sub más básico.
Primero, el Productor genera el mensaje y lo agrega al tema como información adicional, y el tema específico al que se distribuye el mensaje depende de si el mensaje tiene la palabra clave msg.
Además de los consumidores, Pulsar también abstrae una capa de suscripción para suscribirse a temas, lo que le permite admitir colas de manera flexible y colas de mensajes de transmisión. Cada subusuario obtendrá una copia completa de todos los datos del tema, que es algo similar a un grupo de consumidores en Kafka. Dependiendo del tipo de suscripción, puede haber uno o más consumidores debajo de cada suscripción para recibir mensajes.
Actualmente, Pulsar admite los siguientes cuatro modelos de suscripción de mensajes:
Esto significa que cuando el productor envía con éxito un mensaje al tema, el mensaje solo se almacenará una vez en la capa de almacenamiento. , independientemente de si No importa cuántas suscripciones te suscribas al tema, en realidad estás operando con los mismos datos. Sobre esta base, podemos ver el concepto de abstracción jerárquica de arriba hacia abajo de Apache Pulsar como se muestra en la siguiente figura:
Primero, el concepto de abstracción de primer nivel es Tema (partición), que se utiliza para almacenar Productor Adjunto al mensaje, debajo del tema, se encuentra el libro mayor correspondiente, que está dividido en varios fragmentos. Los temas se dividen en fragmentos, en los que se almacenan entradas más pequeñas y las entradas se almacenan como mensajes individuales o lotes de mensajes.
La explicación más sencilla aquí es garantizar que los datos se distribuyan uniformemente en cada nodo bk. Esta es también una de las ventajas del diseño de arquitectura de fragmentación jerárquica.
Pulsar admite dos tipos de mecanismos de confirmación: AckIndividual (los consumidores pueden confirmar mensajes específicos según los ID de los mensajes) y AckCumulative (los consumidores pueden confirmar varios mensajes al mismo tiempo). AckCumulative significa seleccionar varios mensajes a la vez.
Para comprender mejor el tamaño de almacenamiento y el trabajo pendiente, primero debemos comprender el mecanismo de suscripción en Pulsar, como se muestra en la siguiente figura:
El productor aún envía mensajes al tema en el forma de anexo. El Consumidor creará una suscripción para suscribirse al Tema.
En la imagen de arriba, podemos ver que el tema en Suscripción recibió y aceptó correctamente el mensaje m4. Luego, todos los estados de los mensajes, incluido m4, se marcarán como eliminables. En Pulsar, esta posición está marcada con MarkDeletePosition. Todos los mensajes posteriores a este representan mensajes que aún no han sido consumidos por esta suscripción.
A medida que pasa el tiempo, suponiendo que en el escenario AckCumulative, el consumidor en la suscripción anterior consume varios mensajes más, la posición del cursor ahora se mueve a la posición m8, lo que significa que todos los mensajes anteriores a m8 se pueden eliminar. .
Supongamos que en el escenario AckIndividual, el consumidor en la suscripción anterior solo consumió el mensaje m7 y envió una solicitud de confirmación, pero los mensajes m5 y m6 aún no se han consumido, luego los mensajes anteriores al mensaje m4 y al mensaje m7 Actualmente se encuentran en estado Eliminable. En otras palabras, en este caso, existe una vulnerabilidad de Ack en medio del sujeto debido al uso de un solo Ack.
Con el tiempo, en un esquema de reconocimiento único, el orificio de reconocimiento puede desaparecer por sí solo, como se muestra en la siguiente figura:
Arriba, describimos la mezcla de reconocimiento único y por lotes. Escenario de reconocimiento, movimiento del cursor dentro de un tema para una única suscripción. Suponiendo que hay varias Suscripciones suscritas al Tema, cada Suscripción puede obtener una copia completa de los datos en el Tema, es decir, una Suscripción inicializará un nuevo cursor en el Tema y el progreso del consumo entre cada cursor no lo hará. Se cruzan entre sí y no se afectarán entre sí. El progreso del consumo entre cada Cursor no se superpone ni afecta entre sí, por lo que puede ocurrir la situación en la siguiente figura:
En la figura anterior, para el Tema, hay dos suscripciones: suscripción-1 y Suscripción- 2. Los consumidores de la suscripción-1 consumen información antes de m4, los consumidores de la suscripción-2 consumen información antes de m8 y los consumidores de la suscripción-2 consumen información antes de m8. Los usuarios de la suscripción-1 consumen información antes de m4 y los usuarios de la suscripción-2 consumen información antes de m8. La suscripción-2 ha consumido cuatro datos entre m4 y m8, pero la suscripción-1 no ha consumido esta parte de los datos, por lo que esta parte de la información aún no se puede eliminar. La información actualmente en estado eliminable es la información anterior a m4, es decir, la información consumida por la suscripción con el progreso de consumo más lento en este tema. Hay un problema. Suponiendo que la Suscripción-1 está inactiva y la posición del cursor no ha cambiado, esto hará que los datos del Tema no se puedan eliminar.
En respuesta a esta situación, Pulsar introduce el concepto TTL, que le permite establecer el tiempo TTL, de modo que cuando el mensaje alcance el umbral especificado por TTL y el cursor no se haya movido, el mecanismo TTL se activará. se activa y el cursor se moverá automáticamente a Luego se moverá a la ubicación especificada. Una cosa a tener en cuenta aquí es que hemos estado enfatizando que TTL mueve el cursor, y hasta ahora no hemos mencionado el concepto de eliminación de mensajes, así que no confunda los dos, todo lo que TTL hace es mover el cursor, no tiene nada que ver con; eliminación de mensajes cualquier relación lógica.
Para representar mejor los datos no consumidos en el tema, Pulsar introduce el concepto de acumulación para describir esta parte de los mensajes. El trabajo pendiente se puede dividir en las siguientes dos formas:
Como se muestra en la figura siguiente: el trabajo pendiente A pertenece al trabajo pendiente de la suscripción-1; el trabajo pendiente A pertenece al trabajo pendiente de suscripción-1. El trabajo pendiente de suscripción-1; el trabajo pendiente B pertenece al trabajo pendiente de suscripción-2.
A medida que pasa el tiempo, el BacklogSize seguirá cambiando, como se muestra en la siguiente figura:
Una cosa a tener en cuenta aquí es que el backlogSize aquí registra mensajes con lotes. Dado que analizar todo el lote en el lado del agente sobrecargaría al agente y desperdiciaría muchos recursos de CPU, el trabajo de análisis de la lógica del lote se coloca en el lado del consumidor. Entonces, el trabajo pendiente básicamente registra la cantidad de entradas que mencionamos anteriormente.
En Pulsar, el trabajo pendiente tiene las dos métricas siguientes:
Para obtener más información sobre el trabajo pendiente, consulte /p/31e7d4e5aa42.
En Apache Pulsar, BookKeeper se utiliza como una capa de almacenamiento que permite a los usuarios conservar mensajes. Para garantizar que los mensajes no persistan indefinidamente, Pulsar introduce un mecanismo de retención que permite a los usuarios configurar políticas de persistencia de mensajes. De forma predeterminada, la persistencia está desactivada, lo que significa que una vez que se recoge el mensaje, ingresa a la lógica de eliminación.
Al configurar la política de retención, puede especificar dos parámetros:
Después de introducir la política de retención, la vista representada por todo el tema es la siguiente, donde m0-m5 significa que ha sido confirmado por todos los suscriptores y ha superado el umbral de la política de retención, es decir, están listos para ser eliminados. > Listo para eliminar. Tenga en cuenta que los describo como listos para su eliminación, pero no está claro si se pueden eliminar.
Al principio, nos abstrajimos del tema de nivel superior al mensaje específico (para facilitar la descripción, aquí ignoramos el concepto de lote, donde mensaje es equivalente a una entrada), y ahora Volverá al nivel superior y apilará todos estos conceptos. Dado que la unidad de operación más pequeña permitida en bk es un segmento, los mensajes no se pueden eliminar en un nivel de mensaje (entrada) específico; la eliminación debe realizarse en un segmento.
Supongamos que m0-m3 pertenece al segmento 3, m4-m7 pertenece al segmento 2 y m8-m11 pertenece al segmento 1. Entonces los mensajes en m0-m5 se pueden eliminar, pero el segmento 2 contiene m6 y m7 no ha alcanzado El umbral se conserva, por lo que el segmento no se puede eliminar todavía.
Para expresar más convenientemente el tamaño del espacio de almacenamiento ocupado por el mensaje actual, Pulsar introdujo StorageSize para describir todo el concepto. Como se muestra en la siguiente figura: Cuando el trabajo pendiente B y los mensajes identificados por el tamaño de almacenamiento son los mismos, el tamaño del trabajo pendiente es igual al tamaño del almacenamiento.
Cuando se introduce un único reconocimiento, se introduce una política de retención y Bookkeeper se configura en función de eliminaciones segmentadas, es muy probable que el tamaño del espacio de almacenamiento sea mayor que el tamaño del trabajo pendiente. espacio. El tamaño del espacio de almacenamiento es mayor que el tamaño del espacio de trabajo pendiente, como se muestra en la siguiente figura: