Parte del contenido y las imágenes del artículo "Hablar de la inmediatez y confiabilidad del sistema de mensajería instantánea" fue citado cuando se escribió este artículo, gracias al autor original.
1. Introducción
Artículo anterior " Introducción al desarrollo de MI de base cero (2): ¿Cuál es la naturaleza en tiempo real del sistema de MI? 》 Habló sobre la "huella" del sistema de mensajería instantánea, la característica técnica del "tiempo real". Este artículo explica principalmente el tema de la "confiabilidad" en el sistema de mensajería instantánea. Discusión técnica en diferentes niveles para asegurar que sea fácil de entender.
Objetivo de lectura: esta serie de artículos se lee principalmente para desarrolladores o gerentes de producto con una base de mensajería instantánea cero. El objetivo es decirle "¿Qué es el sistema de mensajería instantánea?", Trate de no discutir la implementación técnica específica en profundidad, para asegurarse de que es fácil de entender y apto para todas las edades.
Si desea aprender la tecnología de mensajería instantánea del sistema de dimensión técnica y comenzar su propio desarrollo de mensajería instantánea (es decir, para resolver la pregunta "¿Cómo hacer el sistema de mensajería instantánea?"), Comience con este artículo: "Una introducción para principiantes es suficiente: Desarrolle la mensajería instantánea móvil desde cero ".
intercambio de estudios:
-5 grupos para el desarrollo e intercambio de tecnología push / mensajería instantánea: 215477170 [recomendado]
-Introducción al desarrollo de mensajería instantánea móvil: "Una entrada es suficiente para los principiantes: desarrolle mensajería instantánea móvil desde cero "
-Código fuente del marco de mensajería instantánea de código abierto: https://github.com/JackJiang2011/MobileIMSDK
(Este artículo se publicó simultáneamente en: http://www.52im.net/thread-3182-1-1.html )
2. Serie de artículos
" Introducción al desarrollo de MI de base cero (1): ¿Qué es un sistema de MI? 》
" Introducción al desarrollo de MI de base cero (3): ¿Cuál es la confiabilidad del sistema de MI? "(* Este artículo)
"Introducción al desarrollo de MI de base cero (5): ¿Cuál es la seguridad del sistema de MI? (Se publicará más tarde)》
"Introducción al desarrollo de MI de base cero (6): ¿Cuál es el mecanismo de latido del sistema de MI? (Se publicará más tarde)》
"Introducción al desarrollo de mensajería instantánea de base cero (7): ¿Cómo comprender y realizar el mensaje del sistema de mensajería instantánea no leído? (Se publicará más tarde)》
"Introducción al desarrollo de IM de base cero (8): ¿Cómo comprender y realizar la itinerancia de mensajes multiterminal del sistema de IM? (Se publicará más tarde)》
3. Resumen del texto principal
En términos generales, el mensaje "confiabilidad" del sistema de mensajería instantánea generalmente se refiere a la confiabilidad de la entrega de mensajes de chat (para ser precisos, este "mensaje" es en un sentido amplio, porque todavía hay varias instrucciones que los usuarios no pueden ver . "noticias").
En términos de comportamiento del usuario, la "confiabilidad" del mensaje debe dividirse en dos tipos:
- 1) Fiabilidad de los mensajes en línea: es decir, cuando se envía el mensaje, el destinatario se encuentra actualmente en el estado "en línea";
- 2) Fiabilidad de los mensajes fuera de línea: es decir, al enviar un mensaje, el destinatario se encuentra actualmente en un estado "fuera de línea".
En términos de desempeño técnico específico, el mensaje "confiabilidad" tiene dos significados:
- 1) La noticia no se pierde: esto es muy sencillo, la noticia enviada no puede ser como un agujero negro, no es bueno estar aturdido;
- 2) El mensaje no es pesado: esto es lo contrario a perder un mensaje, y el mensaje se repite y no se puede tolerar.
En cuanto a la característica de "no perder mensajes", en detalle, tiene dos significados:
- 1) Ha sido recibido claramente por la otra parte;
- 2) Claramente no ha sido recibido por la otra parte.
Sí, es fácil entender el primer) significado pesado, y el segundo) significado pesado significa: cuando la otra parte no lo recibe con éxito, su sistema im también debe percibirlo, de lo contrario, también pertenece a la categoría de ser " perdió".
En resumen, un sistema im formado debe contener la lógica de "confiabilidad" de estos dos mensajes para ser utilizable e indispensable.
La confiabilidad del mensaje (no se pierde, no se repite) es sin duda un indicador importante del sistema de MI, y también es una de las dificultades en la implementación del sistema de MI. El siguiente texto de este artículo discutirá la confiabilidad de los mensajes en línea y los mensajes fuera de línea.
4. Proceso típico de mensajería en línea
Primero observe el siguiente proceso típico de envío y recepción de mensajes im:
Sí, esta es una transformación típica del lado del servidor de la arquitectura de mensajería instantánea.
La llamada "transformación de la arquitectura de mensajería instantánea en el servidor" se refiere a: después de que se envía un mensaje desde el cliente A, es necesario transferirlo a través del servidor de mensajería instantánea y luego enviarlo por el servidor de mensajería instantánea al cliente B. la mensajería instantánea más común en la actualidad La arquitectura de distribución de mensajes del sistema.
¿Podría decirse que la mensajería instantánea no puede estar en modo P2P? Sí, en la actualidad, la mensajería instantánea convencional es básicamente el método de transferencia del servidor, y el modo P2P rara vez se usa en el sistema de mensajería instantánea.
La razón son los siguientes dos inconvenientes obvios:
- 1) En el modo P2P, los operadores de mensajería instantánea son fácilmente superados por los usuarios (el comportamiento del usuario no puede ser monitoreado. ¿Tienen los usuarios miedo de involucrarse en pornografía?);
- 2) En el modo P2P, la forma comercial del chat grupal es difícil de lograr (quiero enviar mensajes a miles de personas, me es imposible distribuirlo 1000 veces por mí mismo).
El tema está un poco fuera de lugar, volvamos al tema: en la imagen de arriba, el cliente A envía un mensaje al servidor y el servidor transmite el mensaje al cliente B. Suponiendo que el protocolo de comunicación utilizado en los dos datos enlaces es TCP, cree usted. Con el soporte del llamado protocolo de transmisión confiable de TCP, ¿puede realmente garantizar la confiabilidad de los mensajes de chat de mensajería instantánea?
la respuesta es negativa. Seguimos mirando la siguiente sección.
5. TCP no garantiza la "confiabilidad" de los mensajes en línea.
Continuando con la sección anterior, en una transformación típica del lado del servidor de la arquitectura de mensajería instantánea, incluso si se utiliza el "protocolo de transmisión confiable" TCP, no se puede garantizar la confiabilidad de los mensajes de chat. ¿Por qué dices eso?
Para responder a esta pregunta, muchos artículos en Internet darán ejemplos desde la perspectiva del servidor: por ejemplo, fallas del sistema operativo, flashes de red, fallas de almacenamiento, etc. al enviar mensajes. En resumen, son muy abstractos y no fáciles de comprender.
Esta vez entendemos, desde la perspectiva del cliente, por qué los mensajes de chat de IM aún no son confiables cuando se utiliza el protocolo de transmisión confiable TCP.
Específicamente: Cómo garantizar la confiabilidad de los mensajes de mensajería instantánea es un tema relativamente complicado. El envío de datos del cliente al servidor, y luego del servidor al cliente de destino, finalmente se muestra correctamente en la interfaz de usuario. Hay muchos vínculos involucrados y solo uno de ellos será seleccionado aquí. Hablemos de las dos ideas de diseño con las que he entrado en contacto en el primer capítulo "¿Cómo se asegura el extremo receptor de que el mensaje no se pierda?".
Hablando de entrega confiable: la primera reacción será la confiabilidad de TCP. La entrega confiable de datos es un problema universal. Ya sean datos de flujo binario de red o datos comerciales de capa superior, existen problemas de garantía de confiabilidad. Como protocolo de infraestructura de red, la confiabilidad de su diseño de confiabilidad es incuestionable. Comencemos con la confiabilidad de TCP.
En la capa TCP: todos los datos enviados por el remitente tienen un número de secuencia para cada byte. Después de que cada byte llega al extremo receptor, el extremo receptor devolverá un mensaje de reconocimiento (número de reconocimiento). La relación entre los dos es Ack = Seq + 1. En pocas palabras, si el remitente envía un paquete con Seq = 1 y una longitud de 100 bytes, el receptor devolverá un paquete con Ack = 101. Si el remitente recibe este paquete Ack, significa que los datos se han recibido. por el Receptor, de lo contrario, el Remitente tomará Alguna estrategia reenvía el paquete anterior.
La primera pregunta es: dado que TCP en sí mismo es confiable, ¿por qué el receptor de mensajes (Receptor) pierde mensajes?
Mire la imagen a continuación para una vista clara:
(▲ La imagen de arriba se cita de " Hablando sobre la confiabilidad del mensaje y el mecanismo de entrega de la mensajería instantánea móvil desde la perspectiva del cliente ")
Una oración resume el significado de la figura anterior: la confiabilidad de la capa de red no es lo mismo que la confiabilidad de la capa empresarial.
Una vez que los datos llegan a la capa de red de manera confiable, deben entregarse y procesarse capa por capa. El procesamiento posible es el siguiente:
- 1) Verificación de seguridad;
- 2) Análisis binario;
- 3) Creación de modelos;
- 4) Escriba db;
- 5) Almacenar en la caché;
- 6) exhibición de UI;
- 7) Y algunos problemas de límites: como desconexión de la red, cierre de sesión repentino del usuario, disco lleno, desbordamiento de memoria, bloqueo de la aplicación, apagado repentino, etc.
Cuantas más características funcionales tenga el proyecto, mayor será la posibilidad de errores en el procesamiento desde la capa de red hacia arriba.
Tome el escenario más simple como ejemplo: después de que el mensaje llega de manera confiable a la capa de red, la aplicación de mensajería instantánea se bloquea antes de escribir en la base de datos (no es sorprendente que la aplicación se bloquee). Aunque los datos llegan de manera confiable a la capa de red, no se almacena en la base de datos. La próxima vez que el usuario abra la aplicación, el mensaje se perderá naturalmente. Si no aumenta la garantía de confiabilidad en la capa empresarial (por ejemplo, la garantía de retransmisión de mensajes a nivel de red que se menciona más adelante) , significa que este mensaje será para siempre para el receptor. Si se pierde, naturalmente no hay "confiabilidad".
Para comprender las posibilidades y soluciones de la mensajería instantánea desde la perspectiva del cliente, se puede leer en detalle: " Hablando de la confiabilidad de los mensajes y el mecanismo de entrega de la mensajería instantánea móvil desde la perspectiva del cliente ", este apartado remite al artículo " 4. Protocolo TCP Además de la confiabilidad, habrá pérdida de mensajes? ”Sección del texto.
6. Agregue una garantía de "confiabilidad" para los mensajes en línea.
Entonces, ¿cómo aumentar la garantía de confiabilidad en la capa de aplicación?
Hay un mecanismo listo para usar del que podemos aprender: el mecanismo de tiempo de espera, retransmisión y confirmación del protocolo TCP.
Específicamente:
- 1) Construya un mensaje ACK en la capa de aplicación y envíe un ACK al remitente después de que el receptor procese el mensaje correctamente;
- 2) Si el remitente no recibe un ACK dentro del período de tiempo de espera, se considera que el mensaje no se ha enviado y se requiere retransmisión u otro procesamiento.
El proceso de envío y recepción de mensajes con el mecanismo de confirmación agregado es el siguiente:
Podemos dividir todo el proceso en dos etapas.
Fase 1: clienteA -> servidor
- 1-1: clientA envía un mensaje (msg-Req) al servidor;
- 1-2: El servidor recibe el mensaje y responde ACK (msg-Ack) al clientA;
- 1-3: Una vez que el clienteA recibe el ACK, se considera que el mensaje se ha entregado con éxito y finaliza la primera fase.
No importa si se pierde msg-A o ack-A, el cliente A no puede recibir el ACK dentro del período de tiempo de espera. En este momento, se puede notificar al usuario que la transmisión falló y la retransmisión se puede realizar manualmente.
Fase 2: servidor -> clienteB
- 2-1: El servidor envía un mensaje (Notify-Req) a clientB;
- 2-2: clientB recibe el mensaje y responde ACK (Notify-ACk) al servidor;
- 2-3: Una vez que el servidor recibe el ACK, el mensaje se marca como enviado y finaliza la segunda fase.
No importa si se pierde msg-B o ack-B, el servidor no puede recibir ACK dentro del período de tiempo de espera. En este momento, msg-B necesita ser retransmitido hasta que clientB devuelva ACK.
Para una discusión en profundidad sobre la garantía de confiabilidad de los mensajes de chat de MI, puede leer: " Implementación del mecanismo de garantía de entrega de mensajes de MI (1): Garantizar la entrega confiable de mensajes en línea en tiempo real ", este artículo discutirá este tema en profundidad.
7. Proceso típico de mensajería fuera de línea
Después de hablar sobre la "confiabilidad" de los mensajes en línea, es hora de aprender sobre los mensajes fuera de línea.
7.1 También existe "falta de fiabilidad" en el envío y recepción de mensajes fuera de línea
La siguiente figura es un diagrama de flujo de mensajes de mensajería instantánea fuera de línea típico:
Como se muestra en la figura anterior, es similar al proceso de mensajería en línea.
El proceso de mensajería fuera de línea también se puede dividir en dos etapas:
Fase 1: clienteA -> servidor
- 1-1: clientA envía un mensaje (msg-Req) al servidor;
- 1-2: El servidor encuentra que clientB está fuera de línea y almacena el mensaje en la base de datos fuera de línea.
Fase 2: servidor -> clienteB
- 2-1: Después de que clientB se conecte, extraiga los mensajes fuera de línea (pull-Req) del servidor;
- 2-2: El servidor recupera el mensaje sin conexión correspondiente de la base de datos sin conexión, lo envía a clientB (pull-res) y lo elimina de la base de datos sin conexión.
Obviamente: también existe la posibilidad de pérdida de mensajes durante la mensajería fuera de línea.
Por ejemplo: supongamos que el pull-res no se entrega correctamente al cliente B, pero la base de datos fuera de línea se ha eliminado, esta parte del mensaje fuera de línea se pierde por completo.
7.2 Garantía de "confiabilidad" de los mensajes fuera de línea
De manera similar al proceso de mensajería en línea, también necesitamos agregar un mecanismo de garantía de confiabilidad en la capa de aplicación.
La siguiente figura muestra el proceso de envío y recepción de mensajes fuera de línea después de que se ha agregado la garantía de confiabilidad:
En comparación con el proceso inicial de envío y recepción de mensajes fuera de línea, la figura anterior ha agregado los pasos 1-3, 2-4 y 2-5:
- 1-3: Después de que el servidor guarda el mensaje en la base de datos fuera de línea, responde con un ACK (msg-Ack) a clientA, y clientA recibe el ACK y considera que el mensaje se entregó correctamente;
- 2-4: clientB recibe el mensaje fuera de línea enviado y responde ACK (res-Ack) al servidor;
- 2-5: Después de recibir el res-ACk, el servidor determina que el mensaje fuera de línea ha sido recibido con éxito por el cliente B, y luego se puede eliminar de la base de datos fuera de línea.
Por supuesto, todavía hay espacio para la optimización del rendimiento en el mecanismo de garantía antes mencionado.
Cuando la cantidad de mensajes fuera de línea es grande: Si responde ACK a cada mensaje, sin duda aumentará en gran medida la cantidad de comunicaciones entre el cliente y el servidor. En este caso, usualmente usamos ACK por lotes, y solo se devuelve un ACK a varios mensajes. En la implementación posterior de IM, todos los mensajes fuera de línea se agrupan por sesión y cada grupo responde con un ACK. Si se pierde un ACK, solo se deben retransmitir todos los mensajes fuera de línea de la sesión.
Para una discusión detallada sobre el mecanismo de garantía de confiabilidad de los mensajes fuera de línea, puede leer: " Implementación del mecanismo de garantía de entrega de mensajes de mensajería instantánea (2): Garantizar la entrega confiable de mensajes fuera de línea ", " Desarrollo de mensajería instantánea y uso compartido de productos secos: cómo realizar con elegancia una gran cantidad de mensajes fuera de línea de entrega confiable ", estos dos artículos pueden brindarle respuestas más detalladas y específicas.
8. El problema de los mensajes de chat repetidos
En la sección anterior, después de agregar un mecanismo de retransmisión y confirmación en la capa de aplicación, hemos eliminado la posibilidad de pérdida de mensajes.
Pero debido a la existencia del mecanismo de reintento, nos encontraremos con un nuevo problema: es decir, el mismo mensaje puede enviarse repetidamente.
Tome el ejemplo más simple: suponga que el cliente recibe con éxito el mensaje enviado por el servidor, pero el ACK posterior enviado por él se pierde, entonces el servidor enviará el mensaje nuevamente después del tiempo de espera. Si la capa empresarial no procesa el mensaje duplicado, entonces el usuario verá dos mensajes idénticos.
El método de deduplicación de mensajes es realmente muy simple, generalmente se filtra en función del identificador único (id) del mensaje.
El proceso específico puede ser diferente entre el servidor y el cliente:
- 1) Cliente: Podemos mantener la identificación del mensaje recibido construyendo un mapa y descartarlo directamente cuando recibimos un mensaje con una identificación duplicada;
- 2) Servidor: cuando reciba un mensaje, consulte la base de datos de acuerdo con la identificación. Si la base de datos ya existe, no se procesará, pero aún necesita responder Ack al cliente (porque es probable que este mensaje provenga del usuario retransmisión manual).
Con respecto al tema de la deduplicación de mensajes, en el caso del chat uno a uno, la lógica no es complicada, pero en el modo de chat grupal, el problema será complicado. Para una discusión detallada sobre la no pérdida y la deduplicación de los mensajes de chat grupal, puede leer en profundidad: "El mensaje de chat grupal IM es tan complicado, ¿cómo asegurarse de que no se pierda ni se repita? ".
9. Resumen de este artículo
Asegurar la confiabilidad de los mensajes es una parte muy importante del diseño del sistema de mensajería instantánea. El hecho de que el mensaje "no se pierda" o "no sea pesado" tiene un gran impacto en la experiencia del usuario.
El llamado "protocolo de transporte confiable" TCP tampoco puede garantizar la confiabilidad de los mensajes en la capa de aplicación.
Generalmente implementamos la garantía de confiabilidad de los mensajes IM a través del mecanismo de retransmisión y respuesta ACK en la capa de aplicación. Sin embargo, el problema de la duplicación de mensajes causado por esto requiere un procesamiento adicional El método más simple es realizar una deduplicación idempotente a través del ID del mensaje.
Con respecto a la base teórica de la confiabilidad de los mensajes del sistema de mensajería instantánea, la hemos discutido aquí. Los lectores que tengan preguntas pueden prestarle atención al final de este artículo. Las discusiones activas son bienvenidas.
10. Materiales de referencia
[5] Hablar sobre la inmediatez y confiabilidad del sistema de mensajería instantánea.
[7] El mensaje de chat grupal de IM es tan complicado, ¿cómo asegurarse de que no se pierda ni se repita?
Apéndice: Puntos tecnológicos más populares para el desarrollo de mensajería instantánea
" Problemas técnicos que deben afrontarse en el desarrollo de mensajería instantánea móvil "
" ¿Alguien conoce la implementación generalizada del chat de mensajes de voz? 》
" ¿Cómo garantizar la" secuencia "y la" coherencia "de los mensajes instantáneos en tiempo real? 》
" Un método de bajo costo para garantizar la sincronización de los mensajes de mensajería instantánea "
" Prueba técnica y análisis de la influencia de WeChat en la red (artículo completo) "
Este artículo ha sido publicado simultáneamente en la cuenta oficial de "Instant Messaging Technology Circle".
▲ El enlace a este artículo en la cuenta oficial es: haga clic aquí para ingresar , el enlace original es: http://www.52im.net/thread-3182-1-1.html