Quelqu'un peut-il me donner une certaine direction en ce qui concerne différentes façons de Synchronisez les bases de données d'écriture et de lecture?
Quelles sont les technologies différentes, et comment évaluez-vous chacun, dans Termes de realience, de performance, de coût à la mise en œuvre, etc.
3 Réponses :
Typiquement dans les CQRS, la DB d'écriture est utilisée pour stocker des données de transition pour les processus longs de fonctionnement (SAGAS). Si vous synchronisez la base de données de lecture et d'écriture (je suppose que vous voulez dire des deux manières), vous risquez de faire quelque chose de mal.
Pour un processus de course à long terme Lorsqu'un service s'attend à de multiples messages, il a besoin d'une manière de stocker des données temporaires avant que tous les messages arrivent. Un exemple de ceci est l'enregistrement du client où une approbation de Gestionnaire, qui prend une semaine à traiter, est requise. Le service a besoin d'un moyen de stocker temporairement les informations client avant que l'approbation n'arrive. C'est ici que la DB d'écriture est utilisée pour stocker cette pièce de données temporaires. Notez que avant l'approbation du client, rien n'est écrit à la DB de lecture encore.
Lorsque l'approbation arrive enfin, le service prendra les informations client à partir de la DB d'écriture, complétez le processus d'inscription et écrivez-le à la DB de lecture. À ce stade, les informations temporaires des clients dans la DB d'écriture ont effectué son travail et peuvent être supprimés de la DB d'écriture. Notez qu'il n'y a pas de synchronisation à double sens.
Pour un processus plus simple, tel que Changer le prénom du client, le changement peut être écrit à la DB de lecture immédiate immédiate. L'écriture sur la DB d'écriture n'est pas requise car il n'y a pas de données temporaires dans ce cas.
Si vous, comme moi, voyez le magasin de lecture comme dB que le service de requête utilise (et sa dénormalisation) et l'écriture DB comme base de données où les événements de domaine sont stockés, alors si vous avez besoin de les synchroniser à un moment donné, ce que vous pouvez faire est simplement de relire les événements que vous avez stockés. Dans le cas où vous souhaitez être aussi à jour que possible, vous n'avez pas besoin de limiter la version
si vous utilisez des CQRS, vous aurez probablement un référentiel qui ressemble un peu à ce J'espère que cela aide
Acclamations
Le modèle de requête ne doit pas nécessairement être cohérent. Il doit être finalement cohérent. Le modèle de requête est également le modèle de vue, c'est-à-dire que les tables sont déjà jointes selon l'exigence d'interface utilisateur. Donc, vous pouvez utiliser même un cache en mémoire, ou comme Redis.
La commande côté est comme des objets de commande contenant toutes les informations pertinentes pour mettre à jour la base de données. Ces objets peuvent remplir une file d'attente de messagerie. Les objets de commande sont traités par un processeur de commande qui met à jour transactionnellement le cache de requête et la base de données d'écriture. La base de données d'écriture peut être un RDBM .. mais comme il est apparent, devrait être optimisé comme MongoDb.
Vous pouvez mettre à jour la base de données de lecture via un système de messagerie aussi.
De bons systèmes de messagerie à cet effet sont rabbbitmq et 0 mq.
Pouvez-vous expliquer comment cela se rapporte au DDD?
Désolé! Mon mauvais ... j'étais censé mettre des CQRS là-bas ... merci d'avoir mentionné mec!