Pourquoi Akka est-il bon pour la concurrence?

Je suis nouveau dans Akka et le framework d'acteur - je suis sûr que je manque quelque chose d'évident, veuillez accepter mes excuses à l'avance.

Je continue de lire que l'un des principaux points à choisir Akka est la façon dont il gère la concurrence.

Il n'est pas clair pour moi pourquoi Akka est si spécial; Je comprends qu'il y a beaucoup de petits acteurs qui sont très légers et rapides; cependant, comment cela peut-il m'aider lorsque deux utilisateurs enregistrent un formulaire en même temps?

N'aurais-je pas encore besoin d'une sorte de verrouillage de concurrence (pessimiste / optimiste / etc.)?

L'un des avantages des modèles de traitement des messages comme les acteurs et les agents est que les problèmes de concurrence traditionnels (principalement la synchronisation de l'état partagé) ne sont plus un problème. L'acteur peut garder l'état privé et le mettre à jour librement sans verrou. Le framework d'acteur garantit qu'un seul message est traité à la fois. Avec le traitement sérialisé, le code peut être écrit sans verrouillage.

Dans votre exemple d'utilisateurs enregistrant un formulaire, en supposant que l'acteur conservait une liste de certaines données de chaque formulaire, l'acteur peut mettre à jour la liste sans verrou, car le cadre garantit qu'un seul formulaire sera traité à la fois. Traditionnellement, vous devez verrouiller les accès à la liste ou utiliser une liste simultanée.

La stratégie de concurrence est un sujet légèrement différent et reste votre responsabilité (aucune stratégie n'étant la stratégie la plus courante). Pour changer légèrement votre exemple, disons que les deux utilisateurs essaient de mettre à jour l'instance de formulaire SAME en même temps. Sans stratégie de simultanéité, les changements de l'un remplaceront l'autre (probablement le dernier gagne). C'est bien, mais au mieux, cela entraîne un comportement inattendu pour l'utilisateur dont les modifications ont été écrasées. S'ils voient le formulaire qu'ils viennent de changer, il aura des valeurs inattendues (de l'autre utilisateur). Au pire (lorsque nous ne parlons pas seulement de mises à jour de formulaires, mais de choses comme l'expédition des commandes), cela peut entraîner des pertes de toutes sortes (temps, revenus, etc.).

L'utilisation d'une stratégie de concurrence permet d'identifier ces cas et de pouvoir les résoudre en fonction des règles métier. Par exemple, Optimistic Concurrency demande à l'utilisateur d'envoyer la version du formulaire qu'il met à jour. Lorsque l'acteur va traiter la modification, il remarque que le 2e utilisateur pense qu'il met à jour la version 5 lorsque le formulaire est réellement à la version 6 en raison de la mise à jour du premier utilisateur. Maintenant, au moins, nous pouvons informer le 2e utilisateur que le formulaire a déjà changé depuis qu'il a commencé à le modifier. Ou quelles que soient les règles que l'entreprise souhaite y appliquer.

Dans le cas de la mise à jour d'un formulaire, vous ne vous souciez probablement pas autant de la concurrence (cela dépend, je suppose). Mais dans d'autres cas, il peut être très important de pouvoir au moins vérifier et gérer les violations. Vous pouvez même ignorer la violation d'accès simultané, comme si les utilisateurs changeaient de sections différentes (pour continuer l'analogie du formulaire). Ou si le changement a un impact important sur l'entreprise (une grosse commande), vous voulez l'accepter et résoudre les conflits mineurs plus tard (par exemple, la mise à jour annuelle des coordonnées n'est pas terminée).

Je crois qu'Akka a un certain nombre d'autres dimensions comme la façon dont il gère les pannes, les superviseurs, etc. qui sont des considérations importantes pour les devops.

Je vais écrire sur le modèle d'acteur en général (pas seulement Akka) en comparaison avec d'autres modèles de concurrence tels que la concurrence classique basée sur les verrous et la mémoire transactionnelle soignée.

Les avantages

1. Concept plus facile à comprendre et à utiliser

   • La concurrence basée sur le verrouillage est difficile; en particulier, il est très difficile de bien faire les choses car il existe de nombreux concepts à comprendre et à utiliser pour être corrects et efficaces: verrous, sémaphores, threads, synchronisation, exclusion mutuelle, barrière de mémoire, etc.

   • Les acteurs, en revanche, sont un concept plus abstrait; vous avez des acteurs qui envoient et reçoivent des messages. Pas besoin de saisir et d'utiliser des concepts de bas niveau tels que la barrière mémoire.

2. Renforce l'immuabilité

   • La mutabilité est source de nombreuses erreurs et bogues dans la programmation, en particulier dans les applications multi-thread. Le modèle d'acteur résout ce problème en imposant l'immuabilité.

3. Moins sujet aux erreurs

   • Pour les deux raisons ci-dessus

4. Efficace

   • Pas aussi efficace qu'une bonne clé écrite, mais en général plus efficace que la mémoire transactionnelle logicielle.

5. Facilement évolutif

   • Théoriquement au moins, l'application devrait évoluer assez bien en ajoutant plus d'acteurs pour effectuer vos tâches. Avec les verrous, il est assez difficile de faire évoluer.

Désavantages

1. Toutes les langues n'imposent pas facilement l'immuabilité;

   • Erlang, le langage qui a d'abord popularisé les acteurs, a l'immuabilité au cœur, mais Java et Scala (en fait la JVM) n'imposent pas l'immuabilité.

2. Encore assez complexe

   • Les acteurs sont basés sur un modèle de programmation asynchrone qui n'est pas aussi simple et facile à modéliser dans tous les scénarios; il est particulièrement difficile de gérer les erreurs et les scénarios de défaillance.

3. N'empêche pas l'impasse ou la famine

   • Deux acteurs peuvent être dans l'état qui attendent le message l'un de l'autre; vous avez donc un blocage comme avec les verrous, bien que beaucoup plus facile à déboguer. Cependant, avec la mémoire transactionnelle, vous êtes garanti sans blocage.

4. Pas si efficace

   • En raison de l'immuabilité imposée et du fait que de nombreux acteurs doivent passer en utilisant le même thread, les acteurs ne seront pas aussi efficaces que la concurrence basée sur les verrous.

Conclusion

La concurrence basée sur les verrous est la plus efficace mais elle est difficile à programmer et sujette aux erreurs; La mémoire transactionnelle logicielle est la plus claire, la plus facile à programmer et la moins sujette aux erreurs, mais elle est également la moins efficace. Les acteurs se situent quelque part entre ces deux modèles avec tous les aspects: facilité de programmation, efficacité et propension aux erreurs.