Em Parte 1 desta série do blog sobre a compreensão da ordenação no Couchbase Functions, observamos como as mutações são consumidas por Serviço de eventos do Couchbase em diferentes cenários.
Agora, vamos dar uma olhada nos bastidores do Eventing Service e tentar entender como os Eventing Workers são realmente atribuídos para processar as mutações.
Atribuições do vBucket para o trabalhador
O Couchbase divide automaticamente os dados entre os nós de dados; esses fragmentos são chamados de vbuckets. Cada bucket é fragmentado em 1024 vBuckets. Para saber mais sobre a fragmentação automática e os vbuckets, confira este whitepaper.
Vamos supor que nosso cluster de amostra tenha 3 nós de dados e 1 nó de eventos. Há 2 funções implantadas no nó de eventos e elas escutam 1 bucket no nó de dados.
O Bucket de origem é automaticamente fragmentado em 1024 buckets que são distribuídos entre os 3 nós. A ilustração abaixo mostra o vBucket a ser atribuído em uma ordem monotonicamente crescente, mas isso pode não ser sempre o caso; a ilustração lista a sequência do vBucket em ordem para facilitar a leitura. Há duas funções implantadas no nó Eventing: fn-email e fn-score, cada uma com 4 e 3 workers atribuídos a elas, respectivamente.
Como há apenas um nó de eventos, todos os 1024 vBuckets são atribuídos a esse nó de eventos. Cada trabalhador de uma determinada função escuta 1024/ dos vBuckets. A distribuição de vBuckets seria diferente em um para poucos trabalhadores, se 1024/num_workers != 0. Portanto, como visto na ilustração, cada um dos 4 trabalhadores da função fn-email escuta 256(=1024/4) vBuckets; e, com a mesma analogia, cada um dos 3 trabalhadores da função fn-score escuta 341(=1024/3) vBuckets (com um trabalhador sozinho vendo 342 vBuckets).
Se o cluster estiver estável e não houver Rebalanceamento de Cluster: Todas as mutações que ocorrerem em um determinado vBucket serão consumidas pelo trabalhador designado; todas as alterações que ocorrerem em um determinado documento serão consumidas pelo trabalhador em ordem (basicamente, cada processo de trabalho gera vários threads e os documentos são vistos em ordem pelo thread).
Agora, isso explica por que os documentos não são processados na sequência (Take-Away#1 e Take-Away#3 em Parte 1) em que foram inseridos, pois os documentos podem pertencer a diferentes vBuckets e, portanto, diferentes funcionários atribuídos a esses diferentes vBuckets operam neles simultaneamente, o que leva a um comportamento não sequencial.
Escalabilidade elástica
Agora, digamos que a taxa de mutação aumente e vejamos que o backlog no nó de Eventing único aumenta, levando a uma carga crescente na CPU do nó de Eventing. O administrador adiciona mais um nó de eventos e executa um rebalanceamento do cluster.
Agora, cada um dos Eventing Nodes vê 1024/2 = 512 vBuckets atribuídos a ele, e os workers também veem metade dos vBuckets do que foi atribuído anteriormente. As atribuições de vBuckets a workers são executadas sem problemas pelo Eventing Service durante o Rebalanceamento e são totalmente transparentes para o Administrador.
Como o bucket de metadados armazena as informações do ponto de verificação do processamento que está sendo feito e também as atribuições do trabalhador, nenhuma mutação é perdida e o Eventing Service do Couchbase funciona perfeitamente durante os rebalanceamentos do cluster.
O comportamento acima oferece escalabilidade elástica com base em diferentes sazonalidades ou padrões de tráfego.
Comportamento durante o modo DEBUG
O depurador on-line em tempo real ajuda os desenvolvedores a depurar o código implantado à medida que as mutações ocorrem. Uma sessão de depuração opera somente em uma mutação por vez, e essa mutação é selecionada arbitrariamente. Uma nova sessão de depuração deve ser iniciada para cada alteração sucessiva a ser observada.
Quando uma sessão de depuração é iniciada, uma única mutação é atribuída a um trabalhador para a sessão de depuração e o restante das mutações que ocorrem no bucket é processado; ou seja, o restante das mutações que ocorrem no bucket de origem não é bloqueado quando a sessão de depuração está em andamento.
É importante observar que o depurador não deve ser usado em ambientes de produção e é melhor consumido em ambientes de desenvolvimento. Enquanto a sessão do depurador está em andamento, o restante das mutações é processado pela função. As atribuições vbucket-to-worker que vimos anteriormente são válidas, mas a mutação que foi usada para o depurador é processada fora da sequência. Portanto, uma sessão do Depurador no ambiente de Produção pode introduzir problemas de tempo e causar mutações perdidas se a sessão do Depurador for encerrada no meio. Além disso, se a operação na função for sensível à ordem das mutações de um determinado documento, esse processamento fora de sequência da mutação poderá levar a estados que não estão corretos.
Esperamos que esta série de duas partes tenha lhe dado uma boa compreensão de algumas das semânticas de ordenação de trabalhadores e também uma rápida olhada nos bastidores do Serviço de eventos do Couchbase.
