L'Architecture de cache Redis & Mongo pour la persistance

Question

Le Programme D'Installation:
Imaginer un "twitter comme" le service lorsqu'un utilisateur envoie un message, qui est ensuite lu par un grand nombre (des centaines, des milliers, ou plus) utilisateurs.

Ma question est au sujet de la meilleure façon de l'architecte de la mémoire cache et la base de données pour optimiser pour un accès rapide et bien lit, mais toujours garder l'historique des données afin que les utilisateurs peuvent (s'ils le veulent) voir les messages plus anciens. L'hypothèse ici est que 90% des utilisateurs ne seraient intéressé par les nouveaux trucs, et que les vieux trucs aurez accédé à l'occasion. L'autre hypothèse ici est que nous voulons optimiser pour les 90%, et son ok si le vieux de 10%, un peu plus de temps pour récupérer.

Avec cela à l'esprit, ma recherche semble fortement point dans le sens de l'utilisation d'un cache pour les 90%, et puis aussi de stocker les messages dans un autre plus long terme du système persistant. Donc, mon idée à ce jour est l'utilisation de Redis pour le cache. Avantages est que le Redis est très rapide, et aussi il a construit dans pub/sub qui serait parfait pour la publication des postes à beaucoup de gens. Et puis j'ai été envisage d'utiliser MongoDB comme un plus permanent de la banque de données pour stocker les mêmes postes qui seront accessibles qu'ils expirent hors de Redis.

Questions:
1. Cette architecture contenir de l'eau? Est-il une meilleure façon de le faire?
2. Concernant le mécanisme de stockage de postes dans les deux le Redis & MongoDB, je pensais avoir l'app faire 2 écrit: 1er - écrire pour le Redis, il est alors immédiatement disponible pour les abonnés. 2e - après le succès de stockage pour le Redis, écrire à MongoDB immédiatement. Est-ce la meilleure façon de le faire? Devrais-je plutôt Redis pousser l'expiration de postes à MongoDB lui-même? J'ai pensé à ce sujet, mais je ne pouvais pas trouver beaucoup d'informations sur le poussant vers MongoDB de Redis directement.

Answer 1

Il est effectivement judicieux de les associer MongoDB et Redis: ils sont de bons joueurs de l'équipe. Vous trouverez plus d'informations ici:

MongoDB, redis avec

Un point critique est la résilience de niveau dont vous avez besoin. Les deux MongoDB et Redis peut être configuré pour assurer un niveau acceptable de la résilience, et ces questions doivent être abordées au moment de la conception. Aussi, il peut mettre de contrainte sur les options de déploiement: si vous voulez réplication maître/esclave pour les deux MongoDB et Redis vous avez besoin d'au moins 4 cases (MongoDB et Redis ne doit pas être déployé sur la même machine).

Maintenant, il est peut-être un peu plus simple pour garder le Redis pour les les d'attente, pub/sub, etc ... et de stocker les données des utilisateurs dans MongoDB seulement. La justification est que vous n'avez pas à la conception des données similaires, voies d'accès (la partie la plus difficile de ce travail) pour les deux magasins offrant des paradigmes différents. Aussi, MongoDB a intégré dans l'évolutivité horizontale (jeux de réplicas, auto-partage, etc ...), tandis que le Redis a seulement do-it-yourself de l'évolutivité.

Concernant la seconde question, écrit à la fois des magasins serait la meilleure façon de le faire. Il n'y a aucune fonctionnalité intégrée à reproduire Redis activité à MongoDB. La conception d'un démon à l'écoute d'un Redis file d'attente (où l'activité serait affiché sur le site) et de l'écriture à MongoDB n'est pas si dur.