¿Cómo funciona CCR & amp; El modelo del kit de herramientas DSS se compara con otra escalabilidad & amp; enfoques de concurencia?

Question

Estoy interesado en la comparación entre varios enfoques de escalabilidad & amp; concurrencia incluyendo CCR & amp; Modelo de marco DSS. Me interesaría especialmente en comparación con la concurencia de estilo Hadoop y Erlang

Answer 1

He analizado CCR, DSS y Erlang, aunque de estos, solo he enviado CCR a un código de producción significativo. Nunca he mirado a Hadoop.

La concurrencia de Erlang se deriva de su implementación del modelo Actor. Cada 'proceso' tiene un buzón de correo y recupera los mensajes, uno a la vez. Un proceso sin mensajes para manejar bloques sin hilos. Por el contrario, los procesos con trabajo por hacer están programados en la CPU disponible, sin que ninguno de los equipos subyacentes esté expuesto. Además, los procesos se comunican a través del paso de mensajes con clonación / inmutabilidad asegurando que P1 y P2 nunca compartan lógicamente los mensajes que pasan entre ellos.

Mi sensación es que es la naturaleza sin bloqueo del envío y recepción de mensajes lo que le da a Erlang su reputación de escalabilidad en una sola máquina (posiblemente de múltiples núcleos). Esencialmente, los procesos con trabajo por hacer están programados de manera eficiente en todos los recursos disponibles y los procesos inactivos no consumen más que memoria. Al procesar un mensaje a la vez, cada uno de los cuales garantiza la estabilidad del mensaje, el desarrollador ya no tiene que preocuparse por cosas como las "condiciones de carrera".

CCR es un conjunto de primitivas de paso asíncrono de mensajes de bajo nivel. Uno de los más simples es Receive que recibe un a la Erlang. Pero hay primitivas más sofisticadas, como Join (recibir un mensaje en todos los canales) y Choice (recibir un mensaje en cualquiera de algunos canales), que se pueden anidar y componer de formas interesantes. Estas primitivas tampoco son bloqueantes. Los receptores generan tareas (para manejar los mensajes) en colas de tareas 1..n, que son atendidas por un pequeño número de subprocesos.

Supongo que, ignorando las diferencias de plataforma (¡importante!), las rutinas básicas de programación de tareas de cada uno se encuentran básicamente en el mismo parque. Sin embargo, Erlang es un lenguaje y una plataforma con un modelo fijo (Actor) integrado. El CCR no es ninguna de estas cosas, es solo una biblioteca y puede usarlo / abusarlo más libremente.

DSS es un modelo de programación, que se basa en CCR. Tiene servicios (Erlang = procesos), exige el paso de mensajes asíncronos (con clonación completa por defecto) como la única forma de comunicación entre servicios, y el único controlador que el mundo exterior tiene para un servicio es su URI (Erlang = PID) . Al igual que Erlang, esencialmente no hay diferencia entre invocar un servicio local y uno remoto, aunque en este último caso se produce una (des) serialización.

DSS también tiene un modelo RESTful, lo que significa que los servicios suelen exponer un conjunto fijo y común de operaciones, y que el estado del servicio debe considerarse un recurso manipulado por estas operaciones. Contrasta esto con Erlang, donde se pueden enviar mensajes arbitrarios a un proceso. Los servicios DSS pueden usar el conjunto completo de primitivas CCR para comunicarse con otros servicios, lo que puede ser muy útil para cosas como las operaciones distribuidas de dispersión-reunión.

En última instancia, DSS es solo un marco con bibliotecas compatibles, no un lenguaje o VM, por lo que hay mucho más 'ceremonia' involucrada en escribir incluso un solo servicio DSS en lugar de escribir un proceso Erlang.

En términos de concurrencia, todos proporcionan las primitivas requeridas para escribir código que sea seguro y eficiente bajo múltiples hilos de ejecución, sin preocuparse por esos hilos de ejecución. Creo que es a donde se dirigen la mayoría de los desarrolladores.

En términos de escalabilidad, es una pregunta más difícil de responder ya que se trata tanto del diseño del sistema como de las herramientas utilizadas. ¿Se refiere a la escalabilidad en un solo nodo, es decir, a medida que agrega núcleos, o al agregar nodos? CCR no tiene nada que decir sobre esto último. Tanto DSS como Erlang admiten formatos binarios bastante eficientes para la transmisión por cable. DSS hereda su visión del mundo orientada a los recursos directamente de http, que debería decirle algo sobre su escalabilidad potencial , pero lo hace con algunas restricciones en el modelo de programación.

Un par de puntos técnicos. Un solo servicio DSS consume más memoria (~ 2K) que un solo proceso de erlang (300-400 bytes). Además, cada servicio DSS obtiene su propia cola de tareas y hay un límite superior (~ 10000) en el número de colas de tareas que el CCR puede procesar de manera eficiente. No tengo números en ningún límite superior para Erlang, pero sospecho que podría ser más alto que esto.

Habiendo dicho todo esto, si estás en la plataforma .NET, te estarías haciendo un favor echándote un vistazo serio al CCR. He encontrado que es muy potente, especialmente para programas reactivos controlados por eventos.