Mensagens do Pub/Sub em cache: uma visão geral
Esse paradigma de mensagens Publish/Subscribe (Pub/Sub) fornece um canal intermediário (chamado de tópico) para trocar mensagens entre vários aplicativos sem qualquer conhecimento do remetente (editor) e do destinatário (assinante). Um aplicativo publicador envia mensagens para um aplicativo assinante por meio de tópicos.
Como todos os modelos Pub/Sub exigem um canal para comunicação, NCache atua como um meio para tópicos para que o publicador publique a mensagem no tópico. Os assinantes recebem a mensagem por meio do tópico como uma notificação. Usando NCache como um meio para tópicos garante um baixo acoplamento dentro do modelo e permite maior abstração, fornecendo benefícios adicionais para os tópicos distribuídos.
Além de um cache distribuído, NCache também oferece um dedicado Cache de mensagens do Pub/Sub.
importante
Recomendamos um cache Pub/Sub dedicado pelos seguintes motivos:
Despejo: Se o cache contiver mensagens e itens de cache, o despejo frequente de itens de cache também pode remover as mensagens antes de encaminhá-las ao assinante.
Transferência de Estado: A transferência de estado adiciona um custo a cada operação de item de cache. Como as mensagens são frequentemente publicadas, retransmitidas e expiradas, essa atividade recorrente pode ser cara porque aciona a transferência de estado.
Por que as mensagens do Pub/Sub são importantes
Eventos em tempo real requerem compartilhamento de notificação entre diferentes aplicativos em arquiteturas distribuídas orientadas a eventos. Os padrões Pub/Sub permitem que os editores compartilhem eventos com assinantes para que qualquer processamento desejado ocorra na ocorrência de um evento de interesse.
Por exemplo, um grupo de assinantes pode estar interessado em informações sobre detalhes de remessa de pedidos para que possam processá-las e rastrear a entrega do pedido. Conseqüentemente, eles se inscreverão em um tópico que retransmite mensagens para detalhes do pedido. Assim que o editor publicar uma mensagem sobre o tema, os assinantes serão notificados e receberão a mensagem contendo os detalhes do pedido para posterior processamento por sua parte.
Componentes do Pub/Sub
Os componentes básicos do NCache O Modelo de Assinante do Editor está listado abaixo e discutido em detalhes posteriormente:
Tópico: Um lugar onde as mensagens são publicadas.
Fabricante : Um aplicativo (aplicativo da Web, aplicativos de desktop, microsserviços) que publica mensagens em tópicos/tópicos
Assinante: Uma aplicação interessada em receber mensagens de temas/tópicos.
Inscrição: Uma entidade de interesse criada para um assinante receber mensagens pretendidas.
Mensagem: O objeto de dados real que o editor envia e os assinantes recebem por meio do tópico.
Tema
O editor publica mensagens sobre o tópico. Os assinantes se inscrevem no tópico para receber a mensagem. Este tópico existe de forma distribuída em NCache. Portanto, sua criação ocorre em todos os nós do cluster. Ele contém o armazenamento de mensagens, que armazena os objetos de dados reais que o publicador publica em uma fila. Ele também mantém internamente uma lista de todos os assinantes e uma lista de editores.
A ITopic/Topic
interface facilita criação de tópico, obtenção de tópico e exclusão de tópico. Você também pode excluir um tópico de forma assíncrona para evitar a espera para que um tópico seja excluído.
Note
A natureza distribuída de tópicos e mensagens subjacentes aumenta a escalabilidade.
Uma vez que uma mensagem é publicada no tópico, ela dispara um evento, que o tópico retransmite aos assinantes com base na preferência do usuário. opção de entrega de mensagem para que eles possam receber a mensagem conforme necessário. A figura a seguir ilustra o papel de um tópico como canal intermediário para editores e assinantes:
Note
No caso de desconexão temporária do assinante e, em seguida, reconexão automática, todas as informações relacionadas a um tópico, como assinaturas e notificações de eventos de falha, são registradas novamente no tópico sem qualquer interrupção por parte do assinante.
Prioridade do tópico
NCache apresenta prioridade em nível de tópico que ajuda você a priorizar os tópicos de prioridade mais baixa e alta com base em sua importância. Você pode criar Tópicos com maior prioridade se eles precisarem publicar mensagens críticas. Portanto, essas mensagens são entregues primeiro. Da mesma forma, você pode criar tópicos com prioridade mais baixa se eles publicarem mensagens sem importância. O cache removerá essas mensagens primeiro.
importante
A prioridade de um tópico pode ser especificada apenas no momento da criação do tópico e não pode ser modificada posteriormente.
Você pode simplesmente definir o prioridade no nível do tópico no momento da criação do tópico para priorizar a entrega de mensagens críticas.
Notificação de exclusão de tópico
Todas as mensagens e metainformações relacionadas do cache são excluídas após a exclusão do tópico. Conseqüentemente, o assinante e o editor recebem notificações dessa exclusão pelos seguintes motivos:
- Os assinantes podem estar aguardando mensagens recebidas do tópico registrado. Depois que o tópico for excluído, os assinantes poderão lidar com sua execução adequadamente por meio de notificação de eventos e evitar um estado de espera infinito.
- O editor pode evitar o envio de mensagens para um tópico inexistente e lidar adequadamente com quaisquer mensagens pendentes e execuções futuras.
Para receber notificação de exclusão de tópico, seu aplicativo registra para o evento OnTopicDeleted.
Publicar mensagens em um tópico
Um editor pode publicar mensagens em um tópico especificando um nome de tópico. As mensagens podem ser publicadas de forma assíncrona e em massa para melhorar o desempenho do aplicativo. Um cache particionado distribui mensagens pelo cluster. Para roteamento de mensagens, cada mensagem possui um ID exclusivo chamado MessageID
no final do editor, e o código hash de MessageID
determina o nó do cluster para armazenar a mensagem.
Note
NCache permite publicar uma grande quantidade de mensagens em uma única chamada para melhorar o desempenho e o uso de memória.
NCache permite que um editor use as seguintes propriedades ao publicar mensagens.
Opção de entrega de mensagens: Um editor pode decidir se uma mensagem será entregue a um único assinante ou transmitida a todos os assinantes no momento da publicação usando opção de entrega de mensagem.
Expiração da mensagem: A editora pode definir a expiração de uma mensagem para controlar a vida útil de uma mensagem no cache. Abordamos a expiração com mais detalhes no Mensagens seção.
Notificação de falha de entrega de mensagem: Um editor pode registrar-se para MessageDeliveryFailure para ser notificado se uma mensagem específica não foi entregue. Esses cenários de falha de entrega são elaborados com mais detalhes no Atribuição de mensagens e entrega para assinatura seção.
importante
A notificação de falha de entrega de mensagem é apenas para as mensagens com expiração.
- Notificação de exclusão de tópico: Um editor pode se registrar para notificação de exclusão de tópico para evitar a publicação indevida de mensagens correspondentes após a exclusão do tópico.
Inscrever-se em um tópico
Um aplicativo de assinante pode subscrever mensagens de tópico registrando-se em um tópico de interesse por meio de uma assinatura. No Pub/Sub, uma assinatura representa o interesse de um(s) assinante(s) exibido(s) em um tópico específico.
Note
Caso um novo nó seja adicionado ao cluster de cache e a transferência de estado seja acionada, todas as assinaturas junto com as mensagens e os dados de cache serão replicados para o novo nó.
NCache permite assinar um tópico fornecendo um nome de tópico ou um padrão. Para mais detalhes, consulte Métodos de assinatura. Além disso, você também pode definir modo de entrega de mensagem como síncrono ou assíncrono ao criar uma assinatura.
NCache fornece vários tipos de assinaturas do Pub/Sub que são discutidas a seguir.
Assinatura e seus tipos
Assinaturas em NCache podem ser classificados nos seguintes tipos:
Durável
Note
Uma assinatura durável é uma assinatura nomeada.
Em um artigo do assinatura durável, o cache garante que o assinante não perca nenhuma mensagem em caso de desconexão devido ao desligamento da aplicação/máquina, reinicialização da aplicação ou falha na rede. Conseqüentemente, assinaturas duráveis não sofrem devido à desconexão e reconexão do assinante.
Note
As assinaturas duráveis não são excluídas, a menos que o assinante cancele a assinatura corretamente.
Se um assinante for desconectado, as mensagens destinadas a esse assinante serão armazenadas em um servidor até que o assinante volte a se conectar ou as mensagens expirem. Assinaturas duráveis não são excluídas automaticamente na desconexão do assinante, a menos que o assinante tenha cancelado a assinatura corretamente.
Uma assinatura durável é classificada ainda como:
Compartilhado: Uma assinatura compartilhada e durável significa que vários assinantes compartilham uma assinatura nomeada. As mensagens atribuídas a uma assinatura compartilhada são, então, balanceadas por carga entre os assinantes em um modo round-robin. Mesmo que algum assinante saia da rede, as mensagens continuam sendo entregues aos assinantes ativos. Portanto, se um assinante sair de maneira normal ou abrupta após uma atribuição, suas mensagens atribuídas serão reatribuídas a outros assinantes ativos.
importante
Uma assinatura compartilhada é suportada apenas por uma assinatura durável.
Em uma assinatura compartilhada, a assinatura permanecerá no tópico e não poderá ser cancelada até que todos os assinantes tenham cancelado a assinatura. Isso significa que, enquanto houver um único assinante ativo, a assinatura permanecerá ativa.
- Exclusivo: Uma assinatura durável exclusiva significa que há apenas um assinante ativo registrado em uma assinatura por vez. Se um assinante cancelar a assinatura normalmente, a assinatura exclusiva poderá ser atribuída a um novo assinante. Se um assinante sair abruptamente, a nova solicitação de assinatura será aceita após aguardar um tempo ocioso. As mensagens atribuídas sempre permanecem lá, mesmo que não haja assinante.
Não durável
Em um artigo do assinatura não durável, o assinante só recebe as mensagens a ele destinadas enquanto permanecer conectado. Se o assinante sair da rede, não receberá nenhuma mensagem publicada durante seu período de desconexão. Uma assinatura não durável é exclusiva por padrão.
importante
Os assinantes perderão mensagens se o assinante reiniciar.
Além disso, as assinaturas não duráveis são excluídas automaticamente quando o assinante sai da rede. Isso significa que se esse assinante se conectar novamente ou estabelecer a conexão novamente, será considerada uma nova assinatura.
Expiração da Assinatura Durável
Você pode definir a expiração de uma assinatura durável. Por exemplo, se não houver assinante ativo por um tempo significativo. Aqui, as assinaturas expiram após um período específico de inatividade. Quando uma assinatura durável expira, as mensagens atribuídas a essa assinatura são reatribuídas com base no DeliveryOption
dessas mensagens.
Note
Cada vez que o assinante pesquisa ou realiza qualquer outra atividade, o tempo de expiração da assinatura é redefinido.
Lidando com assinaturas inativas
Note
Apenas assinaturas não duráveis são marcadas como inativas e isso não se aplica a assinaturas duráveis.
Caso não haja assinante ativo contra uma assinatura após aguardar um determinado período de inatividade, a assinatura é considerada vencida. Se um assinante voltar a se conectar após a desconexão durante o período inativo, ele poderá receber suas mensagens atribuídas.
importante
Assinaturas inativas devem ser tratadas para evitar sobrecarga de memória no lado do servidor.
Após aguardar o período inativo, a assinatura expira e suas mensagens atribuídas serão reatribuídas a outras assinaturas. A reatribuição de mensagens depende da opção de entrega das mensagens.
Se a mensagem atribuída à assinatura A tiver a opção de entrega definida como ALL e já estiver atribuída a outra assinatura B antes da assinatura A expirar, a reatribuição não será necessária.
Se a mensagem atribuída a uma assinatura tiver uma opção de entrega definida como ANY e a assinatura expirar, as mensagens atribuídas serão sempre reatribuídas a qualquer outra assinatura.
Mensagem
Uma mensagem contém o objeto de dados real que é enviado pelo editor e entregue aos assinantes por meio do tópico. Assim que o editor publica a mensagem sobre o tema, os assinantes cadastrados são notificados de que foi publicada uma mensagem sobre seu interesse. No caso de múltiplas mensagens, elas são armazenadas em sequência dentro da fila de um determinado tópico.
Note
A mesma mensagem pode ser atribuída a vários tópicos. Isso é identificado exclusivamente por meio de um ID gerado automaticamente.
Aqui, discutiremos ainda mais a atribuição de mensagens à assinatura, a entrega de mensagens e o mecanismo de confirmação.
Atribuição de mensagens e entrega para assinatura
Inicialmente, as mensagens não são atribuídas no lado do servidor. Todas as assinaturas recebem mensagens de acordo com o DeliveryOption
. Depois que ocorre uma atribuição de assinatura, o assinante recebe uma notificação. Em seguida, o assinante implementa um mecanismo de pesquisa para obter várias mensagens em massa - para reduzir a sobrecarga do lado do servidor. Após receber as mensagens, o assinante envia a confirmação, e as mensagens são consideradas entregues.
Note
As mensagens são armazenadas no tópico, caso não haja assinante para recebê-las. As mensagens são atribuídas e entregues ao primeiro assinante assim que ele se inscreve no tópico.
Opção de entrega de mensagens
Um editor precisa especifique a opção de entrega de mensagem decidir se a mensagem será entregue a um único assinante ou transmitida a todos os assinantes no momento da publicação. É importante observar que a definição de entrega bem-sucedida depende da opção de entrega especificada.
As duas opções de entrega e os critérios de entrega bem-sucedidos correspondentes são discutidos da seguinte forma:
Todos: Todos os assinantes registrados recebem mensagens. Uma mensagem é excluída quando todos os assinantes a reconhecem.
Qualquer: Qualquer assinante registrado recebe as mensagens. Se o assinante atribuído não enviar a confirmação, as mensagens serão reatribuídas ao próximo assinante. Se enviarem confirmação, as mensagens serão consideradas entregues com sucesso.
Note
Se uma mensagem for entregue com sucesso de acordo com a opção de entrega especificada, ela será removida do cache.
Armazenamento e Distribuição de Mensagens
A seguir estão os aspectos importantes do armazenamento e distribuição de mensagens no cache:
As mensagens são distribuídas entre nós com base em topologias.
Para as topologias Partition-Replica e Partitioned, é usada a distribuição baseada em hash.
Para topologia replicada, as mensagens são replicadas para todos os nós do cache clusterizado. No entanto, o nó coordenador é responsável pela manipulação da mensagem.
Para a topologia Mirror, as mensagens são publicadas no nó ativo e, em seguida, replicadas no nó passivo de acordo.
Se o armazenamento de mensagens estiver próximo do despejo, um evento será registrado indicando um armazenamento de mensagens completo e o início do despejo.
As mensagens têm uma sobrecarga na memória cache. Portanto, o tamanho da mensagem deve ser considerado ao calcular o tamanho do cache.
Comportamento da mensagem
Aqui discutimos o comportamento esperado das mensagens nos seguintes casos:
Em cache limpo: As mensagens são removidas junto com os itens do cache assim que o cache é limpo.
Ao reiniciar o cache: Semelhante à limpeza do cache, o conteúdo do cache é limpo quando o cache é reiniciado. Isso também inclui todos os tópicos e as mensagens contidas neles.
Despejo: If a remoção está habilitada em um cache do Pub/Sub, os dados serão removidos primeiro e, em seguida, as mensagens serão removidas.
Criptografia e compactação: If criptografia e compressão é configurado no nível do cache, ele também se aplica à carga útil da mensagem do tópico.
Transferência de estado: No caso de transferência de estado, quando as mensagens se movem para outro nó no cluster, o nó onde a mensagem é finalmente armazenada é responsável pela entrega.
Notificação de falha de entrega de mensagem
importante
Os assinantes recebem uma notificação de falha na entrega quando uma mensagem expirada expira antes da entrega a qualquer um deles.
Caso uma mensagem não seja atribuída ou entregue a algum dos assinantes, é considerada uma falha. Pode acontecer quando o assinante não existe ou está inativo devido a uma falha na rede. Nesse cenário, um editor pode registrar notificação de falha de entrega de mensagem. É importante observar que a notificação de falha de entrega é apenas para mensagens com expiração. A entrega de uma mensagem é considerada falha quando uma mensagem expira antes da entrega a qualquer um dos assinantes
Note
Se houver vários editores em um tópico, a notificação de falha será entregue a qualquer um dos editores ativos que se registraram para a notificação de falha.
Expiração da mensagem
Semelhante aos itens de cache, um editor pode definir expiração para mensagens. As mensagens expirarão do cache assim que o intervalo de expiração tiver passado e usarão o mesmo mecanismo de intervalo de limpeza.
A expiração de uma mensagem determina o tempo que ela persiste no cache. Independentemente da entrega, se uma mensagem não for entregue, ela será removida após o tempo de expiração. Se uma mensagem for entregue com sucesso antes da expiração, ela será removida do cache sem aguardar o tempo de expiração.
Mensagens ordenadas
NCache agora suporta mensagens ordenadas onde a sequência das mensagens é mantida no lado do cliente. Um editor pode publicar mensagens ordenadas especificando um nome de sequência para um bloco de mensagens. Em seguida, as mensagens ordenadas são entregues aos assinantes na mesma ordem em que foram publicadas. A sequência de sequência deve ser a mesma para uma cadeia de mensagens ordenadas. Usando a string de sequência, todas as mensagens residem no mesmo nó usando o Afinidade de local mecanismo.
Note
Modo de entrega síncrona pode ser usado para mensagens ordenadas.
A seguir estão as características importantes das mensagens ordenadas:
As mensagens de um publicador com a mesma sequência residem em um único nó de cache.
Se o
DeliveryOption
é definido como Qualquer, todas as mensagens ordenadas da mesma sequência são entregues ao mesmo assinante. Caso o assinante específico perca a conexão ou fique indisponível, um novo assinante é reatribuído para esse fim. No entanto, se oDeliveryOption
for definido como Todos, todas as mensagens ordenadas da mesma sequência serão entregues a todos os assinantes.No caso de transferência de estado, as mensagens ordenadas podem perder sua sequência e serem publicadas sem manter a ordem.
As mensagens ordenadas só podem ser publicadas usando o modo de sincronização na API de publicação. Não há suporte para chamadas de API em massa e assíncronas.
do Paciente
NCache oferece a capacidade de monitorar as estatísticas do Pub/Sub Topic e observar vários contadores de desempenho a respeito disso. A atividade e o status do tópico Pub/Sub podem ser monitorados por meio do Contadores de PerfMon do Windows e Ferramentas de linha de comando.
Confiabilidade e alta disponibilidade
NCache implementa o mecanismo de reconhecimento para entrega de mensagens. As mensagens são mantidas na memória até que sejam entregues com sucesso com base no pelo menos uma vez entrega critério. Por isso, NCache garante a confiabilidade de entrega de mensagens para Pub/Sub Messaging em arquiteturas distribuídas.
Além disso, a tolerância a falhas de até um nó em Topologia de réplica de partição torna o armazenamento de mensagens do Pub/Sub altamente disponível. Se um nó sair do cluster por qualquer motivo, a réplica terá o backup da mensagem.
Nesta secção
Tópicos do Pub/Sub
Explica como criar, obter e excluir tópicos do modelo Pub/Sub em NCache.
Publicar mensagens em um tópico
Fornece código de exemplo que cria um tópico e publica mensagens nele.
Inscrever-se em um tópico
Fornece código de exemplo para se inscrever em um tópico e receber mensagens de interesse.
Eventos do Pub/Sub
Explica os eventos do Pub/Sub para notificar o editor e o assinante sobre vários eventos que ocorrem no cache e nos aplicativos.
Como monitorar tópicos do Pub/Sub
Descreve as maneiras pelas quais as estatísticas do Pub/Sub podem ser monitoradas NCache Monitor, PerfMon e ferramentas de linha de comando.