El diseño de Cassandra fue influenciado por Staged Event-Driven Architecture (SEDA). SEDA es una arquitectura general para servicios de Internet altamente concurrentes, propuesta originalmente en un documento de 2001 llamado "SEDA: An Architecture for Well-Conditioned, Scalable
Internet Services" de Matt Welsh, David Culler y Eric Brewer. Puede leer el documento original de SEDA en http://www.eecs.harvard.edu/~mdw/proj/seda.
En una aplicación típica, una sola unidad de trabajo se realiza a menudo dentro de los límites de un solo hilo. Una operación de escritura, por ejemplo, comenzará y terminará dentro del mismo hilo. Cassandra, sin embargo, es diferente: su modelo de concurrencia se basa en SEDA, por lo que una sola operación puede comenzar con un hilo, que luego pasa el trabajo a otro hilo, que puede pasarlo a otros hilos. Pero no corresponde al hilo actual entregar el trabajo a otro hilo. En su lugar, el trabajo se subdivide en lo que se denomina etapas, y el grupo de subprocesos (en realidad, un servicio java.util.concurrent.Executor) asociado con la etapa determina la ejecución.
Una etapa es una unidad básica de trabajo, y una sola operación puede realizar una transición interna de estado de una etapa a la siguiente. Debido a que cada etapa puede ser manejada por un grupo de subprocesos diferente, Cassandra experimenta una mejora masiva del rendimiento. Este diseño también significa que Cassandra puede administrar mejor sus propios recursos internamente porque diferentes operaciones pueden requerir Entrada y Salida de disco, o pueden estar vinculadas al CPU, o pueden ser operaciones de red, y así sucesivamente, para que los grupos puedan administrar su trabajo de acuerdo a la disponibilidad de estos recursos.
Una etapa consiste en una cola de eventos entrantes, un controlador de eventos y un grupo de subprocesos asociado. Las etapas son administradas por un controlador que determina la programación y la asignación de subprocesos; Cassandra implementa este tipo de modelo de concurrencia utilizando el grupo de subprocesos java.util.concurrent.ExecutorService. Para ver específicamente cómo funciona esto, echa un vistazo a la clase org.apache.cassandra.concurrent.StageManager. Las siguientes operaciones se representan como etapas en Cassandra, incluidos muchos de los conceptos que hemos analizado en post anteriores :
- Read (local reads)
- Mutation (local writes)
- Gossip
- Request/response (interactions with other nodes)
- Anti-entropy ( nodetool repair)
- Read repair
- Migration (making schema changes)
- Hinted handoff
Algunas operaciones adicionales también se implementan como etapas, como las operaciones en memtables que incluyen el vaciado de datos a SSTables y la liberación de memoria. Las etapas implementan la interfaz IVerbHandler para admitir la funcionalidad de un verbo dado. Debido a que la idea de mutación se representa como una etapa, puede desempeñar un papel en las operaciones de inserción y eliminación.
Dejo link : https://en.wikipedia.org/wiki/Staged_event-driven_architecture
