2016-09-16 2 views
0

Je vois souvent des files d'attente dans l'architecture logicielle, en particulier celles dites "évolutives" avec un représentant éminent de la plateforme multi-acteurs Actor from Akka.io. Cependant, comment la file d'attente peut-elle être évolutive, si nous devons synchroniser le placement des messages dans la file d'attente (et donc opérer dans un thread unique vs multi thread) et synchroniser à nouveau les messages de la file d'attente? Cela devient encore plus compliqué, lorsque ces messages peuvent changer l'état du système (acteur) - dans ce cas, même après avoir retiré le message de la file d'attente, il ne peut pas être équilibré, mais traité dans un seul thread.Comment la file d'attente (de messagerie) peut-elle être évolutive?

  1. Est-il correct que la mise en file d'attente des messages doit être synchronisée?
  2. Est-il exact que la mise en file d'attente des messages doit être synchronisée?
  3. Si 1 ou 2 est correct, alors comment la file d'attente est-elle évolutive? La synchronisation avec un seul thread ne crée-t-elle pas immédiatement un goulot d'étranglement?
  4. Comment le système (acteur) peut-il être évolutif, s'il est statefull?
  5. Est-ce que l'acteur/bean statefull signifie que je dois traiter les messages dans un seul thread et dans l'ordre?
  6. Est-ce que statefullness signifie que je dois avoir une copie de bean/acteur par système entier?
  7. Si 6 est faux, alors comment partager cet état entre les instances?
  8. Lorsque j'essaie de connecter mon nouveau noeud P2P à netowrk, je crois que je dois avoir un "serveur" qui me dira, qui sont les autres pairs, est-ce correct? Quand j'essaie de télécharger un torrent, je dois me connecter au tracker - s'il y a un "serveur" alors on l'appelle "P2P"? Si ce tracker va tomber, je ne peux pas me connecter aux pairs, n'est-ce pas?
  9. La synchronisation et l'étatabilité détruisent-ils l'évolutivité?
+0

Certaines de ces questions sont vaguement liées au mieux, vous devriez les poser séparément. – the8472

Répondre

1
  1. Est-il exact, que la mise en file d'attente des messages doivent être synchronisés?
  2. Est-il exact que la mise en file d'attente des messages doit être synchronisée?

n °

En supposant que nous parlons le mot-clé java synchronized alors c'est un verrou d'exclusion mutuelle reenetrant sur l'objet. Même plusieurs threads accédant à ce verrou peuvent être rapides tant que contention est faible. Et chaque objet a sa propre serrure, donc il y a beaucoup de verrous, chacun qui doit seulement être pris pendant une courte période, c'est-à-dire qu'il est verrouillé à grain fin. Mais même si c'était le cas, les files d'attente n'ont pas besoin d'être implémentées via des verrous d'exclusion mutuelle. Lock-free and even wait-free Les structures de données de file d'attente existent. Ce qui signifie que la simple présence de verrous n'implique pas automatiquement une exécution monothread.

Le reste de vos questions doivent être posées séparément car elles ne concernent pas la mise en file d'attente des messages.

1

Bien sûr, vous avez raison de dire qu'une seule file d'attente n'est pas évolutive. Le point du modèle d'acteur est que vous pouvez avoir des millions d'acteurs et donc répartir la charge sur des millions de files d'attente, si vous avez autant de cœurs dans votre cluster.Rappelez-vous toujours ce que Carl Hewitt a dit:

Un acteur n'est pas un acteur. Les acteurs viennent dans les systèmes.

Chaque acteur individuel est une unité de calcul entièrement séquentielle et monothread. Le modèle entier est construit de telle sorte qu'il est parfaitement adapté pour décrire la distribution, cependant; Cela signifie que vous créez autant d'acteurs que nécessaire.

+0

ok, mais si cet acteur est statefull, alors je ne peux pas avoir des millions de copies de lui (ou je peux, mais doit en quelque sorte partager l'état). que diriez-vous de mes autres questions? – spam

+0

"la file d'attente unique n'est pas évolutive" ... c'est discutable. Faire des files d'attente elles-mêmes à l'échelle est non-trivial, mais pas impossible. – the8472

+0

@spam J'ai répondu à votre première question, veuillez poser des questions distinctes si vous voulez des réponses à ces autres sujets très différents. Pour la gestion d'état je vous recommande de lire sur sharding, voir par exemple le module ClusterSharding d'Akka. Il y a aussi de bons livres sur le sujet, par ex. «Motifs réactifs de messagerie» (Vaughn Vernon) ou «Motifs de conception réactifs» (Roland Kuhn). –