Mise en place d'un système de notification

Question

Je suis au début de la construction d'un système de notification de style Facebook pour notre page (type jeu social) et je recherche maintenant quelle serait la meilleure façon de concevoir un tel système. Je ne suis pas intéressé par la façon de pousser les notifications à l'utilisateur ou quelque chose comme ça (même pour l'instant). Je recherche comment construire le système sur le serveur (comment stocker les notifications, où les stocker, comment les récupérer etc...).

Donc ... quelques exigences que nous avons :

• aux heures de pointe, nous avons environ 1 000 utilisateurs connectés simultanément (et beaucoup plus d'invités, mais ils n'ont pas d'importance ici car ils n'ont pas de notifications), ce qui génère de nombreux événements.
• il y aura différents types de notifications (l'utilisateur A vous a ajouté comme ami, l'utilisateur B a commenté votre profil, l'utilisateur C a aimé votre image, l'utilisateur D vous a battu au jeu X, ...)
• la plupart des événements génèrent une notification pour un utilisateur (l'utilisateur X a aimé votre image), mais il y a des cas où un événement génère plusieurs notifications (c'est l'anniversaire de l'utilisateur Y par exemple).
• les notifications devraient être regroupées ; si, par exemple, quatre utilisateurs différents aiment une image, le propriétaire de cette image devrait recevoir une notification indiquant que quatre utilisateurs ont aimé l'image et non quatre notifications distinctes (comme le fait FB)

Je me disais donc que je devrais créer une sorte de file d'attente où je pourrais stocker les événements lorsqu'ils se produisent. Ensuite, j'aurais un travail en arrière-plan ( réducteur ?) qui examinerait cette file d'attente et générerait des notifications en fonction de ces événements. Cette tâche stockerait ensuite les notifications dans la base de données pour chaque utilisateur (ainsi, si un événement affecte 10 utilisateurs, il y aurait 10 notifications distinctes). Ensuite, lorsque l'utilisateur ouvrirait une page contenant la liste des notifications, je lirais toutes ces notifications pour lui (nous pensons limiter cela à 100 notifications récentes), je les regrouperais et je les afficherais enfin.

Ce qui me préoccupe dans cette approche :

• complexe comme l'enfer :)
• La base de données est-elle la meilleure solution de stockage ici (nous utilisons MySQL) ou dois-je utiliser autre chose (redis semble être une bonne solution également) ?
• Qu'est-ce que je dois stocker dans une notification ? l'ID de l'utilisateur, l'ID de l'utilisateur qui a initié l'événement, le type d'événement (pour que je puisse les grouper et afficher le texte approprié) mais ensuite je ne sais pas comment stocker les données réelles de la notification (par exemple l'URL et le titre de l'image qui a été aimée). Dois-je simplement intégrer cette information lorsque je génère la notification, ou dois-je stocker l'ID de l'enregistrement (image, profil, ...) affecté et extraire l'information de la base de données lors de l'affichage de la notification.
• Les performances devraient être correctes ici, même si je dois traiter 100 notifications à la volée lors de l'affichage de la page de notifications.
• problème de performance possible à chaque requête car je devrais afficher le nombre de notifications non lues à l'utilisateur (ce qui pourrait être un problème en soi puisque je regrouperais les notifications). Ce problème pourrait être évité si je générais la vue des notifications (où elles sont regroupées) en arrière-plan et non à la volée.

Alors, que pensez-vous de la solution que je propose et de mes préoccupations ? N'hésitez pas à commenter si vous pensez que je dois mentionner autre chose qui serait pertinent ici.

Oh, nous utilisons PHP pour notre page, mais cela ne devrait pas être un facteur important ici, je pense.

Answer 1

Une notification concerne quelque chose (objet = événement, amitié..) qui est modifié (verbe = ajouté, demandé..) par quelqu'un (acteur) et signalé à l'utilisateur (sujet). Voici une structure de données normalisée (bien que j'aie utilisé MongoDB). Vous devez notifier certains utilisateurs des changements. Il s'agit donc de notifications par utilisateur ce qui signifie que s'il y a 100 utilisateurs concernés, vous générez 100 notifications.

╔═════════════╗      ╔═══════════════════╗      ╔════════════════════╗
║notification ║      ║notification_object║      ║notification_change ║
╟─────────────╢      ╟───────────────────╢      ╟────────────────────╢
║ID           ║—1:n—→║ID                 ║—1:n—→║ID                  ║
║userID       ║      ║notificationID     ║      ║notificationObjectID║
╚═════════════╝      ║object             ║      ║verb                ║
                     ╚═══════════════════╝      ║actor               ║
                                                ╚════════════════════╝

(Ajoutez des champs de temps là où vous le souhaitez)

Il s'agit essentiellement de regrouper les modifications par objet, afin de pouvoir dire "Vous avez 3 demandes d'amis". Il est également utile de regrouper les modifications par acteur, afin de pouvoir dire "L'utilisateur James Bond a modifié votre lit". Cela permet également de traduire et de compter les notifications comme vous le souhaitez.

Mais, puisque l'objet n'est qu'un ID, il faudrait obtenir toutes les informations supplémentaires sur l'objet que vous voulez avec des appels séparés, à moins que l'objet ne change réellement et que vous vouliez montrer cet historique (par exemple "l'utilisateur a changé le titre de l'événement en ...").

Puisque les notifications sont proches du temps réel pour les utilisateurs du site, je les lierais avec nodejs + websockets client avec php poussant la mise à jour à nodejs pour tous les auditeurs au fur et à mesure que le changement est ajouté.

Answer 2

Il s'agit d'une question vraiment abstraite. Je suppose donc que nous allons devoir en discuter au lieu de vous indiquer ce que vous devriez ou ne devriez pas faire.

Voici ce que je pense de vos préoccupations :

• Oui, un système de notification est complexe, mais pas autant que l'enfer. Il existe de nombreuses approches différentes de la modélisation et de la mise en œuvre de tels systèmes, qui peuvent présenter un niveau de complexité moyen à élevé ;

• Pesonalement, j'essaie toujours de faire en sorte que les choses soient basées sur des bases de données. Pourquoi ? Parce que je peux garantir un contrôle total de tout ce qui se passe - mais ce n'est que moi, vous pouvez avoir le contrôle sans une approche basée sur la base de données ; croyez-moi, vous allez vouloir avoir le contrôle sur cette affaire ;

• Laissez-moi vous donner un exemple concret, pour que vous puissiez partir de quelque part. L'année dernière, j'ai modélisé et mis en œuvre un système de notification dans une sorte de réseau social (pas comme facebook, bien sûr). La façon dont j'y stockais les notifications ? J'avais un notifications table, où je gardais les generator_user_id (l'identifiant de l'utilisateur qui génère la notification), l'élément target_user_id (plutôt évident, n'est-ce pas ?), la notification_type_id (qui fait référence à une table différente avec les types de notification), et tous les éléments nécessaires pour remplir nos tables (timestamps, drapeaux, etc). Mon notification_types utilisé pour avoir une relation avec une notification_templates qui stocke des modèles spécifiques pour chaque type de notification. Par exemple, j'avais un POST_REPLY qui avait un modèle un peu comme {USER} HAS REPLIED ONE OF YOUR #POSTS . A partir de là, j'ai juste traité le {} comme une variable et le # comme lien de référence ;

• Oui, la performance debe y doit être ok. Quand on pense aux notifications, on pense à un serveur qui pousse de la tête aux pieds. Et si vous le faites avec des requêtes ajax ou autre, vous allez devoir vous soucier des performances. Mais je pense que c'est une préoccupation secondaire ;

Le modèle que j'ai conçu n'est, bien sûr, pas le seul que vous pouvez suivre, ni le meilleur d'ailleurs. J'espère que ma réponse, au moins, vous guidera dans la bonne direction.

Answer 3

╔════════════════════╗
║notification        ║
╟────────────────────╢
║Username            ║
║Object              ║
║verb                ║
║actor               ║
║isRead              ║
╚════════════════════╝

Cela semble être une bonne réponse plutôt que d'avoir deux collections. Vous pouvez interroger par nom d'utilisateur, objet et isRead pour obtenir de nouveaux événements (comme 3 demandes d'amis en attente, 4 questions posées etc...)

Faites-moi savoir s'il y a un problème avec ce schéma.

Answer 4

Personnellement, je ne comprends pas très bien le diagramme de la réponse acceptée. Je vais donc joindre un diagramme de base de données basé sur ce que j'ai pu apprendre de la réponse acceptée et d'autres pages.

Les améliorations sont bien accueillies.