Das Erstellen eines Chat-Dienstes ist nicht so einfach, wie Sie denken.
Ich habe vollständige XMPP-Server, -Clients und -SDKs erstellt und kann einige der subtilen und schwierigen Probleme bestätigen, die auftreten. Ein Prototyp, bei dem sich Benutzer sehen und chatten, ist einfach. Ein vollständiges Funktionssystem mit Kontoerstellung, Sicherheit, Entdeckung, Anwesenheit, Offline-Zustellung und Freundeslisten ist viel mehr eine Herausforderung. Das dann über eine beliebige Anzahl von Servern zu skalieren ist besonders schwierig.
PubSub ist eher eine Funktion, die von Chat-Diensten (siehe XEP-60) angeboten wird, als ein traditionelles Mittel zum Aufbau eines Chat-Dienstes. Ich verstehe den Reiz, aber PubSub kann Nachteile haben.
Einige Fragen an Sie:
-
Machst du das über das Web? Werden die Benutzer eine Verbindung herstellen und lange polen, oder haben Sie eine Web-Sockets-Lösung?
-
Wie viele Benutzer? Wie viele Verbindungen pro Benutzer? Verhältnis von Schreib- zu Lesevorgängen?
-
Ihre Idee, SQS auf diese Weise zu verwenden, ist interessant, wird aber wahrscheinlich nicht skaliert. Es ist nicht ungewöhnlich, 50.000 oder mehr Benutzer auf einem Chat-Server zu haben. Wenn Sie jede SQS-Warteschlange für jeden Benutzer abfragen, werden Sie das nicht annähernd erreichen. Es wäre besser, für jeden Server eine Warteschlange zu haben, und der Server fragt nur diese Warteschlange ab. Dann müssen Sie herausfinden, auf welchem Server sich ein Benutzer befindet, und die Nachricht in die richtige Warteschlange stellen.
Ich vermute, Sie möchten so etwas wie:
- Eine große RDS-Datenbank im Backend.
- Eine Reihe von Front-End-Servern, die die Client-Verbindungen handhaben.
- Java-/C#-Code auf mittlerer Ebene, der alles verfolgt und Nachrichten an die richtige Stelle weiterleitet.
Um sich ein Bild von der Komplexität des Aufbaus eines Chat-Servers zu machen, lesen Sie die XMPP-RFCs:RFC 3920RFC 3921
