Eventing Improvements: Timers, Handlers and Statistics

Com o lançamento do Couchbase 6.6, o Eventing Service apresenta grandes aprimoramentos de funcionalidade.

Introduzimos novos temporizadores de eventos que podem ser cancelados usando a função cancelTimer() ou criando um novo temporizador com o mesmo identificador de referência de um temporizador existente. Os temporizadores recorrentes também são totalmente compatíveis e podem ser facilmente usados para criar lógica repetitiva usando um retorno de chamada do temporizador para criar novos temporizadores. O agendamento de temporizadores permite que eles sejam criados para dias, semanas ou anos no futuro, sem impacto adverso no desempenho. O manipulador OnDelete agora indica se um documento foi excluído ou expirou usando o novo parâmetro "options". As principais estatísticas de eventos na interface do usuário agora estão co-localizadas com cada controle de ciclo de vida do Functions.

Juntos, esses aprimoramentos simplificam o esforço e o código necessários para criar uma lógica comercial robusta.

Pré-requisitos

Neste artigo, apresentaremos os principais Eventos melhorias adicionadas à versão mais recente do GA, ou seja, a versão 6.6.0 do Couchbase, e para cada item fornecemos um exemplo básico funcional. No entanto, entenda que nenhuma das Eventing Functions fornecidas neste artigo funcionará "como está" em versões anteriores do servidor Couchbase sem alterações significativas e soluções complexas.

Se você não estiver familiarizado com o Couchbase ou com o serviço Eventing, consulte o GET STARTED e um exemplo de Eventing, especificamente o seguinte:

Configure um servidor Couchbase 6.6.0 funcional de acordo com as instruções em Comece aqui!
Compreender os conceitos básicos de Eventing e como implantar uma função básica de Eventing de acordo com as instruções do Arquivamento de documentos exemplo.

Os cronômetros de eventos agora podem ser cancelados

Com a adição da função cancelTimer() ou com a criação de um novo Eventing Timer com o mesmo identificador de referência de um timer existente, os timers ativos que ainda não foram acionados podem ser cancelados. Esse aprimoramento simplifica o código necessário para criar uma lógica comercial robusta.

Os desenvolvedores não são mais obrigados a adicionar campos e lógica e a fazer verificações adicionais para garantir que um Timer que está sendo disparado não seja "obsoleto" e substituído por um Timer mais recente.

Exemplo:

Crie um compartimento de "origem" e um compartimento de "metadados" para Eventing.
Implemente essa função (código abaixo).
Crie um documento no bucket de origem com:

KEY user_scoreboard::1 and DATA {"type": "user_scoreboard", "id": 1}

1

CHAVE placar_do_usuário::1 e DADOS {"tipo": "user_scoreboard", "id": 1}
Inspecione os registros após um minuto.
Exclua o documento com a chave "user_scoreboard::1".
Inspecione os registros após um minuto.
Cancelar a implantação dessa função.

function UserInactivityCallback(context) {
    log('user was inactive for 10 minutes', context.docId);
    /*
    * take some actions ...
    */
}

function OnUpdate(doc, meta) {
    if (doc.type != 'user_scoreboard') return;
    // Create a timestamp 600 seconds from now
    var tenMinutesFromNow = new Date(); // Get current time & add 600 sec. to it.
    tenMinutesFromNow.setSeconds(tenMinutesFromNow.getSeconds() + 600);

    // Every mutation to the user's scoreboard will result in a new Timer but
    // the old timers will be canceled as they have the same identifier, meta.id.
    createTimer(UserInactivityCallback, tenMinutesFromNow, meta.id, {
        "docId": meta.id
    });
}

function OnDelete(meta, options) {
    if (!(meta.id.startsWith("user_scoreboard:"))) return;
    log('user scoreboard was deleted for', meta.id);
    // remove the timer as there is no related document anymore.
    cancelTimer(UserInactivityCallback,meta.id);
    /*
    * take some actions ...
    */
}

função UserInactivityCallback(contexto) {

registro('O usuário ficou inativo por 10 minutos', contexto.docId);

* tomar algumas medidas ...

}

função Sobre a atualização(doc, meta) {

se (doc.tipo != 'user_scoreboard') retorno;

// Criar um registro de data e hora 600 segundos a partir de agora

var dezMinutosDeAgora = novo Data(); // Obtenha a hora atual e adicione 600 segundos a ela.

dezMinutosDeAgora.setSeconds(dezMinutosDeAgora.getSeconds() + 600);

// Toda mutação no placar do usuário resultará em um novo Timer, mas

// os cronômetros antigos serão cancelados, pois têm o mesmo identificador, meta.id.

createTimer(UserInactivityCallback, dezMinutosDeAgora, meta.id, {

"docId": meta.id

});

}

função OnDelete(meta, opções) {

se (!(meta.id.startsWith("user_scoreboard:"))) retorno;

registro('o placar do usuário foi excluído por', meta.id);

// remover o cronômetro, pois não há mais nenhum documento relacionado.

cancelTimer(UserInactivityCallback,meta.id);

* tomar algumas medidas ...

}

Os temporizadores de eventos recorrentes agora são totalmente compatíveis

Os temporizadores recorrentes são totalmente compatíveis, ou seja, uma função invocada por uma chamada de retorno de temporizador pode criar novos temporizadores de forma confiável. Essa atualização permite que uma única Eventing Function implemente de forma confiável eventos recorrentes complexos, criando novos timers a partir da chamada de retorno de outro timer.

Anteriormente, era necessária uma cofunção para criar de forma confiável uma série recorrente de temporizadores (imagem à esquerda). A versão 6.6 simplifica o código necessário para implementar a lógica comercial recorrente (ou programada) (imagem à direita).

Exemplo:

Crie um compartimento de "origem" e um compartimento de "metadados" para Eventing.
Crie um alias de bucket na configuração da função como "src_bkt" para o bucket de origem no modo leitura+gravação.
Implemente essa função (código abaixo).
Crie um documento no bucket de origem com:

KEY recurring_timer::1 and DATA {"type": "recurring_timer", "id": 1, "active": true}

1

CHAVE recurring_timer::1 e DADOS {"tipo": "recurring_timer", "id": 1, "ativo": verdadeiro}
Inspecione os registros após um minuto.
Inspecione as toras após alguns minutos.
Altere o documento com a chave "recurring_timer::1" e mude o campo "active" para false da seguinte forma:
KEY recurring_timer::1 and DATA {"type": "recurring_timer", "id": 1, "active": false}

1

CHAVE recurring_timer::1 e DADOS {"tipo": "recurring_timer", "id": 1, "ativo": falso}
Inspecione os registros após um minuto.
Cancelar a implantação dessa função.

function CreateRecurringTimer(context) {
    log('From CreateRecurringTimer: creating timer', context.mode, context.id);
    // Create a timestamp 30 seconds from now
    var thirtySecFromNow = new Date(); // Get current time & add 30 sec. to it.
    thirtySecFromNow.setSeconds(thirtySecFromNow.getSeconds() + 30);
    // Create a document to use as out for our context
    createTimer(RecurringTimerCallback, thirtySecFromNow, context.id, context);
}

function RecurringTimerCallback(context) {
    log('From RecurringTimerCallback: timer fired', context);

    /*
    * do any sort of recurring work here, just update a date_stamp in a document
    * written back to the source bucket (but with the ID prefixed whit "cur_")
    */
    src_bkt["cur_" + context.id] = { "last_update": new Date() };

    // rearm the timer
    CreateRecurringTimer({ "id": context.id, "mode": "via_callback" })
}

function OnUpdate(doc, meta) {
    // You would typically filter to mutations of interest
    if (doc.type !== 'recurring_timer') return;
    if (doc.active === false) {
        if (cancelTimer(RecurringTimerCallback, meta.id)) {
            log('From OnUpdate: canceled active Timer, doc.active', doc.active, meta.id);
        } else {
            log('From OnUpdate: no active Timer to cancel, doc.active', doc.active, meta.id);
        }
    } else {
        log('From OnUpdate: create/overwrite doc.active', doc.active, meta.id);
        CreateRecurringTimer({  "id": meta.id, "mode": "via_onupdate" });
    }
}

função CreateRecurringTimer(contexto) {

registro('De CreateRecurringTimer: criando cronômetro', contexto.modo, contexto.id);

// Criar um registro de data e hora 30 segundos a partir de agora

var trinta segundos a partir de agora = novo Data(); // Obter a hora atual e adicionar 30 segundos a ela.

trinta segundos a partir de agora.setSeconds(trinta segundos a partir de agora.getSeconds() + 30);

// Criar um documento para usar como saída para nosso contexto

createTimer(RecurringTimerCallback, trinta segundos a partir de agora, contexto.id, contexto);

}

função RecurringTimerCallback(contexto) {

registro('From RecurringTimerCallback: timer fired', contexto);

* Faça qualquer tipo de trabalho recorrente aqui, apenas atualize um date_stamp em um documento

* gravado de volta no bucket de origem (mas com o ID prefixado com "cur_")

src_bkt["cur_" + contexto.id] = { "last_update": novo Data() };

// rearmar o cronômetro

CreateRecurringTimer({ "id": contexto.id, "mode" (modo): "via_callback" })

}

função Sobre a atualização(doc, meta) {

// Normalmente, você filtraria as mutações de interesse

se (doc.tipo !== 'recurring_timer') retorno;

se (doc.ativo === falso) {

se (cancelTimer(RecurringTimerCallback, meta.id)) {

registro('From OnUpdate: canceled active Timer, doc.active', doc.ativo, meta.id);

} mais {

registro('From OnUpdate: no active Timer to cancel, doc.active', doc.ativo, meta.id);

}

} mais {

registro('From OnUpdate: create/overwrite doc.active', doc.ativo, meta.id);

CreateRecurringTimer({ "id": meta.id, "mode" (modo): "via_onupdate" });

}

Os cronômetros podem ser criados para dias/semanas/anos futuros

Um ou um milhão de temporizadores podem ser criados sem impacto adverso no desempenho de um sistema Eventing que, de outra forma, estaria ocioso. Essa capacidade abre casos de uso para notificações de longo prazo e programas de reengajamento de clientes.

Nas versões 6.5.X, a criação de alguns milhares de temporizadores no futuro (como em uma hora ou mais) em um sistema ocioso resultava em um número crescente de operações de bucket de metadados que afetavam o desempenho e podiam eventualmente bloquear mutações para uma determinada Eventing Function.^[1]

Observe que, em uma operação cancelTimer() ou ao substituir um Timer existente por referência, haverá documentos temporários no compartimento de "metadados" do Eventing.^[2]

Exemplo:

Demonstrar a criação de vários Eventing Timers (neste caso, 50.000) e programá-los para um futuro distante (96 horas) e, em seguida, cancelar todo o conjunto (ou permitir que todos disparem a rotina de retorno de chamada) Retorno do cronômetro).

Crie um compartimento de "origem" e um compartimento de "metadados" para Eventing.
Implemente essa função (código abaixo).
Crie um documento no bucket de origem com quaisquer DADOS, como veremos apenas.

KEY spawn_50k_timers::1

1

CHAVE spawn_50k_timers::1
Inspecione as toras após um ou dois minutos.
Exclua o documento com a chave "spawn_50k_timers::1".
Inspecione as toras após um ou dois minutos.
Cancelar a implantação dessa função.

Para ver os 50K Eventing Timers sendo criados e disparados (em vez de serem cancelados):

Edite a função e altere delayMinutes para 1 (você não quer esperar 4 dias).
Implemente a função modificada (código abaixo).
Crie um documento no bucket de origem com quaisquer DADOS, já que só analisamos a CHAVE.

KEY spawn_50k_timers::1

1

CHAVE spawn_50k_timers::1
Inspecione os registros após dois minutos.
Exclua o documento com a chave "spawn_50k_timers::1".
Inspecione as toras após um ou dois minutos.
Cancelar a implantação dessa função.

function TimerCallback(context) {
    if (context.timer_num == 1 || context.timer_num == 50000)
        log('TimerCallback: fired timer #', context.timer_num);
    /*
    * take some actions ...
    */
}

function OnUpdate(doc, meta) {
    if (meta.id != 'spawn_50k_timers::1') return;
    
    // Create a timestamp 96 hours from now (4 days)
    var delayMinutes = 60*96;
    var futureTime = new Date(); 
    futureTime.setMinutes(futureTime.getMinutes() + delayMinutes);

    // make 50K timers 
    for (var i=1; i<= 50000; i++) {
        var timer_id = "tmr_" + i;
        if (i == 1 || i == 50000)
            log('OnUpdate: create timer # ', i, timer_id);
        try {
            createTimer(TimerCallback, futureTime, timer_id, 
                { "docId": meta.id, "timer_num": i});
        } catch (e) {
            log('OnUpdate:  create #', i, " error ", e);
        }            
    }
}

function OnDelete(meta, options) {
    if (meta.id != 'spawn_50k_timers::1') return;
    /*
    * Remove the 50K timer as there is no related control document anymore.
    *
    * Note on a cancel or overwrite there will be documents which will be 
    * cleaned up at a) initial firing schedule of the Timers, b) undeployment 
    * of the function, or c) a lazy cleaning process by the Eventing Service.
    */
    for (var i=1; i<= 50000; i++) {
        var timer_id = "tmr_" + i;
        if (i == 1 || i == 50000)
            log('OnDelete: clear timer # ', i, timer_id);
        try {
            cancelTimer(TimerCallback, timer_id);
        } catch (e) {
            log('OnDelete: clear timer #', i, " error ", e);
        }
    }
}

função Retorno do cronômetro(contexto) {

se (contexto.timer_num == 1 || contexto.timer_num == 50000)

registro('TimerCallback: disparou o cronômetro #', contexto.timer_num);

* tomar algumas medidas ...

}

função Sobre a atualização(doc, meta) {

se (meta.id != 'spawn_50k_timers::1') retorno;

// Criar um registro de data e hora 96 horas a partir de agora (4 dias)

var delayMinutes = 60*96;

var futureTime = novo Data();

futureTime.setMinutes(futureTime.getMinutes() + delayMinutes);

// criar cronômetros de 50 mil

para (var i=1; i<= 50000; i++) {

var timer_id = "tmr_" + i;

se (i == 1 || i == 50000)

registro('OnUpdate: criar cronômetro # ', i, timer_id);

tentar {

createTimer(Retorno do cronômetro, futureTime, timer_id,

{ "docId": meta.id, "timer_num": i});

} captura (e) {

registro('OnUpdate: create #', i, " erro ", e);

}

função OnDelete(meta, opções) {

se (meta.id != 'spawn_50k_timers::1') retorno;

* Remova o cronômetro de 50K, pois não há mais nenhum documento de controle relacionado.

* Observe que, em um cancelamento ou sobrescrita, haverá documentos que serão

* Limpo em a) programação inicial de disparo dos temporizadores, b) desdobramento

* da função, ou c) um processo de limpeza preguiçoso pelo Eventing Service.

para (var i=1; i<= 50000; i++) {

var timer_id = "tmr_" + i;

se (i == 1 || i == 50000)

registro('OnDelete: limpar o cronômetro # ', i, timer_id);

tentar {

cancelTimer(Retorno do cronômetro, timer_id);

} captura (e) {

registro('OnDelete: limpar o cronômetro #', i, " erro ", e);

}

As estatísticas de eventos agora estão localizadas juntamente com os controles de ciclo de vida

Quatro (4) estatísticas importantes de Eventing na interface do usuário agora estão co-localizadas com cada controle de ciclo de vida das funções. Esses aprimoramentos simplificam o esforço, o código e o diagnóstico das Eventing Functions para criar rapidamente uma lógica comercial robusta.

O desenvolvedor ou administrador pode determinar imediatamente que uma função está se comportando mal sem precisar navegar para fora dos controles do ciclo de vida da função.

Exemplo:

Crie um compartimento de "origem" e um compartimento de "metadados" para Eventing.
Faça alguns documentos com qualquer KEY e qualquer DATA no bucket de origem.
Implemente a função modificada (código abaixo), que contém um erro de sintaxe, esquecendo-se de colocar var na frente de uma variável.

function OnUpdate(doc, meta) {
    log('docId', meta.id);
    // this is an error missing 'var'
    a = 2;
}

função Sobre a atualização(doc, meta) {

registro('docId', meta.id);

// isso é um erro, faltando 'var'

a = 2;

}

Quando a função Eventing é implementada, há um feedback imediato de que algo deu errado para o desenvolvedor.

O usuário responde ao feed back, ou seja, às falhas "vermelhas" e pode inspecionar a função para identificar a origem do erro.

Cancelar a implantação dessa função de eventos.
Corrija o erro nesse caso na linha 4: "var a=2;".
Implemente essa Eventing Function novamente.
Depois que o código for corrigido, o desenvolvedor poderá ver o comportamento e o progresso corretos à medida que o contador de sucesso for aumentando.

O manipulador OnDelete agora indica a exclusão ou a expiração

O manipulador OnDelete agora indica se um documento foi excluído ou expirou por meio de um novo parâmetro "options". Esse recurso frequentemente solicitado permite que diferentes lógicas sejam executadas, dependendo do tipo de remoção.

Exemplo:

Criar um bucket de "origem" e um bucket de "metadados" para Eventing
Implemente essa função (código abaixo)
Crie um documento no bucket de origem com quaisquer DADOS, pois só examinamos a CHAVE

KEY doc_to_delete::1

1

CHAVE doc_to_delete::1
Inspecione os registros após alguns segundos
Excluir o documento com a chave "doc_to_delete::1"
Inspecione os registros após um minuto
Cancelar a implantação dessa função

function OnDelete(meta, options) {
    if (options.expired) {
        log("doc expired:",meta.id);
        /*
        * take some action ...
        */
    } else {
        log("doc deleted:",meta.id);
        /*
        * take some other action ...
        */
    }
}

função OnDelete(meta, opções) {

se (opções.expirado) {

registro("doc expired:",meta.id);

* tomar alguma medida ...

} mais {

registro("doc deleted:",meta.id);

* Tomar alguma outra medida...

}

Explore os recursos do Couchbase Server 6.6

Blogs	Documentos e tutoriais	Páginas da web e webinars
O que há de novo no Couchbase Server 6.6	O que há de novo no Couchbase Server 6.6?	Novos recursos no Couchbase Server 6.6: análise, backup, consulta e muito mais
Aprimoramentos de eventos (temporizadores, manipuladores e estatísticas)	Notas de versão do Couchbase Server 6.6	Serviço de análise do Couchbase
Links remotos - Analise sua empresa com o Couchbase Analytics	Experimente o serviço de consultoria de índice do Couchbase	O que há de novo no Couchbase Server (página do produto)
Conjuntos de dados externos - Amplie seu alcance com o Couchbase Analytics	Configurar links remotos e S3 do Analytics usando a API REST	Comparar edições
Anunciando o Flex Index com o Couchbase	Criar conjuntos de dados externos usando a linguagem de definição de dados (DDL)
Apresentando o backup no Object Store (S3)	Configurar links remotos e S3 do Analytics usando a CLI
Importar documentos com o Web Admin Console

Referências

Documentação do Couchbase Eventing:
https://docs.couchbase.com/server/current/eventing/eventing-overview.html
Exemplos de eventos do Couchbase:
https://docs.couchbase.com/server/current/eventing/eventing-examples.html
Couchbase Server 6.6 O que há de novo:
https://docs.couchbase.com/server/6.6/introduction/whats-new.html
Blogs do Couchbase sobre eventos:
https://www.couchbase.com/blog/tag/eventing/

Gostaríamos muito de saber se você gostou dos recursos da versão 6.6 e como ela beneficiará seus negócios daqui para frente. Compartilhe seu feedback nos comentários ou na seção Couchbase fórum.

Notas de rodapé

^[1] A gravidade é determinada por: a) O número de vBuckets com um timer ativo. Portanto, se houver apenas alguns temporizadores no futuro, o problema pode não ser perceptível ou não se materializar. e b) Se um temporizador Eventing foi disparado recentemente em um vBucket (o que elimina o problema para o vBucket em questão com base em cada função). Portanto, os sistemas 6.5 com muita atividade de temporizador de curto prazo não terão esse problema, mesmo que os temporizadores estejam programados para um futuro distante. Isso não é um problema na versão 6.6.

^[2] Em uma operação cancelTimer() ou sobrescrevendo um Timer existente por referência, haverá um documento temporário no compartimento de "metadados" do Eventing que será limpo: a) na programação inicial de disparo dos Timers cancelados (ou sobrescritos) ou b) em uma não implantação da função. Esse comportamento é diferente do disparo de um Timer no horário programado, no qual todos os metadados de Eventing associados são imediatamente limpos do compartimento de "metadados" de Eventing após o disparo de um Timer.

Jon Strabala, gerente principal de produtos da Couchbase

Compartilhe este artigo

Platform

Self-Managed

Services

Capabilities

Why Couchbase?

Migrate to Capella

By Use Case

By Industry

By Application Need

Popular Docs

By Developer Role

Quickstart

Resource Center

About

Partnerships

Our Services

Partners: Register a Deal

Ready to register a deal with Couchbase?

Marriott

Aprimoramentos em eventos: Cronômetros, manipuladores e estatísticas

Pré-requisitos

Os cronômetros de eventos agora podem ser cancelados

Exemplo:

Os temporizadores de eventos recorrentes agora são totalmente compatíveis

Exemplo:

Os cronômetros podem ser criados para dias/semanas/anos futuros

Exemplo:

As estatísticas de eventos agora estão localizadas juntamente com os controles de ciclo de vida

Exemplo:

O manipulador OnDelete agora indica a exclusão ou a expiração

Exemplo:

Explore os recursos do Couchbase Server 6.6

Referências

Notas de rodapé

Receba atualizações do blog do Couchbase em sua caixa de entrada

Autor

Postado por Jon Strabala, gerente principal de produtos da Couchbase

Deixe um comentário Cancelar resposta

Pronto para começar a usar o Couchbase Capella?

Iniciar a construção

Use o Capella gratuitamente

Entre em contato