Este artículo primero explica qué problemas suele necesitar resolver el middleware de mensajes, qué dificultades se encontrarán para resolver estos problemas, si Apache RocketMQ puede resolverse como un middleware de mensajes distribuidos de alto rendimiento y alto rendimiento de código abierto por Alibaba, y cómo se definen estos problemas en la especificación. Este artículo introducirá después el diseño arquitectónico de RocketMQ, para ofrecer a los lectores una comprensión rápida de RocketMQ.
1. ¿Qué problemas debe resolver el middleware de mensajes? Publicar/Suscribirse es la función más básica del middleware de mensajes y también es relativa a la comunicación tradicional RPC. No entraré en detalles aquí.
La prioridad descrita en la especificación de Prioridad de Mensaje se refiere a una cola de mensajes, cada mensaje tiene una prioridad diferente, generalmente descrita por enteros, el mensaje con alta prioridad se entrega primero; si el mensaje está completamente en una cola de memoria, entonces puede ordenarse según la prioridad antes de la entrega, de modo que la alta prioridad se entregue primero.
Dado que todos los mensajes en RocketMQ son persistentes, si se ordenan según la prioridad, la sobrecarga será muy grande, por lo que RocketMQ no soporta específicamente la prioridad de mensajes, pero puede implementar funciones similares en una solución alternativa, es decir, configurar una cola con alta prioridad y otra con prioridad normal, y enviar diferentes prioridades a distintas colas.
Para los temas prioritarios, se pueden resumir en 2 categorías:
- Mientras se cumpla la prioridad, no es una prioridad en el sentido estricto, y la prioridad suele dividirse en niveles altos, medios, bajos o varios más. Cada prioridad puede representarse con un tema diferente y, al enviar un mensaje, especificar diferentes temas para representar la prioridad, lo que puede resolver la mayoría de los problemas de prioridad, pero comprometer la precisión de las prioridades empresariales.
- Prioridad estricta, la prioridad se expresa como un entero, como 0 ~ 65535; este tipo de problema de prioridad generalmente no es adecuado para resolverse con diferentes temas. Si quieres que MQ resuelva este problema, tendrá un impacto muy grande en el rendimiento de MQ. Aquí va un punto para asegurarse de que la empresa realmente necesita esta estricta priorización, y si las prioridades se comprimen en pocas, ¿cuánto impacto tendrá en el negocio?
El orden de mensaje se refiere a un tipo de mensaje que puede consumirse en el orden en que se envía. Por ejemplo, un pedido genera 3 mensajes: creación de pedido, pago del pedido y finalización del pedido. Al consumir, es significativo consumir en este orden. Pero al mismo tiempo, los pedidos pueden consumirse en paralelo.
RocketMQ puede garantizar estrictamente que los mensajes sean ordenados.
Filtro de mensajes Broker Filtrado de mensajes
En Broker, filtrar según los requisitos del consumidor tiene la ventaja de reducir la transmisión de mensajes innecesarios al consumidor.
La desventaja es que aumenta la carga para el corredor y es relativamente complejo de implementar.
1. Taobao Notify soporta una variedad de métodos de filtrado, incluyendo filtrado directo por tipo de mensaje y filtrado flexible de expresiones sintácticas, que pueden cubrir casi las necesidades de filtrado más exigentes.
2. Taobao RocketMQ soporta filtrar por simple etiqueta de mensaje, así como por encabezado y cuerpo de mensaje.
3. El filtrado flexible de expresiones sintácticas también está soportado en la especificación de notificaciones CORBA.
Filtrado de mensajes del lado del consumidor
Este filtrado puede personalizarse completamente por la aplicación, pero la desventaja es que se envían muchos mensajes inútiles al consumidor.
Existen varios métodos comunes de persistencia utilizados por la persistencia de mensajes:
- Persiste en una base de datos, como Mysql.
- Persiste en almacenamiento KV, como levelDB, Berkeley DB y otros sistemas de almacenamiento KV.
- Persistencia en forma de registros de archivos, como Kafka, RocketMQ
- Crea una imagen persistente de los datos de memoria, como beanstalkd, VisiNotify
- (1), (2) y (3) los tres métodos de persistencia tienen la capacidad de extender el búfer de la cola de memoria, y (4) son simplemente una imagen de memoria, que aún puede restaurar los datos de la memoria anterior después de que el intermediario cuelgue y reinicie.
Las especificaciones de notificación JMS y CORBA no especifican explícitamente cómo persistir, pero el rendimiento de la parte de persistencia determina directamente el rendimiento de todo el middleware del mensaje.
RocketMQ aprovecha al máximo la caché de memoria del sistema de archivos Linux para mejorar el rendimiento.
Existen varias situaciones en las que la Fiabilidad de los Mensajes afecta a la fiabilidad del mensaje:
- El bróker cierra normalmente
- Colapso del corredor
- Bloqueo del sistema operativo
- La máquina pierde energía, pero la fuente de alimentación puede restablecerse inmediatamente.
- La máquina no arranca (puede estar dañada en dispositivos clave como CPU, placa base, memoria, etc.)
- Daño en el dispositivo de disco.
(1), (2), (3) y (4) son todas situaciones en las que los recursos de hardware pueden recuperarse inmediatamente, y RocketMQ puede asegurarse de que no se pierdan mensajes o que se pierda una pequeña cantidad de datos (dependiendo de si el método de flasheo es síncrono o asíncrono).
(5) (6) Es un único punto de fallo y no puede recuperarse; una vez ocurrido, todos los mensajes en ese punto único se pierden. En ambos casos, RocketMQ garantiza que el 99% de los mensajes no se pierdan por replicación asincrónica, pero aún así hay muy pocos mensajes que puedan perderse. La tecnología de escritura dual síncrona puede evitar completamente puntos individuales, lo que inevitablemente afectará al rendimiento, haciéndola adecuada para situaciones con requisitos extremadamente altos de fiabilidad de mensajes, como aplicaciones relacionadas con el dinero.
RocketMQ soporta escritura dual síncrona a partir de la versión 3.0.
La mensajería de baja latencia puede llegar al consumidor inmediatamente después de que el mensaje llegue al broker sin acumulación de mensajes.
RocketMQ utiliza un método de consulta larga para asegurar que el mensaje sea muy en tiempo real, y que el mensaje en tiempo real no sea inferior al de push.
Al menos una vez significa que cada mensaje debe entregarse una vez.
RocketMQ Consumer primero atrae el mensaje al área local y luego devuelve el ack al servidor una vez completado el consumo.
Exactamente solo una vez- La etapa de envío de mensajes no permite enviar mensajes duplicados.
- En la etapa de Consume Message, no se permite consumir mensajes duplicados.
Solo cuando se cumplen las dos condiciones anteriores se puede considerar el mensaje "Exactamente Solo una vez", y para lograr los dos puntos anteriores, inevitablemente se generará una sobrecarga enorme en el entorno del sistema distribuido. Por lo tanto, para alcanzar un alto rendimiento, RocketMQ no garantiza esta característica y requiere deduplicación en el negocio, lo que significa que los mensajes de los consumidores deben ser idempotentes. Aunque RocketMQ no puede garantizar estrictamente la no duplicación, en circunstancias normales rara vez se repiten el envío y el consumo, solo anomalías de red, inicio y paro del consumidor y otras situaciones anormales como la duplicación de mensajes.
La razón esencial de este problema es que existe incertidumbre en las llamadas de red, es decir, el tercer estado de no éxito ni fracaso, por lo que surge el problema de la repetición de mensajes.
¿Qué debo hacer si el Buffer del Corredor está lleno? El buffer del broker suele referirse al tamaño del buffer de memoria de una cola en el broker, que suele estar limitado en tamaño; ¿qué pasa si el buffer está lleno?
Así es como se gestiona en la especificación de notificación CORBA:
- RejectNewEvents rechaza el nuevo mensaje y devuelve el código de error RejectNewEvents al Productor.
- Descartar mensajes existentes según una política específica
- AnyOrder - Cualquier evento puede descartarse en el exceso de desbordamiento. Esta es la configuración predeterminada para esta propiedad.
- FifoOrder - El primer evento recibido será el primero descartado.
- LifoOrder - El último evento recibido será el primero descartado.
- Orden de prioridad - Los eventos deben descartarse en orden de prioridad, de modo que los eventos de menor prioridad se descarten antes que los de mayor prioridad.
- Fecha límite de orden - Los eventos deben descartarse primero en el orden de la fecha límite de caducidad más corta.
RocketMQ no tiene el concepto de búfer de memoria, y las colas de RocketMQ son discos persistentes, y los datos se borran regularmente.
Para la solución a este problema, RocketMQ tiene una diferencia muy significativa respecto a otros MQs: el búfer de memoria de RocketMQ se abstrae en una cola de longitud infinita, no importa cuántos datos lleguen, puede instalarse, este infinito se basa en una premisa, el broker borrará regularmente datos caducados, por ejemplo, el broker solo guarda 3 días de mensajes, y aunque la longitud de este buffer es infinita, los datos de hace 3 días se eliminarán al final de la cola.
El consumo retrospectivo se refiere al mensaje de que el consumidor ha consumido con éxito, y que el mensaje debe ser re-consumido debido a la demanda empresarial. Por ejemplo, debido a la falla del sistema de consumo, los datos de hace 1 hora deben reconsumirse tras la recuperación, y entonces el corredor debería proporcionar un mecanismo para revertir el progreso del consumo según la dimensión temporal.
RocketMQ soporta consumo retrospectivo basado en el tiempo, con una dimensión temporal precisa a milisegundos, que puede retroceder hacia adelante o hacia atrás.
La función principal del middleware de apilamiento de mensajes es el desacoplamiento asíncrono, y otra función importante es bloquear el pico de inundación de datos en el front-end y asegurar la estabilidad del sistema back-end, que requiere que el middleware de mensajes tenga cierta capacidad de apilamiento de mensajes, y el heap de mensajes integra las siguientes dos situaciones:
- Los mensajes se acumulan en búferes de memoria y, una vez que superan el búfer de memoria, los mensajes pueden descartarse según una determinada política de caída, tal como se describe en la especificación de notificación CORBA. Es adecuado para servicios que toleran descartar mensajes; en este caso, la capacidad de acumulación de mensajes reside principalmente en el tamaño del búfer de memoria, y la degradación del rendimiento no será demasiado grande una vez apilado el mensaje, ya que la cantidad de datos en memoria tiene un impacto limitado en la capacidad de acceso proporcionada al mundo exterior.
- Los mensajes se acumulan en sistemas de almacenamiento persistentes como DB, almacenamiento KV o formulario de registro de archivos. Cuando los mensajes no pueden ser alcanzados en la caché de memoria, es inevitable acceder al disco, lo que generará una gran cantidad de E/S de lectura, y el rendimiento de la E/S de lectura determina directamente la capacidad de acceso de los mensajes una vez acumulados.
Hay cuatro puntos principales para evaluar la capacidad de acumulación de mensajes:
- ¿Cuántos mensajes se pueden acumular, cuántos bytes? Es decir, la capacidad de heap del mensaje.
- Después de que un mensaje se acumula, ¿se ve afectado el rendimiento del mensaje por el apilamiento?
- ¿Se verá afectado el consumo normal de los consumidores después de que el mensaje se acumule?
- Después de que los mensajes se acumulan, ¿cuál es el rendimiento al acceder a los mensajes acumulados en el disco?
Transacciones distribuidas Varias especificaciones conocidas de transacciones distribuidas, como XA, JTA, etc. Entre ellas, la especificación XA está ampliamente soportada por los principales proveedores de bases de datos, como Oracle, Mysql, etc. Entre ellos, el líder de implementación de MT de XA, como Oracle Tuxedo, es ampliamente utilizado en finanzas, telecomunicaciones y otros campos.
Las transacciones distribuidas implican problemas de compromiso en dos etapas y, en términos de almacenamiento de datos, debe soportarse el almacenamiento KV, porque la segunda etapa de la reversión de compromiso debe modificar el estado del mensaje, lo que debe implicar la acción de encontrar el mensaje según la clave. RocketMQ evita el problema de encontrar el mensaje según la clave en la segunda etapa, usando la primera etapa para enviar el mensaje preparado, obteniendo el desplazamiento del mensaje, y la segunda etapa para acceder al mensaje a través del desplazamiento y modificar el estado; el desplazamiento es la dirección de los datos.
El método de implementación de transacciones de RocketMQ no se realiza mediante almacenamiento KV, sino mediante el método de offset, que tiene un defecto significativo: cambiar datos mediante offset causará demasiadas páginas sucias en el sistema, lo que requiere especial atención.
Mensajes programados Los mensajes programados significan que los consumidores no pueden consumir mensajes inmediatamente después de enviarse al intermediario, y solo pueden consumirse en un momento específico o tras esperar a un tiempo determinado.
Si quieres soportar una precisión temporal arbitraria, a nivel de broker debes hacer ordenación de mensajes, y si hay persistencia, la ordenación inevitablemente implicará una enorme sobrecarga de rendimiento.
RocketMQ soporta mensajes de temporización, pero no soporta precisión temporal arbitraria, y soporta niveles específicos, como el cronometraje 5s, 10s, 1m, etc.
Reintento del mensaje Después de que el consumidor no consuma el mensaje, proporciona un mecanismo de reintento para que el mensaje vuelva a consumir. Los fallos en los mensajes de consumo por parte del consumidor suelen considerarse en las siguientes situaciones:
- Debido a la razón del mensaje en sí, como un fallo de deserialización, los datos del mensaje no pueden procesarse (como la recarga de la factura telefónica, el número de teléfono móvil del mensaje actual está cerrado, no se puede recargar), etc. Este error suele requerir saltarse este mensaje y consumir otros mensajes, y este mensaje fallido es un 99% fallido incluso si el consumo se vuelve a intentar inmediatamente, por lo que es mejor proporcionar un mecanismo de reintento temporizado, es decir, reintentar después de 10 segundos.
- Porque los servicios de aplicación dependientes aguas abajo no están disponibles, como que la conexión de la base de datos no esté disponible, la red externa del sistema sea inaccesible, etc. Al encontrarse con este error, incluso si se omite el mensaje fallido actual, también se consumen otros mensajes. En este caso, se recomienda aplicar 30 segundos de sueño y consumir el siguiente mensaje, lo que puede reducir la presión sobre el corredor para intentar repetir el mensaje.
Resumen de RocketMQ Vamos a ver si RocketMQ resuelve los problemas que presenta el middleware de mensajes mencionado anteriormente.
¿Qué es RocketMQ?
La figura anterior es un modelo típico de middleware de envío y recepción de mensajes; RocketMQ también está diseñado de esta manera; en resumen, RocketMQ tiene las siguientes características:
- Es un middleware de modelo de cola con mensajes de alto rendimiento, alta fiabilidad, alta disponibilidad en tiempo real y características distribuidas.
- Se pueden distribuir productores, consumidores y colas.
- El productor envía mensajes a algunas colas por turno; la colección de colas se denomina Topic, Consumer If broadcast consumption, una instancia de consumidor consume todas las colas correspondientes a este tema, y si consume el clúster, varias instancias de consumidores consumen la colección de colas correspondiente a este tema de forma equitativa.
- Se puede garantizar un orden estricto de los mensajes
- Proporciona modos de pull de mensajes enriquecidos
- Capacidades eficientes de escalado horizontal de abonados
- Mecanismo de suscripción de mensajes en tiempo real
- Cientos de millones de mensajes de capacidad de acumulación
- Menor dependencia
Estructura física de despliegue de RocketMQ
Como se muestra en la figura anterior, la estructura de despliegue de RocketMQ presenta las siguientes características:
- El Servidor de Nombres es un nodo prácticamente sin estado que puede desplegarse en clústeres sin ninguna sincronización de información entre nodos.
- El despliegue de Broker es relativamente complejo, Broker se divide en Maestro y Esclavo, un Maestro puede corresponder a varios Esclavos, pero un Esclavo solo puede corresponder a un Amo, la correspondencia entre Maestro y Esclavo se define especificando el mismo Nombre del Corredor, diferente BrokerId, BrokerId es 0 para Maestro, y non-0 significa Esclavo. Los másteres también pueden desplegarse en varios. Cada broker establece una conexión larga con todos los nodos del clúster de servidores de nombres y registra la información de los temas a todos los servidores de nombres a intervalos regulares.
- El productor establece una conexión larga con uno de los nodos del clúster del servidor de nombres (seleccionado aleatoriamente), recupera periódicamente información de enrutamiento de temas del servidor de nombres, establece una conexión larga con el maestro que proporciona el servicio de temas y envía latidos de corazón al maestro a intervalos regulares. Producer es completamente sin estado y puede desplegarse en clústeres.
- El consumidor establece una conexión larga con uno de los nodos del clúster del servidor de nombres (seleccionado aleatoriamente), recupera regularmente información de enrutamiento de temas del servidor de nombres y establece una conexión larga con el Maestro y el Esclavo que proporcionan el servicio de temas, y envía latidos al Maestro y al Esclavo a intervalos regulares. Los consumidores pueden suscribirse a mensajes tanto de Master como de Slave, y las reglas de suscripción se determinan según la configuración del Broker.
Estructura lógica de despliegue RocketMQ
Como se muestra en la figura anterior, la estructura lógica de despliegue de RocketMQ tiene dos características: productor y consumidor.
Utilizado para representar una aplicación de mensajería, un Grupo de Productores contiene múltiples instancias de Productor, que pueden ser múltiples máquinas, múltiples procesos de una máquina o múltiples objetos Productores de un proceso. Un Grupo de Productores puede enviar múltiples mensajes de Tema, y el Grupo de Productores funciona de la siguiente manera:
- Identifica un tipo de productor
- Puedes consultar si hay varias instancias de Productor en esta aplicación de mensajería a través de la herramienta O&M
- Al enviar un mensaje de transacción distribuida, si el productor se cae inesperadamente, el broker llamará activamente a cualquier máquina del grupo de productores para confirmar el estado de la transacción.
Utilizado para representar una aplicación de mensajería de consumo, un grupo de consumidores contiene múltiples instancias de consumidor, que pueden ser múltiples máquinas, múltiples procesos o múltiples objetos de consumo de un proceso. Varios consumidores en un Grupo de Consumidores consumen los mensajes de forma uniforme y, si se configura para difusión, cada instancia dentro de este Grupo consume la cantidad total de datos.
Estructura de almacenamiento de datos RocketMQ
Como se muestra en la figura anterior, RocketMQ adopta un método de almacenamiento que separa los datos de los índices. Reducir eficazmente la pérdida de recursos de archivos, de E/S y de memoria. Incluso con datos masivos como Alibaba, los escenarios de alta concurrencia pueden reducir eficazmente la latencia de extremo a extremo y contar con fuertes capacidades de escalado horizontal.
|
Publicado en 28/7/2017 20:26:52
|
|
|
|
Publicado en 29/7/2017 8:09:37