Les bases de PubSub - beaucoup de scénario de suiveurs?

Question

J'ai une application web où les utilisateurs peuvent se suivre. Lorsqu'un utilisateur publie une action, j'aimerais que cette action apparaisse dans les flux des abonnés. Une approche simple pourrait consister à conserver un fichier feed.xml pour chaque utilisateur, qui est mis à jour comme suit:

UtilisateurA est suivi par UserB, UserC.

L'utilisateur A publie du contenu.

Mise à jour UtilisateurB, UtilisateurC flux XML, comme:

// feed-UserB.xml 
UserA flew a kite. 
UserX blah blah blah. 
.... 

// feed-UserC.xml 
UserA flew a kite. 
UserY blah blah blah. 
.... 

c'est comme PubSub (je pense). Je n'en ai pas besoin pour être en temps réel. Je ne suis pas sûr de la façon dont le cas de nombreux adeptes est traité. Si un utilisateur compte 1 million de followers, le hub ne doit-il pas rester là et informer tous les 1 million d'abonnés? Si le concentrateur est exécuté sur un seul serveur, cela peut bloquer le processeur pendant une longue période, n'est-ce pas?

Merci

Answer 1

Ce que vous devez savoir est de savoir si vous avez une situation avec de nombreux abonnés à quelques éditeurs ou une solution plus uniformément répartie avec quelques abonnés à de nombreux éditeurs. S'il s'agit de la première, il peut ne pas être judicieux d'écrire tous les fichiers XML lorsque A est mis à jour, mais de générer une demande «sur», en supposant que la demande en question sera suffisamment faible pour que vous n'ayez pas à générer tous les fichiers X, Y, Z pour chacune des mises à jour de A Cela s'appellerait: mises à jour sur les lectures. Si ceci est le dernier, alors vous êtes mieux: mises à jour sur les écritures: vous construisez X, Y et Z à chaque fois que A se met à jour.