Los billetes de avión, los billetes de tren, los billetes de autobús y los negocios relacionados con hoteles de Tongcheng Yilong se han conectado a RocketMQ para reducir los picos de tráfico durante las horas pico y reducir la presión de fondo.
Al mismo tiempo, el sistema convencional se desacopla, parte del procesamiento sincrónico se cambia a procesamiento asincrónico y se procesan 150 mil millones de datos todos los días.
En el reciente encuentro Apache RocketMQ, Cha Jiang, el arquitecto de la división de boletos de Tongcheng Yilong, compartió cómo el sistema de mensajería de Tongcheng Yilong maneja 150 mil millones de procesamiento de datos por día.
A través de este artículo, aprenderá:
Uso del sistema de mensajería Tongcheng Yilong
Escenarios de aplicación del sistema de mensajería Tongcheng Yilong
Foso técnicamente escalonado
Mejoras basadas en RocketMQ
Uso del sistema de mensajería Tongcheng Yilong
El clúster de RocketMQ se divide en dos partes: Servidor de nombres y Agente. El servidor de nombres utiliza el modo principal dual, uno para el rendimiento y el otro para la seguridad. El intermediario de datos puros se divide en muchos grupos, y cada grupo se divide en maestro y esclavo.
En la actualidad, nuestros boletos de avión, boletos de tren, boletos de autobús y negocios relacionados con hoteles se han conectado a RocketMQ para reducir los picos de tráfico durante los picos de tráfico para reducir la presión de back-end.
Al mismo tiempo, el sistema convencional se desacopla, parte del procesamiento sincrónico se cambia a procesamiento asincrónico y se procesan 150 mil millones de datos todos los días.
Las razones para elegir RocketMQ son:
Fácil acceso, se introducen menos paquetes de Java
Desarrollo puro de Java, lógica de diseño clara
El rendimiento general es relativamente estable. En el caso de una gran cantidad de temas, el rendimiento se puede mantener
Escenarios de aplicación del sistema de mensajería Tongcheng Yilong
Darse de baja del sistema
Este es un escenario de aplicación en nuestro sistema de cancelación de suscripción. El usuario hace clic en el botón de cancelación de suscripción en la interfaz, el sistema llama a la interfaz de cancelación de suscripción y luego llama a la interfaz de cancelación de suscripción del proveedor para completar una función de cancelación de suscripción.
Si la interfaz del sistema del proveedor no es confiable, hará que el usuario no pueda darse de baja. Si el sistema está configurado para sincronizar la operación, hará que el usuario vuelva a hacer clic.
Por lo tanto, presentamos RocketMQ para cambiar de síncrono a asíncrono. El usuario final actual envía una solicitud de cancelación de suscripción. Una vez que el sistema de cancelación de suscripción recibe la solicitud, se registrará en la base de datos del sistema de cancelación de suscripción, lo que indica que el usuario se está cancelando la suscripción.
Al mismo tiempo, el mensaje de darse de baja se envía al sistema conectado con el proveedor a través del motor de mensajes para llamar a la interfaz del proveedor.
Si la llamada tiene éxito, se identificará la base de datos, lo que indica que la suscripción se ha cancelado correctamente. Al mismo tiempo, se agregó un script de compensación para recuperar los mensajes cancelados de la base de datos y volver a cancelar la suscripción para evitar fallas en la cancelación de la suscripción causadas por la pérdida de mensajes.
Sistema de almacén
El segundo escenario de aplicación es nuestro sistema de almacén. Este es un escenario de uso de mensajes relativamente convencional. Recopilamos algunos datos de información básica y datos detallados del hotel del proveedor, y luego los conectamos al sistema de mensajes, que se calcula mediante el sistema de distribución back-end, el sistema de precio mínimo y el sistema de inventario.
Al mismo tiempo, cuando el proveedor cambia el precio, el evento de cambio de precio también se transmitirá a nuestro sistema comercial de back-end a través del sistema de mensajes para garantizar el tiempo real y la precisión de los datos.
Sistema de suscripción para biblioteca de suministros
El sistema de suscripción de la base de datos también utiliza la aplicación de mensajes. En circunstancias normales, la sincronización de la base de datos se realiza a través de binlog para leer los datos que contiene y luego moverlos a la base de datos.
Durante el proceso de manejo, lo que más nos preocupa es el orden de los datos, por lo que, sobre la base del modo de fila de la base de datos, se ha agregado una nueva función para garantizar que el orden en cada Cola sea único.
Aunque el orden en la cola es naturalmente único, tenemos una función en uso, es decir, los mensajes con el mismo ID se colocan en la misma cola.
Por ejemplo, el mensaje de id1 en la esquina superior derecha de la figura, el campo principal de la base de datos es id1, está unificado en Queue1, y en orden.
En Queue2, dos id3s están separados por dos id2s secuenciales, pero cuando se lee el consumo real, también será secuencial, por lo que se puede utilizar el orden de múltiples colas para mejorar la concurrencia general.
Foso técnicamente escalonado
Escenario del sistema de proveedores
En la figura anterior, un MQ corresponde a dos consumidores, están en el mismo Grupo 1. Al principio, todos solo tienen el Tema 1. En este momento, el consumo es normal.
Sin embargo, si agrega un Topic2 al primer consumidor, no puede consumir o consumir de manera anormal en este momento.
Este es un problema causado por el propio mecanismo de RocketMQ, y es necesario agregar Topic2 al segundo consumidor para el consumo normal.
Escenario del sistema de transacciones de pago
El otro es un sistema de transacciones de pago. En este escenario, también hay dos aplicaciones. Todas están bajo el mismo grupo y el mismo tema. Una es consumir datos Tag1 y la otra es consumir datos Tag2.
En circunstancias normales, no debería haber ningún problema para comenzar, pero un día descubrimos que una aplicación no se puede levantar y otra aplicación solo consume datos de Tag2, pero debido al mecanismo de RocketMQ, los datos de Tag1 serán asumidos. Los datos de Tag1 serán descartados.
Esto hará que el usuario falle en el proceso de pago. Para esto, colocamos Tag2 en Group2, y los dos grupos no consumirán el mismo mensaje.
Yo personalmente sugiero que RocketMQ puede implementar un mecanismo, es decir, solo aceptar sus propios mensajes de etiqueta y no recibir etiquetas no relacionadas.
Escenarios para leer grandes cantidades de datos antiguos
En el escenario de consumo de boletos de tren, encontramos que no se han consumido 20 mil millones de datos antiguos. Cuando comience nuestro consumo, RocketMQ comenzará a leer desde el dato 0 por defecto. En este momento, la E / S del disco se eleva al 100%, lo que afecta la lectura de otros datos del consumidor, pero después de que se cargan estos datos antiguos, no tiene ningún efecto práctico. .
Por lo tanto, la forma mejorada de leer una gran cantidad de datos antiguos es:
Para nuevos grupos de consumo, el consumo es de LAST_OFFSET por defecto.
Cuando la pila de un solo tema en el Broker supera los 10 millones, el consumo está prohibido y es necesario contactar al administrador para habilitar el consumo.
El monitoreo debe estar en su lugar, y cuando la E / S del disco se dispara, se puede contactar inmediatamente al consumidor para su procesamiento.
Escena del servidor
① El error del kernel de Fuutex en CentOS 6.6 hace que los procesos del servidor de nombres y del agente se bloqueen con frecuencia y no funcionen con normalidad
Solución: actualice a 6.7
② Los dos subprocesos en el lado del servidor crearán el mismo CommitLog y lo colocarán en la Lista, lo que dará como resultado un cálculo de error de desplazamiento de mensaje, una falla de análisis de mensaje, una falla de consumo y el reinicio no resolverán el problema.
Solución: problema de seguridad de subprocesos, cambie a un solo subproceso
③Restablecer el progreso del consumo en el modo Pull hace que el servidor llene una gran cantidad de datos en el mapa, y el uso de CPU del Broker se dispara en un 100%.
Solución: la escena de la variable local del mapa no se utiliza, elimine
④Master recomienda que cuando el cliente consume en el esclavo, si los datos no se han sincronizado con el esclavo, el pullOffset se restablecerá, lo que resultará en una gran cantidad de consumo repetido.
Solución: no restablezca la compensación
⑥ No hay MagicCode para la sincronización.Cuando el grupo de seguridad escanea el puerto de sincronización, el Maestro lo analiza incorrectamente, causando algunos problemas.
Solución: agregue la verificación magicCode durante la sincronización
Mejoras basadas en RocketMQ
Cliente nuevo
Cliente .net recién agregado, desarrollado de forma nativa en base al código fuente de Java; cliente HTTP recién agregado, que implementa algunas funciones y se conecta a RocketMQ a través de Netty Server.
Nueva función de límite de flujo de mensajes
Si el código del cliente se escribe incorrectamente y se genera un bucle infinito, se generará una gran cantidad de datos duplicados. En este momento, el hilo de producción estará lleno y la cola se desbordará, lo que afectará seriamente la estabilidad de nuestro clúster MQ y afectará a otros negocios.
La figura de arriba es un diagrama modelo de limitación de corriente. Agregamos la función de limitación de corriente antes del tema. El límite de velocidad y el límite de tamaño se pueden configurar mediante la función de limitación de corriente.
El límite de velocidad lo implementa el algoritmo del depósito de tokens, es decir, cuántos tokens se colocan en el depósito por segundo y la velocidad se consume por segundo o cuántos datos se escriben en el tema. Las dos configuraciones anteriores admiten la modificación dinámica.
Seguimiento de antecedentes
También hemos creado un fondo de monitoreo para todo el proceso de enlace de los mensajes de monitoreo, que incluyen:
Seguimiento de enlace completo de mensajes, que cubre todo el ciclo de vida de la generación, el consumo y la caducidad de los mensajes
Curva de producción y consumo de noticias
Alarma anormal de producción de mensajes
Los mensajes se acumulan para alarmar, notifican qué IP es demasiado lenta para consumir
Otras funciones:
Producir y consumir mensajes en modo HTTP
Configuración de permisos de consumo de temas, el tema solo puede ser consumido por el grupo designado para evitar la suscripción desordenada en línea
Apoyar a nuevos grupos de consumidores para que consuman desde la última posición (el valor predeterminado es consumir desde la primera)
Sincronización del progreso del consumo del modo de transmisión (progreso de la pantalla del servidor)
Lo anterior es la práctica de Tongcheng Yilong en la construcción del sistema de mensajes.