Chat en temps réel avec l'histoire via les websockets

Je suis intéressé à créer ce que Disqus a fait avec leur système de commentaires: http://highscalability.com/blog/2014/5/7/update-on-disqus-s-still-about-realtime-but-go-demolishes .html

La partie la plus impressionnante de l'infrastructure est le module Nginx Push Stream:

Fonctionne toujours avec 5 machines Nginx.

Utilise NginxPushStream, qui supporte EventSource, WebSocket, Long Polling et Forever Iframe.

Tous les utilisateurs sont connectés à ces machines.

Dans une journée normale, chaque machine voit 3200 connexions / s, 1 million de connexions, 150K paquets / s TX et 130K paquets / s RX, 150 mbits / s TX et 80 mbits / s RC, avec <15ms de retard de bout en bout ( Qui est plus rapide que Javascript peut rendre un commentaire)

En premier lieu, il y a eu de nombreux problèmes avec l'épuisement des ressources. La configuration de Nginx et du système d'exploitation est donnée pour aider à atténuer les problèmes, en les réglant pour gérer un scénario avec de nombreuses connexions qui déplacent de petites données.

De toute évidence, ce module Nginx ne prend pas en charge le stockage de données. Seul le mécanisme en mémoire pris en charge par la directive push_stream_store_messages , mais comme l'a déclaré l'auteur :

La cible principale des messages stockés est de transmettre le message à un abonné déconnecté lorsque le message a été publié.

Il est clair que Disqus ne publie pas de messages directement sur Nginx, mais plutôt que le backend de Go qui gère les messages de Redis est suivi de la publication via POST interne à Nginx qui maintient les abonnés.

Est-ce que quelqu'un a l'expérience d'extraire l'historique des messages via Redis sur un chargement de page avant même d'utiliser le module push stream pour les messages plus récents? Est-ce que vous devez pousser l'ancien historique des messages en une fois ou rendre en HTML simple suivi de pubsub pour les nouveaux messages qui apparaissent après la chargement de la page?

La logique doit être découplée autant que possible. Je n'ai pas l'intention d'introduire un mécanisme de blocage entre l'utilisateur et Nginx pour la communication des messages en temps réel. Serait-ce une bonne solution ci-dessous?

  1. Le client pousse le message à partir de la page Web (via les websockets)
  2. La requête Ajax se dirige directement vers l'emplacement de l'émetteur et sur le rappel complet d'Ajax, il demande un backend pour stocker le message dans Redis (dans l'autre sens, il se bloque avec le backend).
  3. Une fois que l'utilisateur a rafraîchi la liste des redressements de la page Redist et affiche l'historique
  4. L'utilisateur peut voir l'histoire et peut publier de nouveaux messages

Il ne nécessite que 2 requêtes de backend à développer: acceptez le message et entrez dans Redis, récupérez les données et affichez-les en charge de la page. De préférence, un backend léger non bloquant requis, comme le module Lua ou même l'interface HTTP vers Redis, s'appelle Webdis .

J'aimerais connaître l'opinion des gens intelligents sur ce mécanisme du point de vue de l'architecture, pas d'exemple de code attendu.