Entrevista de Alibaba: Cuéntenos sobre MQ utilizado en su proyecto. ¿Cuál es el papel de MQ en los sistemas distribuidos?
En la entrevista con Ali, el entrevistador hizo varias preguntas sobre MQ:
He escrito un artículo antes sobre la implementación de bloqueos distribuidos de rocketMQ, que presenta principalmente cómo usarlos para implementar RocketMQ. locks,
"Springcloud RocketMQ resuelve transacciones distribuidas"
Sin embargo, esta función no es la función básica de MQ, ni es una función que tengan todos los MQ.
¿Cuál es el papel de MQ en el sistema? Dejando de lado la publicación y suscripción de mensajes básicos, existen los siguientes puntos:
En un sistema distribuido, se llama mediante reposo o mediante llamadas RPC como dubbo, pero algunos escenarios requieren un diseño de desacoplamiento, no se puede llamar directamente.
Por ejemplo, en un sistema basado en mensajes, el remitente del mensaje completa el negocio local y envía el mensaje. El servicio al consumidor de mensajes multiplataforma necesita recibir el mensaje enviado y luego continuar procesando otros negocios.
Al observar estos dos diagramas de arquitectura, el primer tipo de BC depende directamente del servicio A. Entonces, si se modifica la interfaz en A, BC se modificará en consecuencia y el grado de acoplamiento es alto.
El segundo método es utilizar MQ como middleware para enviar y recibir mensajes. BC solo se basa en los mensajes recibidos en lugar de en la interfaz específica. solo necesita suscribirse a MQ.
Tome el proceso comercial de registro de usuario como ejemplo.
En el diseño original del sistema, dicho proceso de servicio se procesará en serie, es decir, 1-2-3 primero; Puedes pensarlo aquí, si en el caso de un solo servicio y una sola máquina, hay tantos usuarios registrados. ¿Puede el sistema soportarlo?
Supongamos aquí que el tiempo de cada etapa es 1 = 50 ms, 2 = 50 ms, 3 = 50 ms, entonces una solicitud será toda = 150 ms.
Supongamos aquí que la CPU del servidor; = 1, y solo puede manejar un solo subproceso, luego calcule el QPS de este único subproceso de un solo servidor QPS = 1000/150 ≈ 7
Ahora quiero aumentar este QPS * 3 tres veces. Introduciendo el servicio MQ como middleware
Como se puede ver en la figura, después de completar el registro de usuario del servicio A, regresé directamente. En este momento, MQ se usaba para enviar mensajes de procesamiento asincrónicos y los servicios B. y C los procesó por separado.
A no necesita esperar los resultados de B y C, por lo que la experiencia del usuario es de solo 50 ms de tiempo de espera. En la etapa de correo electrónico y SMS, los usuarios pueden aceptar un cierto período de espera debido a retrasos en la red.
Para servicios generales, nuestras solicitudes de acceso al sistema son solicitudes directas. Este modelo no es un gran problema cuando el número de visitas de usuarios no es grande.
Pero si las solicitudes de los usuarios alcanzan un cierto cuello de botella o causan algunos problemas, debemos considerar la optimización de nuestro diseño de arquitectura como una de las soluciones.
Tomemos el sistema Flash Kill como ejemplo para analizar el problema.
El sistema Flash Kill tiene millones de concurrencias en un instante. Generalmente, el sistema de venta flash filtrará las solicitudes no válidas y duplicadas, y el resto ingresará al servicio de venta flash y al servicio de pedidos.
Pero aun así, la concurrencia sigue siendo muy alta. Si la puerta de enlace reenvía todas las solicitudes al servicio de pedidos descendentes, también abrumará el sistema descendente, provocando indisponibilidad del servicio o incluso una avalancha.
El sistema de venta flash real es más complejo e incluye Nginx, puerta de enlace, centro de registro, caché de Redis, clúster mysql y clúster de cola de mensajes.
La solución es procesar tareas más rápidas en sentido ascendente. Agregue a la cola para su procesamiento y el flujo descendente consumirá la cola una por una hasta que se complete todo el consumo de la cola.
Si el número de solicitudes de procesamiento del servicio de venta flash es: 1000/s,
La solicitud de procesamiento del servicio de pedidos posteriores es: 10/s,
En orden Para no causar ningún daño a la presión del servicio de pedidos posteriores, la información después de la venta flash se envía a la cola y el servicio de pedidos puede procesar tranquilamente diez solicitudes por segundo, en lugar de llenar directamente 1000 solicitudes.
Independientemente de si están dispuestos o no.
En este punto, puede resumir el método de filtrado del sistema de venta flash:
Todos los servicios envían registros al servicio MQ para su almacenamiento.
MQ sirve como middleware para conservar y reenviar registros
El servicio de big data lee y analiza registros en MQ
Alguien se acercó e hizo una comparación de rendimiento. dijo que RabbitMQ es el mejor MQ del mundo...
Compare elegir MQ con elegir una esposa. Necesitas un conjunto completo, piel clara, apariencia hermosa, sexy y capaz. . .
Realmente falta educación social, hermano
¿Te lo puedes permitir? Hay un paquete de mantenimiento disponible a 1 W/mes
¿Puedes conservarlo? Lao Wang, el vecino, suele venir a cenar a tu casa, imaginación loca. . .
¿Está bien comer? Dátiles rojos, baya de goji y tabletas Shenbao, me temo que no estoy lo suficientemente dispuesto
Volvamos al tema, de hecho, creo que esta es una pregunta en la que debemos pensar. lo que hay que mirar es ¿cuáles son las condiciones?
El mensaje de registro de ejemplo en la imagen de arriba usa kafka.
Kafka es el sistema de mensajería de publicación y suscripción distribuido de código abierto de LinkedIn. Es un proyecto Apache de alto nivel y tiene una comunidad activa.
La característica principal de Kafka es manejar el consumo de mensajes en función del modo Pull y lograr un alto rendimiento. Su propósito inicial es utilizar la recopilación y transmisión de registros.
Las versiones posteriores comenzaron a admitir la replicación, pero no admitían transacciones. No tenían requisitos estrictos para la duplicación, pérdida y errores de mensajes, y eran adecuadas para empresas de recopilación de datos de servicios de Internet que generan grandes cantidades de datos. datos.
Sin embargo, Kafka es relativamente pesado y necesita confiar en zookeeper. No es un problema usarlo en grandes empresas y requiere un mantenimiento dedicado.
RocketMQ es un sistema de mensajería fiable de código abierto desarrollado por Alibaba y ha sido donado a Apache para que se convierta en un proyecto de primer nivel. Inicialmente estaba destinado a la transmisión de mensajes confiables sin registros, pero su rendimiento en el procesamiento de registros es bastante bueno.
Los clientes actualmente soportados incluyen java, cy GO. La comunidad es relativamente activa y la documentación es bastante completa. Pero todavía es difícil modificar los aspectos centrales. Después de todo, Alibaba Cloud gana dinero vendiendo este servicio.
Entonces, si la empresa no confía en su solidez, es mejor elegir con cuidado. Si no es posible, puede comprar directamente servicios en la nube para ahorrar preocupaciones y esfuerzos. situación.
La siguiente imagen es de Internet. Parte de la descripción está desactualizada, pero básicamente no está mal. Es solo como referencia:
Aquí hay una breve explicación. Más adelante escribiré una confesión específicamente para este tema.
Se debe aproximadamente a algunas razones especiales, como razones de red y reinicio del servicio, que hacen que el consumo de mensajes no se registre, lo que resulta en la posibilidad de un consumo repetido.
El enfoque general es garantizar la idempotencia del diseño de la interfaz y el propósito es determinar si existe a través de un identificador único.