Je souhaite utiliser la fonctionnalité d'approvisionnement d'événements d'AKKA-Persistence afin de mettre en œuvre une idée du CRQS + de l'approvisionnement d'événements dans mon nouveau projet. Le problème est que, outre la documentation ( http://doc.akka.io/docs/akka/ Snapshot / Scala / Persistence.html ) Je n'ai pas trouvé de bons exemples ni de directives sur la manière de l'approcher. La documentation est excellente en termes d'explication de tous les blocs de construction de l'architecture telles que les processeurs, les vues, les canaux, mais n'explique pas comment les mettre ensemble.
La question est donc la suivante: comment je devrais connecter un modèle d'écriture avec des modèles de lecture à Akka-persistance? J'ai proposé trois options:
Connexion directe EvènementsourcedProcessor -> Voir, la vue reçoit tous les événements directement à partir du journal. Il semble que la solution la plus simple, mais je me demande si nous pouvons distribuer le processeur et afficher sur différents nœuds en utilisant cette approche.
EventsourcedProcesseur -> Channel -> Vue / Acteur normal. Quelle est la différence avec la première option? S'il s'agit de la bonne solution, pourquoi nous avons des vues dans des blocs de construction d'Akka-persistance? Dois-je utiliser des canaux ou des canaux persistants?
EventsourcedProcesseur -> Une sorte de bus d'événement (par exemple contexte.system.eventstream) -> Vues / acteurs.
Quelle est la meilleure façon d'aller et pourquoi?
4 Réponses :
EventsourcedProcessor -> La vue est la meilleure façon de le faire. La vue Replaye à partir du journal, vous avez donc besoin d'un journal distribué lors de la vue sur une autre machine. La liste des journaux de journal peut être trouvée ici: http://akka.io/community/
Merci! Pourriez-vous expliquer pourquoi est-ce? Il semble une approche raisonnable de couvrir tous les cas mauvais (par exemple, un nœud avec une vue redémarre, demande à tous les événements du journal et les replie), mais je suis un peu peur qu'il puisse blesser la performance dans l'état normal du cluster. Je pense que la poussée d'événements à une sorte de bus d'événement est plus légère et conviviale que de demander au journal pour des événements tout le temps. Est-ce que je manque quelque chose dans ma compréhension? Pourquoi avez-vous choisi Journal comme point de connexion entre les processeurs et les vues?
Il peut y avoir des moyens plus efficaces pour des cas d'utilisation spécifiques, mais vous devez alors considérer des choses comme: Démarrage d'une nouvelle vue, découplage entre les côtés de l'écriture et la lecture, la perte de message, la commande de message, les duplicates. Toutes ces choses peuvent être des problèmes difficiles dans une architecture de pub distribuée.
Alors que je pense que la lecture d'un PE Journal est un excellent moyen de récupérer / reconstruire une vue, il semble interroger le journal (akka.persistence.view.view.Auto-update-intervalle). Cela ne serait pas approprié si on souhaitait des mises à jour synchrones du modèle de lecture (qu'il a été suggérée par certains peut être un bon point de départ pour les modèles de lecture). Je suggérerais (et j'aime utiliser moi-même) le journal de la récupération, mais j'ai une sorte d'architecture de pub-sous-sol pour les événements en direct. Je sais que cela peut être très difficile mais cela semble être la bonne chose à faire. Cependant, je ne suis pas suffisamment connu pour suggérer comment faire de manière distribuée de pub-sous avec une persistance Akka ou d'autres bibliothèques ou même sûre s'il est vraiment pratique de le faire.
Autre alternative, serait-il possible que des vues soient notifiées lorsque les journaux suivants sont mis à jour?
Il y a vraiment une bonne discussion sur ce sujet. Je suis juste en train de coller la conclusion post https://groups.google.com/ Forum / #! Topic / Akka-User / MNDC9CVG1TO . J'espère que cela devrait aider les lecteurs atterrissaient dans ce post.
J'ai également trouvé difficile de trouver de bons exemples sur la manière d'aborder la persistance d'Akka et l'approvisionnement d'événements. Par conséquent, j'ai créé cet exemple d'application à l'aide de Dropwizard et d'Akka Persistence, exemple Akka-persistence-java-Exemple < / a>
Cet exemple utilise persistenseActor pour écrire des données et
Pour une réponse mise à jour qui utilise la requête Akka Persistence et Akka Streams, voir Stackoverflow.com/a/42941900/2113120