Ensayo: cómo asegura el modelo de grupo de subprocesos de la cola de mensajes que los mensajes no se pierdan al reiniciar

antecedentes

Hoy vi una publicación sobre Maimai, que es más interesante:

El significado de esta publicación es: Al usar Kafka, hemos configurado múltiples particiones, ¿cómo mejorar el consumo? Si usa el grupo de subprocesos para mejorar, asegúrese de que el mensaje no se pierda al reiniciar.

Esta pregunta en realidad plantea dos puntos: el primero es cómo aumentar la capacidad de consumo y el segundo es cómo podemos evitar que los mensajes se pierdan si elegimos el grupo de subprocesos.

Permítanme explicar primero cuáles son estos dos problemas. En muchas colas de mensajes, existe un concepto llamado partición, que representa la partición. La partición es la clave para que aumentemos el consumo de la cola de mensajes. El canal de consumo de nuestros consumidores es de cada Una partición solo puede ser retenida por un consumidor, como se muestra en la siguiente figura:

Es un poco similar a las colas bancarias. Cuantas más colas haya, menor será el tiempo de espera. Por supuesto, también se puede procesar de manera asíncrona, como un grupo de subprocesos, donde todos los mensajes se lanzan al grupo de subprocesos para su ejecución. Esto lleva a la segunda pregunta que planteó el autor: en primer lugar, echemos un vistazo a por qué el consumo sincrónico no pierde mensajes.

Si usamos un modelo síncrono, compensaremos ack después de consumir. Si reiniciamos y no logramos compensar, esta parte de los datos se consumirá nuevamente. Si es consumida por el grupo de subprocesos, ¿cómo procedemos? ¿Qué pasa con ack, por ejemplo, si consumimos 10, 11, 12 tres mensajes con el grupo de subprocesos, si 12 se consume primero, entonces reconocemos 13? Si hace esto, reinicie en este momento y Kafka pensará que ha procesado los 10, 11 mensajes y los mensajes se perderán en este momento, y el estudiante que publicó esta publicación estará más confundido al respecto.

Respuesta del internauta

Echemos un vistazo a algunas respuestas de los internautas:

Internauta A:

La respuesta de este internauta esencialmente todavía usa el grupo de subprocesos, y el autor también respondió, pero no resolvió el problema del grupo de subprocesos.

Internauta B:

Este método es similar al de las colas bancarias, mientras haya más colas aumentará la velocidad de procesamiento, de hecho es una de las soluciones al primer problema.

Internauta C:

Esta categoría resuelve principalmente el segundo problema. Manteniendo el desplazamiento externamente, por ejemplo, almacenando el desplazamiento en la biblioteca, podemos encontrar el desplazamiento correcto que debería consumirse. Esto es relativamente complicado. El uso de un MQ requiere una base de datos. , En caso de que utilice los servicios MQ sin una base de datos, tengo que presentar una solicitud por separado.

Internauta D:

Otro punto de vista es que si se escribe mejor el código para aumentar la velocidad de consumo, entonces la capacidad de consumo aumentará naturalmente, este es un punto muy importante, que otros suelen ignorar, a veces el consumo es más lento. Las personas pueden comenzar a pensar en cómo configurar middleware y, a menudo, ignoran su propio código.

Después de leer una respuesta a tantas publicaciones, siento que no hay una respuesta que realmente me satisfaga. Aquí hay algunas ideas en mi mente.

mis pensamientos

Respecto a la primera pregunta, ¿cómo mejorar el consumo energético? En realidad, este problema se puede resumir de tres maneras:

1. Si el hilo de consumo de cada máquina de consumo es fijo, entonces podemos expandir la máquina de consumo y la partición, similar a la cola del banco para aumentar la ventana de cola.
2. Si la máquina y la partición son fijas, es una mejor manera de aumentar el hilo de consumo, pero si es un consumo secuencial, no se puede aumentar la capacidad de consumo aumentando el número de subprocesos, porque cada parte de consumo secuencial es un hilo separado. Solo se puede solucionar de la primera forma.
3. Para aumentar el poder de consumo de su propio código, piénselo si el banco maneja los asuntos, si la eficiencia del trabajo del cajero se puede mejorar muy alto, entonces la velocidad general de la cola debe ser muy rápida.
   Para la segunda pregunta, si usamos el modelo de grupo de subprocesos, cómo resolver el problema de la pérdida de mensajes, aquí recomiendo el enfoque en RocketMQ. Dijimos antes que usar una base de datos para ahorrar compensación es más complicado y el rendimiento sigue siendo relativamente pobre. En RocketMQ Se usa una estructura TreeMap para hacer la base de datos que mencionamos anteriormente:

private final TreeMap<Long, MessageExt> msgTreeMap = new TreeMap<Long, MessageExt>();

La clave del TreeMap es el desplazamiento de cada mensaje, y el valor es alguna información del mensaje. La capa inferior del TreeMap se implementa utilizando árboles rojo-negro. Podemos obtener rápidamente los valores mínimo y máximo. Cuando procesamos cada vez Cuando terminemos un determinado mensaje, eliminaremos este mensaje de msgTreeMap,

public long removeMessage(final List<MessageExt> msgs) {
        long result = -1;
        final long now = System.currentTimeMillis();
        try {
            this.lockTreeMap.writeLock().lockInterruptibly();
            this.lastConsumeTimestamp = now;
            try {
                if (!msgTreeMap.isEmpty()) {
                    result = this.queueOffsetMax + 1;
                    int removedCnt = 0;
                    for (MessageExt msg : msgs) {
                        MessageExt prev = msgTreeMap.remove(msg.getQueueOffset());
                        if (prev != null) {
                            removedCnt--;
                            msgSize.addAndGet(0 - msg.getBody().length);
                        }
                    }
                    msgCount.addAndGet(removedCnt);

                    if (!msgTreeMap.isEmpty()) {
                        result = msgTreeMap.firstKey();
                    }
                }
            } finally {
                this.lockTreeMap.writeLock().unlock();
            }
        } catch (Throwable t) {
            log.error("removeMessage exception", t);
        }
        return result;
    }

El método removeMessage es eliminar el mensaje que se ha consumido y devolver la compensación de consumo actual, el resultado devuelto aquí es msgTreeMap.firstKey (), el valor que reconocemos al servidor de cola de mensajes es en realidad este, volviendo a nuestro problema, Si reiniciamos, en realidad no tenemos que preocuparnos por perder mensajes.

Al final

A continuación, se incluye una breve introducción a las colas de mensajes para mejorar las capacidades de los mensajes. Si está interesado en las colas de mensajes, puede leer algunos de mis artículos anteriores:

• Kafka debes saber
• RocketMQ que debes saber
• Comprensión profunda del uso, principio y optimización de los mensajes comunes y secuenciales de RocketMq
• Análisis en profundidad de cómo implementar mensajes de transacciones.
  Si cree que este artículo es útil para usted, su atención y reenvío son mi mayor apoyo.