Selección de MQ en el desarrollo de proyectos

0, resumen

Desde comenzar hasta adentrarse en el suelo (9), le enseñará cómo construir un clúster sincrónico de doble maestro y esclavo doble de RocketMQ, ¡no crea que no puede aprender!

De la entrada al suelo (10) Procesos de clúster de RocketMQ y conceptos básicos

1. Dígame qué middleware de mensajes se utiliza en el entorno de producción en línea de su empresa.

Consulte [2, ¿cómo seleccionar múltiples mq? 】

2. ¿Cómo seleccionar varios mq?

Metros cuadrados	descripción
RabbitMQ	En el desarrollo de Erlang, el soporte para la acumulación de mensajes no es bueno, cuando una gran cantidad de mensajes están atrasados, hará que el rendimiento de RabbitMQ disminuya drásticamente. Puede procesar decenas de miles a cientos de miles de mensajes por segundo.
RocketMQ	Desarrollo de Java, rico en funciones de agrupamiento orientadas a Internet y muchas optimizaciones en el retardo de respuesta de los servicios en línea. En la mayoría de los casos, puede lograr una respuesta de milisegundos y puede procesar cientos de miles de mensajes por segundo.
Kafka	Desarrollo Scala, funciones ricas orientadas a registros, el más alto rendimiento. En su escenario empresarial, cuando el número de mensajes por segundo no es tan elevado, la latencia de Kafka será relativamente alta. Por lo tanto, Kafka no es adecuado para escenarios comerciales en línea.
ActiveMQ	El desarrollo de Java es simple, estable y el rendimiento no es tan bueno como los tres anteriores. Está bien para sistemas pequeños, pero no se recomienda. Se recomienda utilizar Internet convencional.

3. ¿Por qué utilizar MQ?

Debido a que el proyecto es relativamente grande y se construye un sistema distribuido, todas las solicitudes de invocación de servicios remotos se ejecutan de forma sincrónica y, a menudo, surgen problemas, por lo que se presenta mq

efecto	descripción
Desacoplamiento	El grado de acoplamiento del sistema se reduce y no existe una fuerte dependencia
asincrónico	Las llamadas remotas que no necesitan ejecutarse de forma síncrona pueden mejorar eficazmente el tiempo de respuesta
Recorte de picos	Una vez que la solicitud alcanza el pico, el servicio de back-end aún puede mantener una tasa de consumo fija y no se verá abrumado.

4. ¿En qué roles se compone RocketMQ y cuáles son las funciones y características de cada rol?

Personaje	efecto
Nombre del servidor	Lista dinámica y sin estado; esta es también una de las diferencias importantes con el guardián del zoológico. El guardián del zoológico tiene estado.
Productor	El productor de mensajes es responsable de enviar mensajes al Broker.
Corredor	Es el propio MQ, responsable de enviar y recibir mensajes, persistir mensajes, etc.
Consumidor	Los consumidores de mensajes son responsables de extraer los mensajes del Broker para su consumo y de recibirlos después del consumo.

5. ¿Cuál es la diferencia entre Topic y la cola JMS en RocketMQ?

Cola es la cola FIFO derivada de la estructura de datos. El tema es un concepto abstracto. La capa inferior de cada tema corresponde a N colas y los datos realmente existen en la cola.

6. ¿Se eliminarán los mensajes en RocketMQ Broker inmediatamente después de consumirse?

No, todos los mensajes se conservarán en CommitLog. Después de que cada consumidor se conecte al corredor, mantendrá la información de progreso de consumo. Cuando se consume un mensaje, solo se actualiza el progreso de consumo actual del consumidor (compensación de CommitLog).

Seguimiento: Entonces, ¿se acumularán las noticias? ¿Cuándo limpiar los mensajes caducados?

La versión 4.6 eliminará los archivos de CommitLog que ya no estén en uso después de 48 horas de forma predeterminada

Verifique la última hora de acceso a este archivo
Determine si es mayor que el tiempo de vencimiento
Eliminar a la hora especificada, predeterminado a las 4 en punto de la mañana

El código fuente es el siguiente:

/**
 * {@link org.apache.rocketmq.store.DefaultMessageStore.CleanCommitLogService#isTimeToDelete()}
 */
private boolean isTimeToDelete() {
    // when = "04";
    String when = DefaultMessageStore.this.getMessageStoreConfig().getDeleteWhen();
    // 是04点，就返回true
    if (UtilAll.isItTimeToDo(when)) {
        return true;
    }
 // 不是04点，返回false
    return false;
}

/**
 * {@link org.apache.rocketmq.store.DefaultMessageStore.CleanCommitLogService#deleteExpiredFiles()}
 */
private void deleteExpiredFiles() {
    // isTimeToDelete()这个方法是判断是不是凌晨四点，是的话就执行删除逻辑。
    if (isTimeToDelete()) {
        // 默认是72，但是broker配置文件默认改成了48，所以新版本都是48。
        long fileReservedTime = 48 * 60 * 60 * 1000;
        deleteCount = DefaultMessageStore.this.commitLog.deleteExpiredFile(72 * 60 * 60 * 1000, xx, xx, xx);
    }
}
                                                                       
/**
 * {@link org.apache.rocketmq.store.CommitLog#deleteExpiredFile()}
 */
public int deleteExpiredFile(xxx) {
    // 这个方法的主逻辑就是遍历查找最后更改时间+过期时间，小于当前系统时间的话就删了（也就是小于48小时）。
    return this.mappedFileQueue.deleteExpiredFileByTime(72 * 60 * 60 * 1000, xx, xx, xx);
}

7. ¿Cuáles son los modos de consumo de RocketMQ?

El modelo de consumo lo determina el Consumidor y la dimensión de consumo es el Tema.

Consumo de clúster

1. Un mensaje solo será consumido por un consumidor en el mismo grupo

2. Cuando varios grupos consumen un tema al mismo tiempo, cada grupo tendrá un consumidor para consumir los datos.

Consumo de radiodifusión

El mensaje se consumirá para cada instancia de consumidor en un grupo de consumidores. Es decir, incluso si estos consumidores pertenecen al mismo grupo de consumidores, el mensaje será consumido una vez por cada consumidor del grupo de consumidores.

8. ¿Las noticias del consumidor son de empuje o de atracción?

RocketMQ no tiene un significado real de push, que son todos pulls. Aunque hay clases push, la implementación subyacente real usa el mecanismo de sondeo largo , es decir, el método pull.

La propiedad de intermediario longPollingEnable marca si el sondeo largo está habilitado. Predeterminado activado

El código fuente es el siguiente:

// {@link org.apache.rocketmq.client.impl.consumer.DefaultMQPushConsumerImpl#pullMessage()}
// 看到没，这是一只披着羊皮的狼，名字叫PushConsumerImpl，实际干的确是pull的活。

// 拉取消息，结果放到pullCallback里
this.pullAPIWrapper.pullKernelImpl(pullCallback);

Seguimiento: ¿Por qué quiere tomar la iniciativa de extraer mensajes en lugar de utilizar métodos de monitoreo de eventos?

El método controlado por eventos consiste en establecer una conexión larga y enviarla en tiempo real mediante eventos (envío de datos).

Si el corredor empuja mensajes activamente, es posible que la velocidad de empuje sea rápida y la velocidad de consumo sea lenta, lo que hará que el mensaje se acumule demasiado en el lado del consumidor y, al mismo tiempo, no será consumido por otros. consumidores. El método de extracción se puede tirar de acuerdo con la situación actual, sin causar demasiada presión y causar un cuello de botella. Entonces se adopta el método de tracción.

9. ¿Cómo maneja el corredor las solicitudes de extracción?

El consumidor solicita al corredor por primera vez

Si hay mensajes elegibles en el Broker
Si->
- Respondiendo al consumidor
- Esperando la próxima solicitud del consumidor
No
- DefaultMessageStore # ReputMessageService # ejecutar 方法
- PullRequestHoldService se conecta a Hold, y se ejecuta cada 5 segundos para verificar si hay mensajes en pullRequestTable y enviarlos inmediatamente si los hay.
- Compruebe si hay mensajes nuevos en commitLog cada 1 ms y escríbalos en pullRequestTable si hay alguno
- Solicitud de devolución cuando hay un mensaje nuevo
- Suspender la solicitud del consumidor, es decir, ni desconectar ni devolver datos
- Utilice la compensación del consumidor,

10. ¿Cómo realiza RocketMQ el equilibrio de carga?

Obtenga almacenamiento distribuido en múltiples Brokers a través de Topic.

productor 端

El remitente especifica la cola de mensajes para enviar el mensaje al corredor correspondiente para lograr el equilibrio de carga al escribir

Mejore el rendimiento de escritura. Cuando varios productores escriben datos en un intermediario al mismo tiempo, el rendimiento disminuirá
Los mensajes se distribuyen entre varios agentes para prepararse para el consumo de carga.

La estrategia predeterminada es elegir al azar:

El productor mantiene un índice
Cada vez que se toma el nodo, aumentará automáticamente
el índice toma el resto de todos los corredores
Estrategia de tolerancia a fallas incorporada

Otras implementaciones:

SelectMessageQueueByHash
- El hash son los argumentos entrantes
SelectMessageQueueByRandom
SelectMessageQueueByMachineRoom no está implementado

También puede personalizar el método de selección en la interfaz MessageQueueSelector

MessageQueue select(final List<MessageQueue> mqs, final Message msg, final Object arg);

consumidor 端

El algoritmo de distribución promedio se utiliza para el equilibrio de carga.

Otros algoritmos de equilibrio de carga

Estrategia de distribución promedio (predeterminada) (AllocateMessageQueueAveragely) Estrategia de distribución circular (AllocateMessageQueueAveragelyByCircle) Estrategia de distribución de configuración manual (AllocateMessageQueueByConfig) Estrategia de distribución de salas de computadoras (AllocateMessageQueueByMachineRoom) Estrategia de distribución de hash coherente (Allouelocate)

Seguimiento: ¿Qué sucede cuando el balanceador de carga del consumidor y la cola no son iguales?

Los consumidores y las colas se asignarán por igual en primer lugar. Si el número de consumidores es menor que el número de colas, algunos consumidores consumirán varias colas. Si el número de consumidores es igual al número de colas, entonces un consumidor consumirá una cola. Si el número de consumidores es mayor que el número de colas, algunos consumidores se salvarán, lo que se desperdicia.

11. Consumo repetido de mensajes

Una razón importante que afecta el envío y consumo normal de mensajes es la incertidumbre de la red.

Causas del consumo repetido

En circunstancias normales, después de que el consumidor realmente consume el mensaje, debe enviar un ack para notificar al corredor que el mensaje se ha consumido normalmente y eliminarlo de la cola.

Cuando el ack no se puede enviar al corredor debido a razones de la red, el corredor pensará que el mensaje de entrada no se ha consumido, y luego se activará el mecanismo de retransmisión del mensaje para entregar el mensaje al consumidor nuevamente.

Patrón de consumo

En el modo CLUSTERING, se garantiza que el mensaje será consumido por los consumidores del mismo grupo una vez en el corredor, pero los consumidores de diferentes grupos serán empujados varias veces.

solución

Tabla de base de datos

Antes de procesar el mensaje, utilice la clave principal del mensaje para insertarlo en el campo restringido de la tabla.

Mapa

Puede usar map ConcurrentHashMap -> putIfAbsent guava cache en modo independiente

Redis

Las cerraduras distribuidas están activas.

12. Cómo hacer que RocketMQ garantice el consumo secuencial de mensajes

Cuando usa middleware de mensajes para negocios en línea, ¿necesita asegurar el orden de los mensajes?

Si no hay necesidad de garantizar el orden de los mensajes, ¿por qué no ?, si tengo un escenario en el que quiero garantizar el orden de los mensajes, ¿cómo deberían garantizarlo?

En primer lugar, varias colas solo pueden garantizar el orden en una sola cola. La cola es un orden natural, FIFO típico. El consumo de varias colas al mismo tiempo no puede garantizar absolutamente el orden de los mensajes. Entonces, el resumen es el siguiente:

El mismo tema, la misma COLA, un hilo envía un mensaje al enviar un mensaje y un hilo consume un mensaje en una cola cuando consume.

Seguimiento: ¿Cómo garantizar que los mensajes se envíen a la misma cola?

Rocket MQ nos proporciona la interfaz MessageQueueSelector, puede reescribir la interfaz interna e implementar su propio algoritmo. Para dar el ejemplo más simple: juzgue i % 2 == 0, luego póngalo en queue1, de lo contrario, póngalo en queue2.

for (int i = 0; i < 5; i++) {
    Message message = new Message("orderTopic", ("hello!" + i).getBytes());
    producer.send(
        // 要发的那条消息
        message,
        // queue 选择器 ，向 topic中的哪个queue去写消息
        new MessageQueueSelector() {
            // 手动 选择一个queue
            @Override
            public MessageQueue select(
                // 当前topic 里面包含的所有queue
                List<MessageQueue> mqs,
                // 具体要发的那条消息
                Message msg,
                // 对应到 send（） 里的 args，也就是2000前面的那个0
                Object arg) {
                // 向固定的一个queue里写消息，比如这里就是向第一个queue里写消息
                if (Integer.parseInt(arg.toString()) % 2 == 0) {
                    return mqs.get(0);
                } else {
                    return mqs.get(1);
                }
            }
        },
        // 自定义参数：0
        // 2000代表2000毫秒超时时间
        i, 2000);
}

13. ¿Cómo se asegura RocketMQ de que los mensajes no se pierdan?

En primer lugar, puede haber mensajes perdidos en las siguientes tres partes:

Productor 端
Lado del corredor
Consumidor 端

13.1 Cómo asegurarse de que el mensaje no se pierda del lado del productor

Use send () para enviar mensajes de forma sincrónica, y el resultado del envío es consciente de forma sincrónica.
Puede volver a intentarlo después de que el envío haya fallado y establecer el número de reintentos. El valor predeterminado es 3 veces.

productor.setRetryTimesWhenSendFailed (10);

Implementación de clúster, por ejemplo, el motivo del error de envío puede ser que el Broker actual no funcione y se enviará a otros Brokers cuando se reintente.

13.2 ¿Cómo se asegura el Broker de que el mensaje no se pierda?

Modifique la estrategia de cepillado al cepillado sincrónico. De forma predeterminada, es una descarga asincrónica.

flushDiskType = SYNC_FLUSH

Implementación de clúster, modo maestro-esclavo, alta disponibilidad.

13.3 ¿Cómo se asegura el consumidor de que el mensaje no se pierda?

Una vez que el consumo completo es normal, se realiza una confirmación manual de acuse de recibo.

14. Cómo lidiar con la acumulación de mensajes de rocketMQ

Si el sistema de consumo descendente falla, lo que provoca una acumulación de millones de mensajes en el middleware de mensajes, ¿qué debo hacer en este momento?

¿Ha encontrado una falla de producción con una acumulación de noticias en línea? Si no la ha encontrado, ¿cómo considera cómo lidiar con ella?

Lo primero es averiguar qué provocó la acumulación de mensajes, ya sea por demasiados Productores, muy pocos Consumidores u otras situaciones, en fin, localice el problema primero.

Luego, verifique si la tasa de consumo de mensajes es normal. Si es normal, puede resolver temporalmente el problema de la acumulación de mensajes lanzando más consumidores en línea

Seguimiento: ¿Qué debo hacer si el consumidor y la cola no son iguales y varios dispositivos están en línea pero no pueden consumir los mensajes acumulados en poco tiempo?

Prepara un tema temporal
La cantidad de colas es varias veces la acumulación
La cola se distribuye a varios corredores
Ejecute un consumidor como portero de mensajes, mueva los mensajes del tema original al nuevo tema, no realice el procesamiento de la lógica empresarial, simplemente muévalo
N Los consumidores están en línea y consumen los datos del tema temporal al mismo tiempo
Arreglar error
Restaurar el consumidor original y continuar consumiendo el tema anterior

Seguimiento: ¿El tiempo de acumulación es demasiado largo y se agotó el tiempo de espera del mensaje?

El mensaje en RocketMQ solo desaparecerá cuando se elimine el commitLog y no se agotará el tiempo de espera. Es decir, los mensajes que no se hayan consumido no se eliminarán con el tiempo.

Seguimiento: ¿Los mensajes acumulados entrarán en la cola de mensajes no entregados?

No, el mensaje entrará en la cola de reintentos (% RETRY% + ConsumerGroup) después de que falle el consumo, 18 veces (predeterminado 18 veces, todos los artículos en Internet dicen 16 veces, sin excepción. Pero no entiendo por qué es 16 En segundo lugar, ¿no son 18 horas?) Antes de entrar en la cola de mensajes no entregados (% DLQ% + ConsumerGroup).

El código fuente es el siguiente:

public class MessageStoreConfig {
    // 每隔如下时间会进行重试，到最后一次时间重试失败的话就进入死信队列了。
 private String messageDelayLevel = "1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h";
}

15. ¿El principio subyacente del mecanismo de soporte de transacciones distribuidas de RocketMQ?

¿Está utilizando RocketMQ? Una gran característica de RocketMQ es su soporte para transacciones distribuidas. ¿Cuénteme sobre el principio subyacente de apoyar este mecanismo en transacciones distribuidas?

Las transacciones en sistemas distribuidos pueden usar TCC (Try, Confirm, Cancel), 2pc para resolver la atomicidad de los mensajes en sistemas distribuidos

RocketMQ 4.3+ proporciona funciones de transacciones distribuidas, a través de los mensajes de transacciones de RocketMQ, se puede lograr la consistencia final de las transacciones distribuidas

Método de implementación de RocketMQ:

** Medio mensaje: ** Preprocese el mensaje, cuando el corredor reciba dicho mensaje, se almacenará en la cola de consumo de mensajes de RMQ_SYS_TRANS_HALF_TOPIC

** Verifique el estado de la transacción: ** El corredor iniciará una tarea cronometrada para consumir mensajes en la cola RMQ_SYS_TRANS_HALF_TOPIC. Cada vez que se ejecuta la tarea, el estado de ejecución de la transacción (compromiso, reversión, desconocido) se confirmará al remitente del mensaje. Si se desconoce, el corredor irá a la devolución de llamada con regularidad y volverá a verificar.

** Tiempo de espera: ** Si se excede el número de comprobaciones, el mensaje se revierte de forma predeterminada.

Es decir, en realidad no ingresó a la cola de Temas, sino que usó una cola temporal para colocar el llamado medio mensaje, y después de que se envió la transacción, el medio mensaje se transfirió realmente a la cola debajo del tema.

16. Si se le pide que implemente un middleware de mensajería distribuida, ¿cómo diseñaría e implementaría la arquitectura general?

Personalmente pienso responder desde los siguientes puntos:

Es necesario tener en cuenta la capacidad de expandirse rápidamente y admitir clústeres de forma natural.
Postura persistente
Alta disponibilidad
Consideraciones de pérdida de datos 0
Fácil de implementar en el lado del servidor y fácil de usar en el lado del cliente

17. ¿Ha leído el código fuente de RocketMQ? Si lo ha leído, dígame su comprensión del código fuente de RocketMQ.

Si realmente quieres que me lo diga, me quejaré. En primer lugar, no hay ningún comentario. Tal vez Alibaba escribió un comentario en chino antes. Después de donarlo a apache, apache sintió que el comentario en chino no se podía guardar y yo estaba Demasiado perezoso para escribir comentarios en inglés, así que les di todos. Los patrones de diseño más típicos son los patrones singleton, de fábrica, de estrategia y de fachada. Las fábricas de singleton están en todas partes y las estrategias son impresionantes. Por ejemplo, cuando se envían y consumen mensajes, el equilibrio de carga de la cola es de N tipos de algoritmos de estrategia, incluidos aleatorio, hash, etc. Esta es también una de las razones necesarias para poder realizar rápidamente expandir el grupo de apoyo natural. La persistencia también es relativamente completa, utilizando CommitLog para colocar el disco, de forma sincrónica y asincrónica.

18.¿Cómo optimizar el desempeño de productores y consumidores con alto rendimiento?

Desarrollo

Despliegue de varias máquinas y consumo paralelo en el mismo grupo
Un solo consumidor aumenta el número de subprocesos de consumidores
Consumo a granel
- Extracción por lotes de mensajes
- Procesamiento por lotes de lógica empresarial

Operación y mantenimiento

Sintonización de tarjetas de red
tuning jvm
Múltiples subprocesos y ajuste de cpu
Página de caché

19. Permítanme hablar sobre cómo RocketMQ garantiza la alta tolerancia a fallas de los datos.

Cuando la tolerancia a fallas no está habilitada, sondee la cola para enviar. Si falla, filtre el Broker fallado cuando vuelva a intentarlo.
Si la estrategia de tolerancia a fallas está habilitada, el mecanismo de predicción de RocketMQ se utilizará para predecir si un corredor está disponible
Si el corredor que falló la última vez está disponible, la cola del corredor aún estará seleccionada
Si la situación anterior falla, seleccione al azar uno para enviar
Al enviar un mensaje, registrará la hora de la llamada y si se informa de un error, y predecirá el tiempo disponible del corredor en función del tiempo.

De hecho, es la opción de cola al enviar un mensaje. El código fuente es el siguiente:

org.apache.rocketmq.client.latency.MQFaultStrategy#selectOneMessageQueue()

20. ¿Qué debo hacer si algún corredor cae repentinamente?

Arquitectura de intermediario maestro-esclavo y estrategia de copias múltiples. Una vez que el maestro recibe el mensaje, lo sincronizará con el esclavo, de modo que haya más de un mensaje, y el maestro esté inactivo y el mensaje en el esclavo esté disponible, lo que garantiza la confiabilidad y alta disponibilidad de MQ. Y Rocket MQ4.5.0 ha admitido el modo Dlegder desde el principio, basado en la balsa, para lograr una sensación real de HA.

21. ¿Con qué servidor de nombres Broker registra su información?

Preguntar esto obviamente lo está enfrentando, porque Broker registrará su propia información en todos los NameServers, no en uno, sino en todos, ¡todos!