Comment CCR & amp; Le modèle de boîte à outils DSS se compare à d’autres solutions d’évolutivité & amp; approches de concurence?

Question

Je suis intéressé par la comparaison entre diverses approches d’évolutivité & amp; accès simultané, y compris CCR & amp; Modèle de cadre DSS. Je serais particulièrement intéressé par la comparaison avec la concurence de style Hadoop et Erlang

Answer 1

J'ai examiné CCR, DSS et Erlang, bien que parmi ceux-ci, je n'ai livré que du CCR dans un code de production significatif. Je n'ai jamais regardé Hadoop.

La simultanéité de Erlang découle de sa mise en œuvre du modèle Actor. Chaque "processus" a une boîte aux lettres et récupère les messages, un à la fois. Un processus sans message à gérer bloque pas de thread. Inversement, les processus comportant des tâches à effectuer sont planifiés sur toutes les unités centrales disponibles, sans aucune des machines sous-jacentes exposées. De plus, les processus communiquent via la transmission de messages avec clonage / immuabilité, ce qui garantit que P1 et P2 ne partagent jamais logiquement les messages échangés.

Mon sentiment est que c'est la nature non bloquante de l'envoi et de la réception des messages qui donne à Erlang sa réputation d'évolutivité sur une seule machine (éventuellement multicœur). Essentiellement, les processus dont le travail est à effectuer sont planifiés efficacement sur toutes les ressources disponibles et les processus inactifs ne consomment que de la mémoire. En traitant un message à la fois, garantissant chacun sa stabilité, le développeur ne doit plus s'inquiéter d'éléments tels que les "conditions de concurrence".

CCR est un ensemble de primitives de transmission de messages asynchrones de bas niveau. Un des plus simples est recevoir qui reçoit a la Erlang. Mais il existe des primitives plus sophistiquées, telles que Join (recevoir un message de tous les canaux) et Choice (recevoir un message de n'importe quel canal), qui peuvent être imbriquées et composées de manière intéressante. Ces primitives sont également non bloquantes. Les destinataires génèrent des tâches (pour gérer les messages) dans des files d'attente de tâches 1..n, qui sont desservies par un petit nombre de threads.

J’imagine qu’en ignorant les différences de plate-forme (importantes!), les routines de base de planification des tâches de chacune d’entre elles se trouvent essentiellement dans le même parc de base-ball. Cependant, Erlang est un langage et une plate-forme avec un modèle fixe (acteur). Le CCR n’est ni l’une de ces choses, mais une simple bibliothèque et vous pouvez l'utiliser / en abuser plus librement.

DSS est un modèle de programmation qui repose sur le CCR. Il dispose de services (Erlang = process), il impose la transmission asynchrone des messages (avec le clonage complet par défaut) comme seule forme de communication interservices et le seul traitement que le monde extérieur ait à un service est son URI (Erlang = PID). . Comme Erlang, il n’existe essentiellement aucune différence entre l’appel d’un service local et celui d’un service distant, bien que la (dé) sérialisation se produise dans ce dernier cas.

DSS possède également un modèle RESTful, ce qui signifie que les services exposent généralement un ensemble d'opérations fixe et commun, et que l'état du service doit être considéré comme une ressource manipulée par ces opérations. Comparez cela avec Erlang, où des messages arbitraires peuvent être envoyés à un processus. Les services DSS peuvent utiliser l’ensemble complet des primitives CCR lorsqu’ils dialoguent avec d’autres services, ce qui peut s'avérer très utile pour des opérations telles que les opérations de diffusion / regroupement distribuées.

En fin de compte, DSS n’est qu’un cadre avec des bibliothèques de support, et non un langage ou une machine virtuelle. Il est donc considérablement plus fastidieux d’écrire un seul service DSS que d’écrire un processus Erlang.

En termes de simultanéité, toutes fournissent les primitives requises pour écrire du code sûr et efficace sous plusieurs threads d’exécution, sans se soucier de ces threads d’exécution. Je pense que la plupart des développeurs souhaitent s'y rendre.

En ce qui concerne l'évolutivité, il est plus difficile de répondre à cette question, car elle concerne autant la conception du système que les outils utilisés. Voulez-vous dire évolutivité sur un seul nœud, c’est-à-dire lorsque vous ajoutez des cœurs ou lorsque vous ajoutez des nœuds? Le CCR n'a rien à dire sur ce dernier. DSS et Erlang prennent tous deux en charge des formats binaires relativement efficaces pour la transmission filaire. DSS hérite de http une vue du monde axée sur les ressources, ce qui devrait vous en dire plus sur son potentiel , mais il le fait avec certaines restrictions dans le modèle de programmation.

Quelques points techniques. Un seul service DSS consomme plus de mémoire (~ 2 Ko) qu'un seul processus erlang (300 à 400 octets). De plus, chaque service DSS obtient sa propre file d'attente de tâches et une limite supérieure (~ 10000) concerne le nombre de files d'attente de tâches pouvant être traitées efficacement par le CCR. Je n'ai pas de chiffres sur ces limites supérieures pour Erlang, mais je pense que cela pourrait être plus élevé que cela.

Cela dit, si vous utilisez la plate-forme .NET, vous vous rendriez service en regardant de près le CCR. Je l’ai trouvé très puissant, en particulier pour les programmes réactifs pilotés par les événements.