Proyecto de mensajería instantánea de código abierto github 6.7k star altamente recomendado. Pruebas de confiabilidad de mensajes y rendimiento OpenIM.

Recursos del servidor: 8 núcleos de memoria de 16G, 6 discos mecánicos, de 100G cada uno, para fragmentación mongo, ancho de banda de 10MB.

Capacidad: La capacidad de usuarios supera los 654,38 millones y el número de mensajes es de 100 millones.

Evaluación del rendimiento: hay más de 654,38 millones de usuarios en línea al mismo tiempo, se envían 900 mensajes por segundo y el retraso del mensaje es de 1 segundo (del remitente al receptor).

Inicie el SDK para simular las situaciones en línea y fuera de línea de 50 usuarios y la confiabilidad del mensaje es del 100%.

Se enviaron más de 6,5438 millones de mensajes, 3 fallaron y la otra parte recibió con precisión otros mensajes e inició sesión exitosamente en la base de datos local. Para los tres mensajes fallidos, el receptor no los recibió y los mensajes del sistema eran consistentes.

OpenIM es un componente de mensajería instantánea de código abierto creado por antiguos expertos técnicos de WeChat. Open-IM incluye servidor de mensajería instantánea y SDK de cliente. Es una solución general con código fuente abierto y todo es controlable.

OpenIM puede admitir todas las plataformas, actualmente es compatible con Android, iOS, Flutter, Uni-app, react-native, JSSDK, etc.

OpenIM se puede usar para trabajo de oficina interno, hacer amigos, servicio al cliente en línea y otros proyectos, y también se puede usar en el Metaverso.

Dirección de Github:/#/

En el caso de una sola computadora, simula el proceso de envío de mensajes de los usuarios en línea. Después de que la cantidad de usuarios en línea y mensajes alcance un cierto orden de magnitud, simule la CPU, la memoria, el uso del disco y el retraso de los mensajes del sistema. Determinar la evaluación previa de los recursos del servidor después de que la base de usuarios alcance un cierto orden de magnitud. Esta prueba no es una prueba de límite. Primero, el entorno de producción estará limitado por la cantidad de usuarios y mensajes. En segundo lugar, debido al modelo de mensaje de OpenIM, el mensaje se enviará inicialmente a Kafka a través de websocket. En teoría, el rendimiento de escritura de los mensajes enviados es una combinación de los dos, pero el verdadero cuello de botella en el envío de mensajes es en realidad la lectura y escritura aleatoria de mongodb.

Recursos del servidor: 1 conjunto de Tencent Cloud Host (Hong Kong): sistema Linux Ubuntu 18.04.4, memoria 8G de 4 núcleos, disco duro mecánico único. Ancho de banda de 5Mb.

Condiciones de prueba: elimine el almacenamiento de mensajes mysql (porque mysql solo se usa para la administración del backend y no afecta los servicios de usuario en línea). Ajuste el nivel de registro a 4 o menos. Kafka tiene 2 particiones y 2 msg_transfer.

Proceso de prueba: 1 cliente (Chengdu, PC con ventana, memoria de 4 núcleos y 16 G) inicia 10.000 sesiones, simula que el usuario establece una conexión websocket larga con el servidor y el intervalo es aleatorio de 50 a 100 segundos. . Dos clientes * * * simulan 20.000 usuarios en línea al mismo tiempo, envían mensajes, observan las capacidades de procesamiento de cada módulo del flujo de mensajes, * * * cuentan 25 millones de mensajes y observan el uso de la memoria del sistema y los recursos del disco.

Estado de los datos de Mongodb

Estado de los datos de Redis

Estado del disco

Análisis de uso de recursos

(1)redis Ocupa muy poca memoria. Un dato para cada usuario (incluido el token y la secuencia) es proporcional a la cantidad de usuarios que 30.000 usuarios ocupan decenas de metros de memoria.

(2) Si elimina el caché de 2) mongodb, el consumo de memoria es muy pequeño. Cada documento almacena 5000 mensajes, lo que es proporcional a la cantidad de usuarios y la cantidad de mensajes. 30.000 usuarios y 25 millones de mensajes son sólo 950 000 (una mejor visión de cómo mongo consume memoria fuera del caché).

(3) 25 millones de mensajes ocupan 10G de espacio en disco.

(4) Hay 150 mensajes por segundo, y la CPU ocupa el 50% del total, es decir, 2 núcleos.

Análisis de rendimiento técnico

(1) El cuello de botella del rendimiento radica en las operaciones de escritura de mongodb. Hay un mensaje que debe dividirse dos veces según el remitente y el receptor, y la lectura y escritura de mongodb se pueden optimizar aún más en el futuro.

(2) Para módulos con alto consumo de CPU, se realizará una optimización general en el futuro.

(3) El rendimiento es estable y no disminuirá a medida que aumente la cantidad de datos. Los iops del disco mecánico llegan a 200, que es básicamente el límite del equipo.

Recursos del servidor: 8 núcleos, 16G de memoria, 6 discos, 100G cada uno, utilizados para fragmentación mongo, 10MB de ancho de banda.

Evaluación del rendimiento: hay más de 654,38 millones de usuarios en línea al mismo tiempo, se envían 900 mensajes por segundo y el retraso del mensaje es de 1 segundo (del remitente al receptor).

(1) La implementación del clúster Mongo admite cientos de millones de usuarios en línea al mismo tiempo y cientos de miles de millones de mensajes

(2) Implementación del clúster simplificada

Lo anterior prueba principalmente el rendimiento del servidor, pero una solución de mensajería instantánea completa no es solo el trabajo del servidor. La importancia del cliente es indudable, incluyendo cómo usar seq para sincronizar mensajes con el servidor, cómo devolver la llamada al cliente (cambios de sesión, adiciones y nuevos mensajes) mientras se garantiza el tiempo de envío y recepción de mensajes, cómo sincronizar mensajes con la base de datos local y seq. Cómo combinar la inserción y extracción de mensajes para garantizar la confiabilidad del envío y recepción de mensajes.

De hecho, la accesibilidad (confiabilidad) del mensaje es más importante que las pruebas de rendimiento. Por lo tanto, mientras realiza pruebas de rendimiento, también debe probar la accesibilidad (confiabilidad) del mensaje. Si no se puede garantizar la precisión del envío y recepción de mensajes, no importa cuán alto sea el rendimiento, será en vano. Este artículo resume principalmente la solución, el proceso y los resultados de la prueba de accesibilidad de mensajes de OpenIM. En primer lugar, la tasa de accesibilidad de los mensajes de OpenIM es del 100 %, por lo que se puede utilizar en entornos de producción con confianza. Los mecanismos de alineación y sincronización de Seq garantizan que la accesibilidad de los mensajes de OpenIM sea líder en la industria.

La confiabilidad del sistema de mensajería instantánea generalmente se refiere a la confiabilidad de la entrega del mensaje, que es el "mensaje que debe llegar" que a menudo escuchamos. Generalmente se expresa mediante dos indicadores técnicos: el mensaje no se pierde. ; repetir. Asegúrese de que el destinatario pueda recibir el mensaje después de enviarlo. Debido a la complejidad del entorno de red y la incertidumbre de los usuarios al estar en línea, la confiabilidad de los mensajes (sin pérdida, sin duplicación) es sin duda el indicador central del sistema de mensajería instantánea y una de las dificultades en la implementación del sistema de mensajería instantánea. En términos generales, la "confiabilidad" del mensaje del sistema de mensajería instantánea generalmente se refiere a la confiabilidad de la entrega de mensajes de chat (precisamente, este "mensaje" es amplio, porque hay varias instrucciones y notificaciones que los usuarios no pueden ver, incluidas, entre otras, notificaciones de unirse a un grupo, notificaciones para agregar amigos, etc., para facilitar la descripción, se denominan colectivamente "mensajes").

A partir del comportamiento del usuario del remitente y del receptor del mensaje, la "confiabilidad" del mensaje debe dividirse en las siguientes situaciones:

(1) Fallo de transmisión. En este caso, el sistema de mensajería instantánea debe ser consciente de esto y comunicarlo claramente al remitente. Si el correo electrónico no tiene éxito, el remitente puede optar por volver a intentarlo o intentarlo más tarde.

(2)Transmisión exitosa. Si el destinatario está en línea, debería recibir este mensaje inmediatamente. Si el receptor está desconectado y no puede recibir el mensaje, lo recibirá tan pronto como se conecte.

(3) Los mensajes no se pueden repetir. Expresado en términos matemáticos: "Sólo existe este mensaje". Si se repite, el posible significado cambia. En resumen, un sistema de mensajería instantánea comercial debe contener una lógica de "confiabilidad" de mensajes para que sea básicamente utilizable. Esta es la lógica más básica y central del sistema de mensajería instantánea.

El escenario real de Internet es más complicado, pero el cliente se puede dividir aproximadamente en dos situaciones: (1) Al enviar un mensaje, el receptor está en línea y puede recibir el mensaje (2) Cuándo; Al enviar un mensaje, el receptor no está en línea, pero inicia sesión para recibir mensajes sin conexión. Utilizamos programas de prueba para simular varios escenarios para clientes de Internet. Según la situación de inicio de sesión, envío y recepción de mensajes, el cliente de prueba se divide en los dos tipos siguientes:

(1) Sin conexión al iniciar la prueba, duerme aleatoriamente durante 0 a 60 segundos y luego iniciar sesión, enviar mensajes y recibir mensajes.

(2) Esté desconectado al iniciar la prueba, inicie sesión después de dormir aleatoriamente durante 0 a 60 segundos y solo reciba mensajes pero no envíe mensajes.

En la prueba real, había 50 clientes, alrededor de 25 (50% de probabilidad) clientes no enviaron sino que solo recibieron mensajes, y alrededor de 25 (50% de probabilidad) clientes enviaron y recibieron mensajes.

Método de envío: cada cliente selecciona aleatoriamente a otros clientes como destinatarios del mensaje;

Expectativas de la prueba: cada ID de mensaje enviado correctamente se puede encontrar en la lista de mensajes recibidos. De manera similar, cada MsgID recibido se puede encontrar en la lista de mensajes enviados exitosamente.

Medidas específicas: (1) Después de que el mensaje se envíe correctamente, registre el MsgID a través de la devolución de llamada OnSuccess; después de recibir el nuevo mensaje, vuelva a llamar a OnRecvNewMessage y registre el MsgID (2) Compare periódicamente los dos mensajes; listas para confirmar si son completamente consistentes;

Se enviaron 100,000 datos, 3 de los cuales fallaron, 9999997 fueron exitosos y el receptor recibió exitosamente 9999997 mensajes (el receptor recibió exitosamente el mensaje, lo escribió en el base de datos local y activó la devolución de llamada del mensaje).

La otra parte puede recibir con precisión cada mensaje enviado correctamente, independientemente de si el estado de inicio de sesión del destinatario está en línea o fuera de línea cuando se envía el mensaje.

Todo mensaje que no se envíe no será recibido por la otra parte.

Notas:

(1) Controle la presión, debido a que el SDK necesita escribir en la base de datos local, el cliente se convertirá en un cuello de botella de presión.

(2) Los registros del cliente de pruebas de estrés afectarán el rendimiento de la prueba.

Esta tabla es el precio de una plataforma de mensajería instantánea en la nube. Si se calcula en base a una actividad mensual de 6,5438 millones y al almacenamiento de mensajes durante tres años, deberá pagar 6,5438 millones por año. Para utilizar OpenIM, sólo necesita comprar un host en la nube, que cuesta alrededor de 800.000 al año.