Was sind die Situationen des Nachrichtenverlusts?
Nehmen wir als Beispiel das gebräuchlichste IM-System vom Typ "Server-Side-Routing-Relay" (nicht P2P). Hier eine Erklärung. Das sogenannte "Server-Side-Routing-Relay" bedeutet, dass eine Nachricht, die von Benutzer A gesendet wurde, zuerst den IM-Server passieren muss Übertragen und dann vom IM-Server an Benutzer B senden. Dies ist derzeit auch die häufigste Art der Nachrichtenverteilung in IM-Systemen.
Nehmen wir also ein Szenario an: Benutzer A sendet eine Nachricht an Benutzer B. Schauen wir uns als nächstes an, bei welchen Links die Gefahr besteht, dass Nachrichten verloren gehen.
Unter Bezugnahme auf das obige Sequenzdiagramm ist die Nachricht grob in zwei Teile als Ganzes unterteilt:
1. Benutzer A sendet eine Nachricht an den IM-Server, der Server speichert die Nachricht vorübergehend und gibt dann ein erfolgreiches Ergebnis an den Absender A zurück (Schritte 1, 2, 3).
2. Der IM-Server sendet dann die vorübergehend gespeicherte Nachricht, die von Benutzer A an den Empfängerbenutzer B gesendet wurde (Schritt 4).
Die Szenarien, in denen Nachrichten verloren gehen können, sind wie folgt. Im ersten Teil. Die Schritte 1, 2 und 3 können alle fehlschlagen.
1. Da die Nachricht von Benutzer A ein Prozess von "Anforderung" und "Antwort" ist, kann Benutzer A die Nachricht aufgrund einer Netzwerkunterbrechung und aus anderen Gründen nicht an den IM-Server senden.
2. Oder der IM-Server konnte die Nachricht beim Empfang der Nachricht nicht speichern.
3. Oder Benutzer A wartet eine bestimmte Zeitspanne auf den IM-Server, aber der IM-Server hat kein Ergebnis zurückgegeben. In diesen Fällen wird Benutzer A aufgefordert, das Senden fehlgeschlagen zu machen.
Hinweis:
1. Im ersten Teil. Die Schritte 1, 2 und 3 können alle fehlschlagen. Da Benutzer A, der eine Nachricht sendet, ein Prozess von "Anforderung" und "Antwort" ist, kann Benutzer A die Nachricht aufgrund einer Netzwerkunterbrechung oder aus anderen Gründen nicht an den IM-Server senden oder der IM-Server empfängt die Nachricht für die serverseitige Speicherung Fehlgeschlagen oder Benutzer A wartet für eine bestimmte Zeitspanne auf den IM-Server, aber der IM-Server hat kein Ergebnis zurückgegeben. In diesen Fällen wird Benutzer A aufgefordert, das Senden fehlgeschlagen zu machen. Als nächstes kann er dies durch einen erneuten Versuch usw. ausgleichen. Beachten Sie, dass dies zu dem Problem führen kann, dass doppelte Nachrichten gesendet werden. Beispiel: Der Client erhält innerhalb des Zeitlimits keine Antwort und versucht es erneut. Tatsächlich wurde die Anforderung möglicherweise erfolgreich auf dem Server verarbeitet, die Antwort ist jedoch langsam. Daher muss der Server in diesem Fall über eine Deduplizierungslogik verfügen, im Allgemeinen über den Absender Es gibt eine eindeutige ID für dieselbe Wiederholungsnachricht, die der Server bequem wiederverwenden kann.
2. Im zweiten Teil . Nachdem die Nachricht auf dem IM-Server gespeichert wurde, antworten Sie Benutzer A, um zu informieren, dass die Nachricht erfolgreich gesendet wurde. Anschließend sendet der IM-Server die Nachricht an das Online-Gerät von Benutzer B. Wenn der Server während der Push-Vorbereitungsphase oder nach dem Schreiben der Nachricht in den Kernel-Puffer die Stromversorgung verliert, wird die Nachricht nicht erfolgreich an Benutzer B gesendet. In diesem Fall funktioniert der verbundene IM-Server möglicherweise nicht mehr normal, und spätere Abhilfemaßnahmen sind erforderlich, um das Problem des Nachrichtenverlusts zu lösen. Selbst wenn unsere Nachricht über TCP erfolgreich mit dem Gerät von Benutzer B verbunden wurde, geht die Nachricht verloren, wenn das Gerät von Benutzer B nach dem Empfang ein Problem mit der Verarbeitung hat. Wenn beispielsweise das Gerät von Benutzer B eine Nachricht in die lokale Datenbank schreibt, tritt eine Ausnahme auf und diese kann nicht erfolgreich gespeichert werden. In diesem Fall kann Benutzer B die Nachricht nicht sehen, da die Netzwerkebene tatsächlich erfolgreich zugestellt wurde. Es ist also schwieriger damit umzugehen.
Im Allgemeinen werden wir die folgenden entsprechenden Lösungen verwenden:
1. Im ersten Teil können wir das Problem grundsätzlich durch die Timeout-Neuübertragung von Client A und den Deduplizierungsmechanismus des IM-Servers lösen.
2. Im zweiten Teil bezieht sich die Industrie im Allgemeinen auf den ACK-Mechanismus des TCP-Protokolls, um einen Satz von ACK-Protokollen für die Geschäftsschicht zu implementieren.
Lösung für Verluste: Business-Layer-ACK-Mechanismus
Lassen Sie uns zuerst ACK erklären. Der vollständige Name von ACK lautet Acknowledge, was Bestätigung bedeutet. Im TCP-Protokoll wird standardmäßig der ACK-Mechanismus bereitgestellt. Ein mit dem Protokoll geliefertes Standard-ACK-Paket wird verwendet, um die von der Kommunikationspartei empfangenen Daten zu bestätigen und den Kommunikationssender darüber zu informieren, dass er bestätigt hat, dass er die Daten erfolgreich empfangen hat. Dann ist der ACK-Mechanismus der Geschäftsschicht ähnlich, und die Lösung lautet: Bestätigen, ob die Nachricht erfolgreich an den Empfänger übermittelt wurde, nachdem der IM-Dienst übertragen wurde. Die konkrete Realisierung lautet wie folgt:
Wenn der IM-Server die Nachricht weiterleitet, trägt er eine Identifikations-SID (Sicherheitskennung, ähnlich der Sequenz-ID von TCP). Nachdem die Nachricht herausgeschickt wurde, wird die aktuelle Nachricht zur "Nachricht, die ACK-Liste sein soll" hinzugefügt. Nachdem der Client B die Nachricht erfolgreich empfangen hat, wird sie gegeben Der IM-Server gibt ein Business-Layer-ACK-Paket zurück, das die SID der empfangenen Nachricht enthält. Nach dem Empfang der Nachricht löscht der IM-Server diese Nachricht aus dem Datensatz "ACK-Nachrichtenliste", und dieser Push ist wirklich beendet.
1. Neuübertragung von Nachrichten im ACK-Mechanismus
Was passiert, wenn die Nachricht beim Weiterleiten an Benutzer B verloren geht? Beispiel: Netzwerk B ist tatsächlich nicht erreichbar, aber der IM-Server hat es noch nicht erkannt. Das Gerät von Benutzer B ist abgestürzt, bevor es Daten aus dem Kernel-Puffer abgerufen hat. Die Nachricht wurde von einem Zwischengerät auf dem Weg zum Zwischennetzwerk gelöscht, und die TCP-Schicht ist noch vorhanden Die erneute Übertragung war nicht erfolgreich und so weiter. Die oben genannten Probleme führen dazu, dass Benutzer B keine Nachrichten empfängt.
Lösung: Die gängige Strategie zur Lösung dieses Problems bezieht sich tatsächlich auf den Neuübertragungsmechanismus des TCP-Protokolls. In ähnlicher Weise verwaltet die "wartende ACK-Warteschlange" des IM-Servers im Allgemeinen einen Zeitüberschreitungszeitgeber. Wenn das ACK-Paket von Benutzer B nicht innerhalb eines bestimmten Zeitraums empfangen wird, wird die Nachricht aus der "wartenden ACK-Warteschlange" abgerufen und erneut gesendet.
2. Das Problem des wiederholten Pushs von Nachrichten
Wie bereits erwähnt, wird für die Push-Nachricht, wenn das ACK-Paket nicht innerhalb eines bestimmten Zeitraums empfangen wird, die erneute Übertragung des Servers ausgelöst. Es gibt zwei Situationen, in denen die ACK nicht empfangen werden kann. Zusätzlich zu der Tatsache, dass die Push-Nachricht verloren geht und Benutzer B die ACK nicht zurückgibt, kann es auch sein, dass das von Benutzer B zurückgegebene ACK-Paket verloren geht. Im zweiten Fall kann eine durch ACK-Paketverlust verursachte erneute Übertragung des Servers dazu führen, dass der Empfänger wiederholte Push-Nachrichten empfängt.
Lösung:
Die allgemeine Lösung lautet: Wenn der Server die Nachricht sendet, trägt er eine Sequenz-ID. Die Sequenz-ID muss in dieser Verbindungssitzung eindeutig sein. Für dieselbe erneute Push-Nachricht ändert sich die Sequenz-ID nicht. Der Empfänger führt das Geschäft gemäß dieser eindeutigen Sequenz-ID aus. Deduplizierung der Ebene, sodass Benutzer B nach der Deduplizierung immer noch eine Nachricht erhält, die die Benutzererfahrung nicht beeinträchtigt.
3. Verhindert dies wirklich, dass Sie Nachrichten verlieren?
Wenn Sie vorsichtig sind, stellen Sie möglicherweise fest, dass der kombinierte Mechanismus "ACK + Timeout-Neuübertragung + Deduplizierung" das Problem des Nachrichtenverlusts lösen kann, wenn die meisten Benutzer online sind. Kann er alle Nachrichtenverlustszenarien vollständig abdecken? Stellen Sie sich vor, ein IM-Server ist aus Hardwaregründen nach dem Push einer Nachricht ausgefallen. Wenn die Nachricht wirklich verloren geht, ist der verantwortliche IM-Server ausgefallen und kann keine erneute Übertragung auslösen, was zum Empfang führt Partei B kann diese Nachricht nicht empfangen. Es liegt ein Problem vor. Wenn Benutzer B erneut eine Verbindung herstellt und wieder online geht, weiß er möglicherweise nicht, dass eine Nachricht zuvor verloren gegangen ist. Wie gehe ich mit dieser Art von Neuübertragungsfehlern um?
Abhilfemaßnahmen: Überprüfung der Nachrichtenintegrität
Lassen Sie uns das Problem eines erneuten Übertragungsfehlers analysieren, der durch Serverausfallzeiten verursacht werden kann. Das Problem hierbei ist: Der Server ist ausgefallen und die erneute Übertragung funktioniert nicht. Wenn Benutzer B dann eine Integritätsprüfung durchführen kann, wenn Benutzer B wieder online ist, und feststellt, dass Benutzer B einen "Nachrichtenverlust" aufweist, kann er die verlorenen Daten erneut synchronisieren oder reparieren. Der gebräuchlichste Implementierungsmechanismus für die Überprüfung der Nachrichtenintegrität ist der "Zeitstempelvergleich". Die spezifische Implementierung lautet wie folgt:
Lassen Sie uns einen Blick darauf werfen, wie der "Zeitstempelmechanismus" die Integrität von Nachrichten überprüft. Ich werde dieses Beispiel verwenden, um diesen Prozess zu erläutern.
1. Der IM-Server sendet msg1 mit dem neuesten Zeitstempel timest1 an Empfänger B. Nach dem Empfang von msg1 aktualisiert Empfänger B den Zeitstempel der neuesten lokalen Nachricht auf timestamp1.
2. Der IM-Server sendet die zweite Nachricht msg2 mit einem aktuellen letzten Zeitstempel2. Während des Push-Vorgangs wird die Verbindung zwischen Empfänger B und dem IM-Server von msg2 aus irgendeinem Grund getrennt, was dazu führt, dass msg2 nicht erfolgreich an Empfänger B übermittelt wird.
3. Benutzer B stellt die Online-Verbindung wieder her und überträgt den neuesten lokalen Zeitstempel Zeitstempel1. Der IM-Server gibt alle von Benutzer B vorübergehend gespeicherten Nachrichten mit einem Zeitstempel größer als Zeitstempel1 an Benutzer B zurück, einschließlich msg2, die zuvor nicht erfolgreich war.
4. Nachdem Benutzer B msg2 empfangen hat, aktualisiert er den Zeitstempel der neuesten lokalen Nachricht auf timestamp2.
Durch den obigen Zeitstempelmechanismus kann Benutzer B die fehlende Nachricht 2 erfolgreich senden, um dies zu kompensieren. Es sollte beachtet werden, dass, da der Zeitstempel das Problem asynchroner Uhren mehrerer Maschinen aufweisen kann, eine gewisse Abweichung auftreten kann, die zu einer unzureichenden Datenerfassung führt. In der tatsächlichen Implementierung können Sie stattdessen auch die globale Auto-Inkrement-Sequenz als Versionsnummer verwenden.
um zusammenzufassen:
Die Gewährleistung der zuverlässigen Zustellung von Nachrichten ist ein wesentlicher Bestandteil des IM-Systemdesigns. "Kein Nachrichtenverlust" und "Keine Wiederholung von Nachrichten" wirken sich stärker auf die Benutzererfahrung aus. Wir können die folgenden Methoden verwenden, um die Zuverlässigkeit des Pushdowns von Nachrichten sicherzustellen.
1. In den meisten Szenarien und tatsächlichen Implementierungen kann der ACK-Bestätigungs- und Neuübertragungsmechanismus der Geschäftsschicht den größten Teil des Nachrichtenverlusts während des Push-Prozesses beheben.
2. Durch den Deduplizierungsmechanismus des Clients wird das Problem, das bei der erneuten Übertragung zu einer Duplizierung von Nachrichten führen kann, abgeschirmt, um die Benutzererfahrung nicht zu beeinträchtigen.
3. Für das spezielle Szenario nicht erreichbarer Nachrichten zur erneuten Übertragung können wir auch den Integritätsprüfungsmechanismus "Undercover" verwenden, um den Zeitverlust der Nachricht zu ermitteln und zu reparieren. Die Integritätsprüfung der Nachricht kann durch Zeitstempelvergleich oder global erfolgen Es kann durch selbsterhöhende Sequenz realisiert werden.