En Primera parte de esta serie de blogs sobre la comprensión del Ordenamiento en las Funciones Couchbase, observamos cómo las mutaciones son consumidas por Servicio de eventos Couchbase en diferentes escenarios.
Ahora, vamos a mirar bajo el capó del Servicio de Eventos y tratar de entender cómo los Trabajadores de Eventos realmente se asignan para el procesamiento de las mutaciones.
Asignación de vBucket a los trabajadores
Couchbase divide automáticamente los datos entre los nodos de datos; estos fragmentos se denominan vbuckets. Cada bucket se divide en 1024 vBuckets. Para saber más sobre auto-sharding y vbuckets, echa un vistazo a esto libro blanco.
Supongamos que nuestro cluster de ejemplo tiene 3 nodos de datos y 1 nodo de eventos. Hay 2 funciones desplegadas en el nodo Eventing y escuchan 1 bucket en el nodo Data.
El cubo de origen se divide automáticamente en 1024 cubos que se reparten entre los 3 nodos. La siguiente ilustración muestra el vBucket que se asignará en un orden monotónicamente creciente, pero esto no siempre puede ser el caso; la ilustración enumera la secuencia vBucket en orden para una mejor legibilidad. Hay 2 funciones desplegadas en el nodo Eventing: fn-email y fn-score, cada una con 4 y 3 trabajadores asignados respectivamente.
Como sólo hay 1 nodo de Eventing, todos los 1024 vBuckets están asignados a este nodo de Eventing. Cada trabajador de una función determinada escucha 1024/ de los vBuckets. Si 1024/num_workers != 0, la distribución de los vBuckets se desviaría en uno para pocos trabajadores. Por lo tanto, como se ve en la ilustración, cada uno de los 4 trabajadores de la función fn-email escucha 256(=1024/4) vBuckets; y con la misma analogía, cada uno de los 3 trabajadores de la función fn-score escucha 341(=1024/3) vBuckets (con un solo trabajador viendo 342 vBuckets).
Si el cluster es estable y no hay Rebalanceo de Cluster: Todas las mutaciones que ocurran a un vBucket en particular serán consumidas por el trabajador asignado; todos los cambios que ocurran a un documento en particular serán consumidos por el trabajador en-orden (esencialmente, cada proceso de trabajador genera múltiples hilos, y los documentos son vistos en orden por el hilo).
Ahora bien, esto explica por qué los documentos no se procesan en la secuencia(Take-Away#1 y Take-Away#3 en Parte 1) en los que se insertaron, ya que los documentos pueden pertenecer a diferentes vBuckets y, por tanto, diferentes trabajadores asignados a estos diferentes vBuckets, operar en ellos de forma concurrente dando lugar a un comportamiento no secuencial.
Escalabilidad elástica
Ahora, digamos que la tasa de mutación aumenta y vemos que el backlog en el único nodo Eventing dado aumenta lo que lleva a un aumento de la carga en la CPU en el Nodo Eventing. El Administrador añade un nodo Eventing más y realiza un Rebalanceo del Cluster.
Ahora, cada uno de los Nodos de Eventing ve 1024/2 = 512 vBuckets asignados a él, y los trabajadores también ven la mitad de vBuckets de los que tenían asignados anteriormente. Las asignaciones de vBuckets a trabajadores son realizadas sin problemas por el Servicio de Eventing durante el Rebalanceo y son completamente transparentes para el Administrador.
Como el bucket de metadatos almacena la información del punto de control del procesamiento que se está realizando y también las asignaciones de los trabajadores, no se pierde ninguna mutación y el servicio de eventos de Couchbase funciona sin problemas durante los reequilibrios del clúster.
El comportamiento anterior ofrece una escalabilidad elástica basada en diferentes estacionalidades o patrones de tráfico.
Comportamiento durante el modo DEBUG
El depurador en línea en tiempo real ayuda a los desarrolladores a depurar el código desplegado a medida que se producen las mutaciones. Una sesión de depuración sólo opera sobre una mutación a la vez, y esta mutación se selecciona arbitrariamente. Debe iniciarse una nueva sesión de depuración para cada mutación sucesiva que se desee observar.
Una vez que se inicia una sesión de depuración, se asigna una única mutación a un trabajador para la sesión de depuración y se procesan el resto de mutaciones que ocurren en el bucket; es decir, el resto de mutaciones que ocurren en el bucket de origen no se bloquean cuando la sesión de depuración está en curso.
Es importante tener en cuenta que el Depurador no debe utilizarse en entornos de Producción y es mejor consumirlo en entornos de Desarrollo. Mientras la sesión del depurador está en curso, el resto de las mutaciones son procesadas por la Función. Las asignaciones vbucket-to-worker que vimos antes se mantienen, pero la mutación que se usó para el Depurador se procesa fuera de secuencia. Por lo tanto, una sesión de depuración en un entorno de producción puede introducir problemas de sincronización y puede causar mutaciones perdidas si la sesión de depuración se termina en el medio. Además, si la operación en la Función es sensible al orden de las mutaciones para un documento en particular, entonces este procesamiento fuera de secuencia de la mutación podría conducir a estados que no son correctos.
Esperamos que esta serie de dos partes le haya proporcionado una buena comprensión de la semántica de los pedidos de los trabajadores y también un rápido vistazo a los entresijos de Servicio de eventos Couchbase.
