Recientemente, esto no ha alcanzado al nueve de oro y diez de plata, y la compañía también entrevistó a algunos. Afortunadamente, seguí al jefe y pasé por algunas escenas de entrevistas, una de las cuales realmente me impresionó.
Dijo que era un ingeniero senior en la empresa original, lo que era equivalente a una columna vertebral técnica, y los proyectos de la empresa también eran buenos. Cuando el jefe y yo nos sentimos bien, le hice una pregunta más, ¿cómo eliges tu middleware de mensajes? El hermano mayor me respondió: El jefe decidió usar esto
Volviéndome para mirar la cara del jefe que se estaba petrificando gradualmente, le pregunté por el middleware RocketMQ que usaban. . . . No hablaré del resto (hermano mayor, comiste un bocadillo durante la entrevista). Afortunadamente, hay un proyecto en nuestra empresa que usa la tecnología y la arquitectura y él respondió bien, de lo contrario, oye. . .
A continuación, técnicamente, veamos por qué eligieron RocketMQ en ese momento. De hecho, esta tecnología es realmente buena.
Introducción a RocketMQ
Apache RocketMQ es un middleware de mensajería distribuida con baja latencia, alta concurrencia, alta disponibilidad y alta confiabilidad. La cola de mensajes RocketMQ puede proporcionar capacidades asincrónicas de desacoplamiento, reducción de picos y llenado de valles para sistemas de aplicaciones distribuidas. También tiene las características de acumulación masiva de mensajes, alto rendimiento y reintento confiable que requieren las aplicaciones de Internet.
Concepto RocketMQ
- Tema: tema del mensaje, que se utiliza para clasificar un tipo de mensaje, como el tema del pedido, es decir, todos los mensajes relacionados con el pedido pueden ser transportados por este tema, y el productor envía mensajes a este tema.
- Productor: El rol responsable de producir mensajes y enviarlos a Topic.
- Consumidor: el rol responsable de recibir y consumir mensajes de Topic.
- Mensaje: El contenido enviado por el productor al Tema será consumido por el consumidor.
- Atributos del mensaje: el productor puede personalizar algunos atributos relacionados con la empresa para el mensaje al enviarlo, como la clave y la etiqueta del mensaje.
- Grupo: Un tipo de productor o consumidor, este tipo de productor o consumidor generalmente produce o consume el mismo tipo de mensaje, y la lógica de publicación o suscripción de mensajes es consistente.
¿Por qué utilizar RocketMQ?
Desacoplamiento asincrónico
Con la popularidad de la arquitectura de microservicios, es muy importante resolver la relación entre los servicios. El desacoplamiento asincrónico puede reducir el grado de acoplamiento entre servicios, al tiempo que aumenta el rendimiento de los servicios.
Hay muchos escenarios de negocios que utilizan el desacoplamiento asincrónico, porque el negocio de cada industria será diferente, creo que todos pueden entenderlo con algunos negocios más comunes.
Por ejemplo, en el escenario empresarial de realizar un pedido en la industria del comercio electrónico, el proceso de pedido más simple es el siguiente:
- Bloquear inventario
- Crear orden
- Pago de usuario
- Deducción de inventario
- Enviar notificación de compra por SMS a los usuarios
- Agregar puntos a los usuarios
- Notificar al comerciante que envíe
Después de que nuestro pedido se haya realizado correctamente, el usuario realizará un pago. Después de que se complete el pago, habrá una lógica llamada devolución de llamada de pago, y es necesario realizar alguna lógica comercial en la devolución de llamada. Primero, observe el tiempo que se tarda en sincronizar, como se muestra a continuación:
El proceso de pedido anterior de 3 a 5 se puede procesar en un proceso asincrónico.Para el usuario, una vez completado el pago, no necesita prestar atención al siguiente proceso. El procesamiento lento en segundo plano es suficiente, lo que puede simplificar los tres pasos y mejorar el tiempo de procesamiento de las devoluciones de llamada.
Corte de picos y llenado de valles
La reducción de picos y el llenado de valles significan que, bajo el impacto de un gran tráfico, RocketMQ puede soportar un gran tráfico instantáneo, proteger la estabilidad del sistema y mejorar la experiencia del usuario.
En la industria del comercio electrónico, el impacto de tráfico más común es la actividad de picos. El uso de RocketMQ para lograr un negocio de picos completo todavía es mucho trabajo por hacer. Está más allá del alcance de este artículo. Tengo la oportunidad de hablar contigo a solas más adelante. Lo que quiero decirles es que escenarios como este pueden usar RocketMQ para manejar una alta concurrencia, siempre que el escenario empresarial admita el procesamiento asincrónico .
Consistencia eventual de transacciones distribuidas
Como todos sabemos, las transacciones distribuidas tienen 2PC, TCC, consistencia eventual y otras soluciones. Entre ellos, el uso de colas de mensajes para eventuales soluciones de coherencia es el más utilizado.
En el escenario empresarial del comercio electrónico, el negocio principal relacionado con las transacciones debe garantizar la coherencia de los datos. Al introducir la transacción distribuida de la versión RocketMQ de la cola de mensajes, se puede lograr el desacoplamiento entre sistemas y se puede garantizar la consistencia de los datos finales.
Distribución de datos
La distribución de datos se refiere a la capacidad de distribuir los datos originales a múltiples sistemas que necesitan utilizar estos datos para lograr la heterogeneidad de los datos. Lo más común es distribuir datos a ES, Redis para proporcionar servicios como búsqueda y almacenamiento en caché para empresas.
Además de la distribución manual de datos a través del mecanismo de mensajes, también puede suscribirse al binlog de Mysql para distribuir. En este escenario, debe utilizar los mensajes secuenciales de RocketMQ para garantizar la coherencia de los datos.
Arquitectura RocketMQ
Fuente de la imagen Documento oficial de Alibaba Cloud
- Servidor de nombres: Es un nodo casi sin estado que se puede implementar en clústeres, brinda servicios de nombres en la versión RocketMQ de la cola de mensajes, actualizando y descubriendo los servicios del Broker. Es un registro.
- Broker: Rol de retransmisión de mensajes, responsable de almacenar y reenviar mensajes. Se divide en Master Broker y Slave Broker. Un Master Broker puede corresponder a varios Slave Brokers, pero un Slave Broker solo puede corresponder a un Master Broker. Una vez que el Broker se inicia, debe completar una operación de registro en el servidor de nombres; luego, informa periódicamente la información de enrutamiento del tema al servidor de nombres cada 30 segundos.
- Productor: establezca un enlace largo (Keep-alive) con uno de los nodos en el clúster del servidor de nombres (aleatoriamente), lea periódicamente la información de enrutamiento del tema del servidor de nombres y establezca un enlace largo con el intermediario principal que proporciona los servicios del tema, e informe periódicamente al maestro. El corredor envía un latido.
- Consumidor: establezca una conexión larga con uno de los nodos en el clúster del servidor de nombres (aleatoriamente), extraiga regularmente la información de enrutamiento del tema del servidor de nombres y establezca una conexión larga con el agente principal y el agente esclavo que brindan servicios de tema, y envíelo regularmente al agente principal. Slave Broker envía un latido. Los consumidores pueden suscribirse a los mensajes de Master Broker o Slave Broker Las reglas de suscripción están determinadas por la configuración del Broker.
Tipo de mensaje de RocketMQ
RocketMQ admite tipos de mensajes enriquecidos, que pueden satisfacer las necesidades comerciales de múltiples escenarios. Los diferentes mensajes tienen diferentes escenarios de aplicación. A continuación, se muestran cuatro tipos de mensajes de uso común.
Noticias generales
Los mensajes comunes se refieren a mensajes sin características en RocketMQ. Cuando no existe un escenario comercial especial, los mensajes ordinarios son suficientes. Si hay escenarios especiales, puede utilizar tipos de mensajes especiales, como secuencia, transacción, etc.
Enviar sincrónicamente
Envío síncrono: el remitente del mensaje envía un mensaje y el resultado devuelto por el servidor se sincronizará.
Envío asincrónico
Envío asincrónico: el remitente del mensaje envía un mensaje sin esperar a que el servidor devuelva el resultado y puede enviar el siguiente mensaje. El remitente puede recibir la respuesta del servidor a través de la interfaz de devolución de llamada y procesar el resultado de la respuesta.
Envío unidireccional
Envío unidireccional: el remitente del mensaje solo es responsable de enviar el mensaje, y después de enviarlo, la velocidad de envío es muy rápida y existe el riesgo de perder el mensaje.
Mensaje secuencial
La mensajería secuencial significa que los productores publican mensajes en un orden determinado; los consumidores se suscriben a los mensajes en un orden predeterminado, es decir, los mensajes que se publican primero serán recibidos primero por los consumidores.
Por ejemplo, en el escenario de distribución de datos, si nos suscribimos al binlog de Mysql para la heterogeneidad de datos. Si los mensajes están fuera de orden, habrá desorden de datos.
Por ejemplo, agregue un dato con id = 1 y luego elimínelo inmediatamente. Esto da como resultado dos mensajes. La secuencia de consumo normal es agregar primero, luego eliminar, en este momento no hay datos. Si los mensajes no están en orden, primero se consumen los eliminados y luego se consumen los recién agregados. En este momento, los datos siguen ahí y no se eliminan, lo que generará inconsistencias.
Mensaje cronometrado
Mensaje programado significa que el mensaje tiene la función de envío programado. Cuando el mensaje se envía al servidor, no se entregará al consumidor de inmediato. En cambio, el mensaje no se entregará a los consumidores para su consumo hasta el momento especificado por el mensaje.
Los mensajes retrasados también son mensajes cronometrados. Los mensajes cronometrados están programados para enviarse en un momento determinado, como 2020-11-11 12:00:00.
Los mensajes retrasados generalmente se basan en la hora de envío actual según la duración del retraso. Por ejemplo, la hora actual es 2020-09-10 12:00:00, y la demora es de 10 minutos, luego el mensaje se enviará a las 2020-09-10 12:10 después de que el mensaje se envíe correctamente. : 00 para entrega a consumidores.
Los mensajes programados se pueden usar en escenarios como la cancelación automática de pedidos sin pago después del tiempo de espera.
Mensaje de transacción
RocketMQ proporciona una función de transacción distribuida similar a X / Open XA. A través de los mensajes de transacción de RocketMQ, se puede lograr la consistencia final de las transacciones distribuidas.
Proceso interactivo:
Fuente de la imagen Documento oficial de Alibaba Cloud
- El remitente primero envía un mensaje semi-transaccional al servidor RocketMQ.
- Después de que el servidor de RocketMQ recibe el mensaje y lo persiste con éxito, devuelve un Ack al remitente para confirmar que el mensaje se ha enviado correctamente. En este momento, el mensaje es un mensaje semitransaccional y no se entregará al consumidor.
- Después de recibir el Ack del mensaje semi-transaccional, el remitente comienza a ejecutar la lógica de transacción local.
- El remitente envía una segunda confirmación al servidor en función del resultado de la ejecución de la transacción local. Si la transacción local se ejecuta correctamente, el mensaje se confirma, si la ejecución falla, el mensaje se revierte y el servidor recibe el estado de confirmación y marca el mensaje semitransacional como entregable. , El consumidor eventualmente recibirá el mensaje; el servidor eliminará el mensaje semi-transaccional cuando reciba el estado Rollback y el consumidor no recibirá el mensaje.
- Si ocurre una situación inesperada, no hay una segunda confirmación del mensaje en el paso 4, y el servidor iniciará una verificación de retroceso del mensaje después de esperar un tiempo fijo.
- Después de recibir el mensaje, el remitente debe verificar el resultado final de la ejecución de la transacción local del mensaje correspondiente. El remitente vuelve a enviar la segunda confirmación de acuerdo con el estado final de la transacción local obtenida por la inspección, y el servidor aún realiza operaciones en el mensaje de media transacción de acuerdo con el paso 4.
Mejores prácticas
Reintentar mensaje
Después de que el consumidor no consuma el mensaje, el servidor de RocketMQ volverá a enviar el mensaje, sabiendo que el consumidor ha consumido con éxito el mensaje, por supuesto, hay un límite en el número de reintentos, 16 por defecto.
El reintento del mensaje garantiza que el mensaje no se pierda hasta cierto punto y que el consumo final se logre mediante el reintento. Cabe señalar que cuando los consumidores consumen, deben esperar el éxito del negocio local antes del ACK (confirmación de consumo), de lo contrario se producirá un fallo de consumo, pero el ACK ya se ha realizado y el mensaje no se entregará repetidamente.
Si usa el consumo asíncrono, debe convertir de asíncrono a síncrono y esperar hasta que se complete la operación asíncrona antes de ACK
Por último, es necesario hacer el seguimiento correspondiente. Si lo reintenta 4 o 5 veces, aún falla. Básicamente, los reintentos posteriores también fallan. En este momento, debe informar al desarrollador que el procesamiento manual es una intervención manual. O supervise directamente la cola de mensajes no entregados.
Filtrado de mensajes
Asunto del mensaje, generalmente utilizado para la clasificación unificada de un tipo de mensaje. Por ejemplo, el asunto del pedido, pero los mensajes del pedido se dividirán en muchos tipos. Por ejemplo, crear un pedido, cancelar un pedido, etc.
Los diferentes tipos de mensajes tienen diferentes procesos comerciales. Podemos definir el formato del mensaje de manera uniforme y luego usar un campo para distinguir los tipos de mensajes para realizar diferentes lógicas comerciales. El punto malo es que todos los mensajes se enviarán al consumidor y no se pueden consumir a pedido.
En RocketMQ, puede asignar etiquetas a los mensajes y distinguir los tipos de mensajes por etiqueta. Los consumidores pueden completar el filtrado de mensajes en el servidor RocketMQ en función de las etiquetas para garantizar que los consumidores solo consuman los tipos de mensajes que les interesan.
Una vez encontré una etiqueta que no se usó correctamente, solo había una instancia de MQ y las etiquetas se usaron para distinguir el entorno. Todos los mensajes están en un tema, el entorno de prueba consume la etiqueta del entorno de prueba y la etiqueta del consumidor en línea está en línea.
El problema con este enfoque es que los mensajes no están aislados y los mensajes en línea y fuera de línea están todos juntos. La otra es que las etiquetas se fijan como una distinción entre entornos y no se pueden utilizar en escenarios de tipo de mensaje. Como resultado, varios temas solo se pueden crear para que incluyan varios tipos de mensajes comerciales.
Patrón de consumo
Hay dos modos de consumo para RocketMQ, consumo de clúster y consumo de transmisión.
Consumo de clúster:
Los consumidores implementan varias instancias, que llamamos clúster, y el consumo del clúster solo será consumido por una de las instancias.
Adecuado para la mayoría de los escenarios comerciales. En la mayoría de los escenarios, nuestro mensaje solo se puede consumir una vez y solo un consumidor puede consumirlo. Por ejemplo, en el escenario de devolución de llamada de pago, si un mensaje es consumido por varias instancias al mismo tiempo, habrá un consumo simultáneo. Modificar el estado del pedido y deducir el inventario.
Consumo de emisión:
El consumo de difusión hará que cada instancia del clúster consuma una vez.
Por ejemplo, usamos un caché local.Cuando los datos cambian, necesitamos actualizar el caché local de cada nodo, por lo que cada nodo necesita recibir un mensaje.
Idempotencia de consumo
El problema idempotente se encuentra tanto en el escenario de solicitud de API como en el escenario de consumo de mensajes. Un mensaje no se puede consumir repetidamente varias veces. Esto debe garantizarse, porque no podemos garantizar que el remitente del mensaje no lo envíe varias veces, ni tampoco podemos garantizar que el mensaje no se entregue repetidamente.
La semántica de entrega Exactly-Once de RocketMQ se utiliza para resolver problemas idempotentes. Exactamente una vez significa que el mensaje enviado al sistema de mensajería solo puede ser procesado por el consumidor y procesado solo una vez. Incluso si el productor que vuelve a intentar enviar el mensaje hace que el mensaje se entregue repetidamente, el mensaje solo se consumirá una vez en el consumidor.
El mejor método de procesamiento idempotente aún necesita un identificador comercial único. Aunque cada mensaje tiene un MessageId, no se recomienda usar MessageId para hacer juicios idempotentes. Al enviar mensajes, puede establecer una MessageKey para cada mensaje. Esta clave de mensaje se puede utilizar para identificar de forma única la empresa.
Esquema general de implementación idempotente.
Encapsulación de mensajes de transacciones locales
El mensaje de transacción se presentó anteriormente. El mensaje de transacción de RocketMQ adopta el método de confirmación de dos fases. Y combinado con el mecanismo de contraste de mensajes para garantizar la coherencia final.
Desde la perspectiva del uso, cada escenario empresarial tiene que implementar una lógica contrastante, lo cual es un poco molesto.
Aquí hay otro método de uso frecuente, que son los mensajes de transacciones locales. La tabla de mensajes local fue propuesta originalmente por eBay. Los mensajes de transacciones locales deben crear una tabla de mensajes en la base de datos correspondiente al servicio. Al enviar un mensaje, el mensaje no se envía realmente a MQ, pero los datos del mensaje se insertan en la tabla de mensajes.
La acción insertada es la misma transacción que la lógica comercial local. Si la transacción local se ejecuta correctamente, el mensaje se eliminará y enviará a MQ. Si la transacción local falla, los datos del mensaje se revertirán.
Luego, necesita un programa especial para extraer los mensajes no enviados en la tabla de mensajes y entregarlos a MQ. Si la entrega falla, puede seguir intentándolo hasta que tenga éxito o la intervención manual.
El mensaje se escribe en la tabla de mensajes y luego se envía a MQ todo el tiempo.Este paso no es un problema. Si después de que MQ recibe el mensaje, el Broker está inactivo mientras el mensaje todavía está en PageCache y el mensaje se pierde en este momento. Por supuesto, también puede utilizar el flasheo sincrónico para evitar pérdidas. Si vaciamos el disco de forma asincrónica, ¿hay alguna forma de garantizar que el mensaje no se pierda?
Como mencionamos anteriormente, los mensajes de transacción de RocketMQ tendrán un mecanismo de verificación, y el método de la tabla de mensajes también necesita un mecanismo para garantizar que el mensaje se consuma; de lo contrario, deberá reintentar constantemente enviar el mensaje hasta que se consuma el mensaje.
Es necesario que haya un campo en la tabla de mensajes para identificar el estado actual del mensaje, como no enviado, enviado y consumido. Cuando el mensaje aún no se envía, se enviará a MQ. Si el envío es exitoso, se envía el estado. Pero después de unos minutos, el estado aún se envía, esta vez necesitamos hacer algunas acciones.
En este escenario, es posible que los consumidores no puedan mantenerse al día con la velocidad de producción y que los mensajes se hayan acumulado, dando como resultado mensajes que no se hayan consumido. ¿Otra posibilidad es que el mensaje se pierda?
Puede obtener los datos de acumulación de mensajes correspondientes para determinar si el mensaje se ha acumulado, si no, reenviar el mensaje a MQ, sabiendo que el mensaje se ha consumido.
El problema es que el mensaje se ha consumido, ¿cómo lo sé?
Al igual que el servicio en la nube que utilizo, existe una API abierta correspondiente que puede consultar directamente el seguimiento de mensajes. También debería haber una versión de código abierto, que sin un estudio detenido debería ser similar a la versión comercial.
Según la trayectoria del mensaje, puede saber si el mensaje se ha consumido y el proceso termina aquí. Si el mensaje enviado a MQ falla, se volverá a intentar. Si el mensaje no se consume durante mucho tiempo, se reenviará. Incluso si finalmente ingresa a la cola de mensajes no entregados, se puede intervenir manualmente a través del monitoreo de la cola de mensajes no entregados. Definitivamente será la consistencia final.
En comparación con el mensaje de transacción incorporado, el método de la tabla de mensajes local no necesita implementar la lógica de verificación, pero es problemático aumentar la tabla de mensajes y también admite varias lógicas de envío y verificación. Especialmente cuando la cantidad de mensajes es grande, la forma de enviar rápidamente los mensajes en la tabla de mensajes requiere mucho procesamiento. El sondeo de búsqueda de tabla simple no es adecuado para grandes cantidades.
Se pueden utilizar ambos métodos, siempre que se logre el propósito que queremos.
Debido a las limitaciones de espacio, RocketMQ mostrará una pequeña parte, similar al código fuente y las operaciones reales de la empresa.
La compilación de esta información, además de RocketMQ, existen RabbitMQ, ActiveMQ, Kafka , teoría de la cola de mensajes y protocolo de mensajes, todo desde el nivel del código fuente subyacente.
RabbitMQ
ActiveMQ
Kafka
Me pregunto si este documento de middleware de código fuente + mensaje gráfico despierta su interés. De hecho, lo más importante de este documento es que tiene un análisis de código muy detallado, durante el proceso de aprendizaje puedes practicarlo tú mismo para comprobar el efecto y lograr un efecto multiplicador.
Aquellos que necesitan esta información, vamos
