Mensagens .NET Pub/Sub escalonáveis usando NCache
Webinar gravado
Por Ron Hussain e Edward Bator
Neste webinar, você aprenderá como usar mensagens poderosas do Pub/Sub para aplicativos .NET de alto tráfego e superar gargalos de desempenho. NCache é um cache distribuído escalável para .NET que fornece um conjunto avançado de recursos de mensagens do Pub/Sub.
Um de nossos arquitetos de soluções sênior orientará você por todos os recursos do Pub/Sub e seus casos de uso e mostrará como incorporá-los ao seu aplicativo .NET.
Este webinar cobre:
- Introdução às mensagens do Pub/Sub em geral
- Compreensão NCache Recursos do Pub/Sub
- Como configurar o Pub/Sub em NCache
- Prático usando Pub/Sub em seus aplicativos .NET
- Demonstração de mensagens do Pub/Sub por meio de NCache
- NCache alta disponibilidade e escalabilidade para Pub/Sub
O tópico de hoje será sobre mensagens em aplicativos .NET e usaremos NCache como um produto de exemplo. O foco principal será Mensagens do Pub/Sub. O modelo de assinante do editor. Por que é importante? Onde exatamente você o usa e por que NCache é um ajuste melhor em comparação com outras opções que você vê para o seu .NET e .NET core formulários? Então, temos muito a cobrir. Vamos começar rapidamente com isso e pessoal, se houver alguma dúvida, como Eddie sugeriu, use a guia de perguntas e respostas e faça quantas perguntas precisar. Então, vamos começar rapidamente.
O que é Pub/Sub?
Os primeiros slides são focados na parte de introdução. O que é Pub/Sub? Tenho certeza de que todo mundo sabe, mas apenas por uma questão de integridade, vou passar por cima do paradigma de mensagens do Pub/Sub.
Portanto, é um modelo de assinante do editor. Tem basicamente três componentes. Temos editor, que envia mensagens, transmite essas mensagens para o canal de comunicação. Então temos assinantes, que pode ser outro aplicativo, que está recebendo essas mensagens e então temos uma comunicação, bus um broker, um serviço, um processo dentro de um editor e um componente intermediário de assinante que ajuda a retransmitir essas mensagens dos editores para os assinantes. Em alguns casos, você pode armazenar mensagens, processar mensagens. Isso pode ser uma base de tempo, isso pode ser baseado em seus destinatários.
Como funciona o Pub/Sub?
Portanto, existem diferentes opções que você pode ajustar quando planeja usá-lo. Mas, em geral, existem algumas diretrizes, algumas regras que são comuns à plataforma de mensagens típica do Pub/Sub. É frouxamente acoplado. Publicador e assinante, eles podem trabalhar de forma independente sem depender um do outro. Eles também podem estar completamente inconscientes um do outro e o sistema deve funcionar sem problemas. A idéia toda é que, o editor simplesmente envia mensagens para o canal de comunicação e, em seguida, o canal de comunicação retransmite essas mensagens e os assinantes recebem essas mensagens. O editor não precisa saber sobre identidade ou informações sobre os aplicativos do assinante e, da mesma forma, os assinantes não precisam saber quais são as informações do editor. Eles podem apenas lidar com as mensagens, esse é o principal ponto de interesse e a ideia é que cada componente funcione de forma independente. Os editores não têm nenhuma dependência do canal de comunicação ou dos assinantes e vice-versa também.
A maioria dos modelos de assinantes do editor, os modelos Pub/Sub permitem que você tenha separação de preocupações, onde você pode ter tópicos ou canais ou fluxos. Estes são usados para separar as mensagens. Então, mensagens de natureza semelhante que servem a um único propósito simples, elas podem ser colocadas em um tópico específico e você pode ter vários tópicos, vários fluxos, vários canais, dentro de um paradigma de mensagens Pub/Sub e você pode receber essas mensagens. Os editores se conectam a tópicos e, em seguida, transmitem essas mensagens para um determinado tópico e, em seguida, os assinantes também podem se conectar a um tópico no canal de comunicação e receber essas mensagens e funciona perfeitamente, usando essa abordagem baseada em tópicos.
Aqui está um diagrama, que destaca os detalhes arquitetônicos.
Temos um tópico, esse é o canal de comunicação, esse é o aplicativo do editor que temos aplicativos do assinante. Pode haver vários editores. Da mesma forma, pode haver vários assinantes e, no canal de comunicação, você também pode ter vários tópicos. Por exemplo, você pode ter um tópico que trata das informações de processamento de pedidos. Pode haver outro tópico que esteja lidando com informações do cliente e assim por diante. Então, com base no propósito da mensagem, com base no tipo da mensagem, isso é os requisitos de carga, você pode distribuir as mensagens em tópicos e então esse Assinante é conectado ao Tópico A, onde o Assinante 2 está conectado ao Tópico A como assim como para B e então o Assinante 3 está conectado apenas ao Tópico B. Assim, o publicador envia essas mensagens e os assinantes que estão conectados aos respectivos tópicos, eles recebem essas mensagens sem problemas.
Casos de uso comuns do Pub/Sub
Tudo bem, então, seguindo em frente. Quais são os casos de uso comuns do Pub/Sub? Está no mercado há algum tempo, todo esse paradigma de mensagens do Pub/Sub e também tem sido usado em muitos aplicativos de alto tráfego. Tem muita tração.
Portanto, temos sistemas de back-end, principalmente, que podem se beneficiar das mensagens Pub/Sub que lidam com processamento de dados assíncrono. Pode ser alguns fluxos de trabalho, algumas tarefas em segundo plano, alguns procedimentos que você precisa, alguns cálculos que você está fazendo. Portanto, os sistemas de back-end usam principalmente essa plataforma de mensagens.
Aplicativos de bate-papo, isso pode ser a indústria de jogos, que pode estar lidando com milhões de usuários, milhões de mensagens, sendo transmitidas para usuários. Por exemplo, um de nossos clientes estava usando o Pub/Sub para compartilhar informações quando havia torneios diferentes em seu site de jogos. Então, eles estavam compartilhando muitas informações relacionadas a torneios entre os usuários.
Setor financeiro, comércio eletrônico, reservas qualquer, qualquer coisa que seja voltada para o público e eles precisem fazer algum processamento de pedidos de back-end, algum processamento de reservas ou, em geral, fornecer alguma interação entre diferentes componentes do aplicativo.
Automação e plantas fabris. Mas, normalmente, poderia ser o caso de uso mais importante, seria um caso de uso técnico, seria o microsserviços caso de uso. Onde temos diferentes microsserviços, que representam um grande aplicativo, mas esses componentes atendem a um único propósito independente. É muito difícil implementar a camada de comunicação para esses microsserviços. Você teria que ter um canal de comunicação separado atuando novamente como um microsserviço, que também não tem capacidade para outros microsserviços e essa é a ideia de onde você gostaria de ter uma camada de microsserviços independente, as instâncias de microsserviços são independentes umas das outras. Uma instância está fazendo um único propósito e não depende de outra e vice-versa. Então, para esses aplicativos de microsserviços, onde temos microsserviços dentro do aplicativo, implementar o canal de comunicação é muito difícil e complica e tem muita dependência nele, retarda as coisas também. Então, faz muito sentido usar uma plataforma de mensagens Pub/Sub, onde o canal de comunicação é gerenciado pela própria plataforma e então os microsserviços atuam como publishers e assinantes e então compartilham informações entre si. Portanto, isso deve ajudar a aliviar a carga, bem como os problemas de arquitetura que você normalmente vê com o Pub/Sub, os aplicativos de plataformas de microsserviços que usam seu próprio canal de comunicação. Eles devem usar o Pub/Sub para ajudar a aliviar isso.
O problema: problemas de escalabilidade com plataformas Pub/Sub
Existem muitas plataformas Pub/Sub, mas normalmente há gargalos e é isso que abordaremos a seguir. Temos plataformas de mensagens tradicionais típicas. Eles são muito bons em termos do lado arquitetônico das coisas. Você envia uma mensagem, essa mensagem será transmitida para todos os assinantes, tudo funciona bem. Mas normalmente, isso funciona muito bem sob carga baixa. Quando você tem menos usuários, carrega, bem como menos número de solicitações ou menos número de mensagens sendo transmitidas para o seu aplicativo. Quanto à carga, quando a carga do aplicativo cresce, por exemplo, há muitos usuários, muito processamento acontecendo e, em seguida, há muita carga de mensagens dos editores para os assinantes, normalmente, vimos que nossas mensagens tradicionais plataforma, como banco de dados, tornam-se um gargalo. Aqui está um diagrama que ilustra isso.
Temos aplicativos de editora, assinante. Pode ser uma aplicação web, algum .NET ou .NET Core Processo interno. Alguns fluxos de trabalho. Pode ser qualquer tipo de .NET ou .NET Core aplicativo ou mesmo aplicativo Java, conectado a uma plataforma de massa tradicional, como banco de dados ou fila de mensagens. Em primeiro lugar, eles não são tão rápidos quanto o armazenamento na memória, certo. Então, isso é algo que você precisa trabalhar. Mas o principal problema é que quando sua carga de mensagens cresce, quando você tem muitos usuários, as coisas começam a desacelerar porque sua carga de mensagens pode sufocar a própria plataforma porque é uma única fonte. Ele não tem a capacidade de adicionar mais e mais servidores para ajudar a acomodar o aumento da carga que seus aplicativos estão colocando.
Então, esse é o principal problema e qual seria o impacto do usuário final? Por exemplo, uma mensagem não foi retransmitida em tempo hábil, levou muito tempo e isso contribuiu para a latência no lado do aplicativo. Por exemplo, o usuário final estava aguardando a conclusão de um processamento e esse processamento dependia de uma plataforma de modelo Pub/Sub e a plataforma era lenta. Portanto, isso também afetaria a solicitação do usuário final e você perderá negócios se houver, digamos, um fator de milissegundo ou alguns segundos de atraso, então isso pode afetar o usuário final e, por sua vez, afetará seus negócios, pois bem e isso é muito difícil de gerenciar, porque não tem como, você pode mudar qualquer coisa dentro da arquitetura do aplicativo para ajudar a resolver esse problema. Tem um problema, que está fora da arquitetura da aplicação com a camada de banco de dados, né. Então, como lidar com esse cenário específico?
A solução: cache distribuído na memória
A solução é muito simples, você usa uma plataforma de mensagens Pub/Sub na memória que é distribuída na natureza, como NCache. É super-rápido, é isso que o diferencia das plataformas de mensagens tradicionais. Pode ter menos recursos, eu admitiria isso. Desde a, NCacheO foco principal da empresa é ter cache de objetos, cache de dados, cache de sessão, para processamento de dados e armazenamento e melhoria de desempenho. Pub/Sub é um dos recursos. Existem produtos como filas de mensagens, por exemplo, serviço de mensagens Java, fila MSM, esses são mais elaborados. Mas o que faz NCache além desses produtos é que NCache é a memória. Portanto, é super-rápido para iniciar.
Então, se você tiver, digamos, cinco usuários e tiver menos carga de mensagens, esses usuários terão uma experiência super rápida em comparação com as plataformas de mensagens tradicionais. Então, está na memória. Então, isso é uma grande vantagem e temos vários servidores hospedando essa plataforma de mensagens. Você pode ver um servidor de equipe unido em uma capacidade lógica que formula a plataforma de bagunça e tem um mecanismo Pub/Sub implementado em cima dela, certo. Portanto, seus aplicativos de editor podem se conectar a esse cache e, dentro do cache, você pode ter tópicos separados. Eu vou te mostrar como isso funciona, depois os assinantes, que também podem ser editores, eles também estão conectados ao mesmo canal de comunicação que é oferecido por NCache como na forma de cache de distribuição e, em seguida, esse canal de comunicação oferece todas as informações relacionadas à comunicação para esses editores e assinantes. Isso pode retransmitir mensagens e isso pode ter todos esses tipos diferentes de explorações, algum tipo diferente de persistência e recursos diferentes que destacarei mais adiante.
O legal dessa plataforma é que você pode adicionar quantos servidores precisar e não precisa se preocupar com a possibilidade de sua plataforma ser um gargalo de escalabilidade, como visto aqui. Portanto, não é mais um gargalo de escalabilidade. Você pode adicionar mais servidores na hora e de dois para três servidores você aumenta um fator à direita e de três para quatro servidores, você quase dobra a capacidade de quantas solicitações você pode atender, quantas mensagens você pode manipular por segundo e sem comprometer o desempenho, isso proporcionaria melhorias de escalabilidade linear para a entrega de mensagens e isso ajudaria muito no lado do aplicativo. Os usuários finais se beneficiariam muito, onde veriam um tempo de resposta mais rápido, baixa latência e alta taxa de transferência para seu aplicativo e usuários.
Alguma dúvida até agora? Isso abrange por que você deve considerar o uso NCache em comparação com o tradicional e quais são os problemas com a plataforma de mensagens Pub/Sub tradicional. Alguma dúvida até agora? Os próximos slides são focados em detalhes arquitetônicos de NCache Mensagens do Pub/Sub e, em seguida, falaremos sobre os diferentes recursos, que estão sendo oferecidos como parte disso. Oi Rony, temos uma pergunta. Quais são as opções de monitoramento disponíveis? OK, eu acho que é em relação a NCache, sim, essa é outra vantagem que eu tenho um segmento no final alinhado apenas para isso. Mas acho que seria muito bom se eu esperasse até essa parte e apresentasse a demonstração prática do produto e, como parte disso, também mostrarei os recursos de monitoramento. Então, eu vou revisitar esta questão, uma vez que eu estiver nessa parte. Espero que esteja tudo bem.
NCache Mensagens do Pub/Sub
Bem, NCache Mensagens do Pub/Sub. É muito parecido com o que você viu aqui. É uma plataforma de mensagens Pub/Sub tradicional. Aqui está o detalhamento da arquitetura. Temos canal de mensagens oferecido por NCache e temos uma equipe de servidores aqui e dentro desse canal de mensagens temos o Tópico 1, o Tópico 2 e depois temos o editor que pode ser qualquer .NET, .NET Core aplicação e, em seguida, temos assinantes que são novamente qualquer .NET ou .NET Core, até mesmo aplicativo Java, que está conectado a ele.
Um cache dedicado pode ser formulado para isso e, em seguida, a mensagem é algo que é retransmitido do canal de comunicação usando o mecanismo típico de Pub/Sub, onde uma mensagem é enviada do editor para os assinantes. Aqui está um trecho de código simples.
Order payload = new Order();
payload.OrderID = 10248;
payload.OrderDate = new DateTime(2015, 07, 04);
payload.ShipName = "Vins et alcools Chevalier";
...
Cache cache = NCache.InitializeCache("PubSubCache");
ITopic orderTopic = cache.MessagingService.CreateTopic("orderTopic");
Message orderMessage = new Message(payload);
// Publish message to all registered subscribers
// Register delivery failure notification
orderTopic.Publish(orderMessage, DeliveryOption.All, true);Só para você ter uma ideia de que você constrói sua carga útil, que é o objeto de interesse, inicialize o cache, ou seja, conecte-se a ele, nomeie-o, você pode criar um cluster de cache com servidores diferentes, você cria um tópico ou se conecta a um tópico existente. O tópico é um canal, um meio separado para mensagens semelhantes e então você constrói uma mensagem e depois publica e pronto. É assim que é simples para o caso de uso básico.
No lado do assinante, novamente você precisa se conectar a um tópico ou criar um novo tópico e se tornar um assinante usando o método create subscription e, em seguida, há um retorno de chamada que é invocado toda vez que uma mensagem é recebida e esta é uma chamada assíncrona -costas.
Cache cache = NCache.InitializeCache("PubSubCache");
ITopic productTopic = cache.MessagingService.GetTopic(topicName);
ITopicSubscription prodSubscriber = prodTopic.CreateSubscription(MessageReceived);
private void MessageReceived(object sender, MessageEventArgs args)
{
// Perform operations
}Uma demonstração prática
Devo dar-lhe rapidamente a demonstração do produto e então acho que seria muito mais fácil de entender depois de fazer a demonstração. Eu iria em frente e, como parte disso, também responderia às opções de monitoramento. Tudo bem, então, eu iria rapidamente em frente e mostrar-lhe o NCache gerenciador, que vem instalado com ele.
Criar um cache
Vou criar um novo cache.
Vamos nomeá-lo, PubSubCache e vou anexar o Windows Win no final. Todos os caches precisam ser nomeados. Você pode nomear seu cache Pub/Sub, algo que seja significativo para seu aplicativo. Você pode criar um cache, NCache permite que você crie um cache em ambiente Windows, servidores Windows, bem como em servidores Linux e também temos versão mono Windows também, que também está disponível. Então, com o Linux você precisa usar .NET Core e no Windows você pode usar .NET assim como .NET Core lançamentos de NCache. Então, vou continuar com os servidores Windows. Escolha o cache de réplica de partição porque quero ter vários servidores contribuindo para a capacidade de manipulação de solicitações.
Portanto, Partitioned e Partitioned Replica são opções muito boas. O Partitioned Cache permite particionar dados em vários servidores, enquanto a Partitioned Replica é semelhante ao Partitioned, mas também possui backups. Então, depende inteiramente de você. Se você quer que as mensagens sejam importantes por natureza, se de um servidor cair, você não quer perder as mensagens que ainda estão no canal de comunicação, então você pode usar a Réplica Particionada caso contrário, o Cache Particionado é mais excêntrico .
Existem duas outras topologias, mas essas são para configurações menores e nosso NCache webinar de arquitetura cobre todos os detalhes em torno dessas topologias de forma muito eficaz. Portanto, eu recomendaria que você os visitasse, revise esse webinar se precisar saber mais sobre essas topologias. Vou manter tudo simples. Escolha Async como uma opção de replicação.
Isso é entre a partição ativa e o backup em outro servidor e aqui eu especifico a equipe de servidores que vão hospedar meu cluster de cache. Posso ter dois para começar e posso adicionar mais servidores a qualquer momento, conforme discutido anteriormente. Esta é uma porta TCP a propósito. Toda comunicação entre NCache é conduzido através de TCP/IP e tamanho é algo que é o tamanho por servidor. Portanto, com base na carga de mensagens, com base na carga de dados, recomendamos que você configure um tamanho relevante para seus aplicativos. Vou manter tudo simples. Inicie este cache no início automático, para que cada vez que o servidor for reinicializado, o cache seja iniciado automaticamente e pronto.
É assim que é simples configurar esse cache e, a seguir, mostrarei como executar o aplicativo, mas precisaria de mais uma etapa antes de passarmos a isso. Está começando também, então está demorando um pouco, tudo bem, lá vai.
Monitorar estatísticas
Então, havia uma pergunta sobre as opções de monitoramento, acho que deveria resolver isso agora. Vou adicionar minha caixa como cliente, de onde vou rodar o aplicativo de editor e assinante. Eles também podem ser executados em qualquer servidor que tenha acesso a esse cache. Eu adicionei minha caixa como um cliente, então, essa é essencialmente a caixa do cliente. Posso adicionar outra caixa e a partir dela também posso executar aplicativos. Você percebe que há algumas opções de janela de estatísticas disponíveis na ferramenta de gerenciamento, mas para o Pub/Sub, o que eu faria inicialmente, lançaria NCache monitor e, em seguida, também mostrarei alguns dos contadores que estão disponíveis especificamente para Pub/Sub.
Por exemplo, este é meu painel Pub/Sub. Eu vou em frente e isso é NCache ferramenta de monitor que vem instalar com NCache. Acho que preciso, 1 por 3 é bom. Tudo bem, então, primeiro de tudo, se você notar, temos estatísticas de tópicos. Então temos algumas mensagens publicadas por segundo, digamos, contagem de mensagens e então temos mensagens expiradas por segundo. Eu acho, isso é bom. Você pode adicionar mais também pelo caminho. Há muitos aqui e depois há contadores PerfMon que também estão disponíveis. Deixe-me habilitá-los também e, em seguida, executarei um aplicativo para mostrar como isso funciona. Eu só preciso mostrar os contadores e nossa ferramenta de monitoramento também está usando contadores PerfMon. Então, o que você está vendo aqui também está disponível no monitor e vice-versa também. Tudo bem, então, estamos todos configurados. Então, temos alguns contadores aqui também. Por exemplo, contagem de mensagens, entrega por segundo expirou. Então, você pode ver a visualização numérica, a visualização numérica e também temos a visualização gráfica no monitor também.
Executar uma editora
Agora, eu executaria um aplicativo que vem instalado com ele, mas o ajustei um pouco, para que eu possa publicar quantas mensagens precisar. Portanto, esta é a configuração do aplicativo um para o editor e, em seguida, esta é uma configuração do aplicativo para o consumidor, o assinante. Tudo bem, então, eu executaria este aplicativo. Primeiro, ele iniciará o aplicativo do editor e mostrará como isso funciona. Deixe-me rever isso, talvez eu não salvei. Tudo bem, só me dê um minuto que eu preciso colocar um loop em torno dele. Na verdade, há um loop. Tudo bem, deixe-me depurá-lo. Portanto, não tenho informações para me conectar a esse cache. Então, vamos descobrir isso. Eu adicionei minha caixa então, por favor, tenha paciência comigo. Deixe-me corrigir esse problema rapidamente, levará alguns minutos. Embora tenha adicionado, talvez tenha havido um erro de digitação. Ai está. Eu estava especificando nosso nome de cache errado, meu bem. Deixe-me rever o nome aqui. É pubsubcachewin.
Eu estava usando o nome do cache de ontem, que era um cache de demonstração. Acontece. Tudo bem, estou feliz por ter conseguido consertá-lo rapidamente, caso contrário, teria sido um desastre total. Então, acho que estamos bem. Então, isso vai lançar o programa, que será o publisher.exe e publicará dez mensagens. Estou publicando as mesmas mensagens de novo e de novo. Neste ponto, o editor é iniciado, o assinante ainda não foi iniciado. Então, deixe-me mostrar os detalhes do monitoramento.
Há alguns pedidos que estão chegando, é claro, em torno disso. Mas se você notar, havia o meu tópico, esse é o nome 10.
Os itens estão lá e você deve ver essas mensagens expiradas após o tempo de expiração ter decorrido e acho que estou colocando cinco minutos de expiração ou mais nisso. Agora eu iria em frente e publicaria mais alguns. Lá vai você e você deve ter 10 itens aqui, extra adicionado. Portanto, 20 itens no total e você pode ver a contagem de mensagens subindo.
Então, esse é o gráfico e você também pode ver as mesmas opções no monitor de desempenho do Windows, onde temos tamanho e contagem de mensagens de 20 a 12 agora. Principalmente, porque alguns expiraram. Acho que já estou usando menos expiração como parte disso. Deixe-me ver, eu acho, a contagem de mensagens não está aparecendo corretamente, deixe-me ver, eu acho que isso é, isso deve ser 20 conforme o meu monitor.
Executar assinantes
Vamos rever isso com a ajuda dos assinantes. Vamos ver quantas mensagens ele recebe e, a propósito, vou mostrar o código assim que terminar a demonstração.
Então, é suposto receber as mensagens existentes e acho que conseguiu todas de forma aleatória. Esta é uma chamada assíncrona de mensagens. Ele não garante que as mensagens sejam entregues nessa ordem. Assim, você pode receber a primeira mensagem em um estágio posterior e assim por diante.
E se eu voltar aqui, temos a contagem de mensagens caindo para zero. Acho que este contador, vamos rever isso mais uma vez. Não tenho certeza se isso representa as mensagens para um determinado tópico ou mensagens gerais que são publicadas. Tudo bem, então, não está mostrando o valor correto, enquanto isso deveria aparecer. Acho que essas mensagens foram recebidas. Então, eu preciso fechar o assinante para conseguir isso. Vou abrir outro assinante. Então, você vê as mensagens sendo entregues a vários e acho que vamos concluir e mostrar o exemplo de código para isso. Vou inserir mais algumas mensagens, continue fazendo isso e então no lado do assinante você pode ver que 10 mensagens são recebidas por este e depois mais algumas recebidas por este. Se houver duas opções de entrega, você pode optar por transmitir mensagens para todos esses assinantes ou para qualquer um. Certo, então, com base no que o recebe, uma mensagem também expira do cache. Então, essa foi uma demonstração rápida. Agora, vou mostrar os detalhes sobre o que está envolvido para publicar uma mensagem? Quais são os recursos no lado do tópico? Quais são os recursos do lado do editor e quais são os recursos do lado do assinante? Se houver alguma dúvida neste momento, por favor me avise. Eu ficaria feliz em responder a essas perguntas para você agora, caso contrário, vou seguir em frente e mostrar o lado arquitetônico detalhado das coisas.
Principais interfaces do Pub/Sub em NCache
Estas são as principais interfaces dentro NCache.
Tema
Temos tópico. Novamente, é um canal de comunicação. Ele contém uma lista de assinantes e retransmite mensagens publicadas para si mesmo para os assinantes conectados.
Mensagem
Então temos a mensagem que é a carga principal. O ponto de interesse, o objeto de interesse dos assinantes. É uma carga útil serializável. Pode ser qualquer objeto, pode ser qualquer mensagem que você queira entregar, qualquer dado para ser preciso.
Publisher
Publisher é aquele que é um aplicativo que está publicando mensagens e também pode receber uma notificação de status de entrega opcional. O status de entrega é algo que você pode optar por ativar, mas como foi decidido anteriormente ou conforme discutido anteriormente, o editor não precisa esperar a entrega da mensagem. Pode seguir em frente. Portanto, o status de entrega opcional é algo que você pode ativar conforme necessário ou desativá-lo.
Assinante
Assinantes, eles se cadastram para um tópico específico e recebem todas as mensagens.
Então, vamos revisá-los um por um e o diagrama ilustra tudo o que acabamos de discutir.
O Publisher cria mensagens, registra eventos, envia mensagens, tópico e armazena mensagens, armazena assinantes e envia mensagens. Os assinantes se inscrevem e recebem notificações de mensagens.
NCache Interface de tópicos do Pub/Sub
Então, vamos revisar a interface do tópico. Então, em primeiro lugar, você pode criar um NCache Pub/Sub e, em seguida, você também pode se conectar a um tópico existente ou excluir um tópico. Então, vamos ver o que está envolvido nessa interface aqui? Então, se eu for a este editor aqui, primeiro preciso ir ao programa e se você notar neste programa, estou recebendo o nome do cache. Estou recebendo o nome do tópico, que pode ser qualquer tópico que você escolher e estou recebendo um contador de mensagens, que é uma mensagem aleatória e tenho o método publisher.start, que implementei e dentro dele' Estou inicializando o cache, o que significa que vou conectá-lo ao cache e, em seguida, estou obtendo uma interface de criação de tópico e, se eu voltar aqui, temos IMessagingService. Então, se eu rapidamente mostrar isso aqui.
IMessagingService Interface for managing Topics in NCache
namespace Alachisoft.NCache.Web.Caching
{
public interface IMessagingService
{
ITopic CreateTopic(string topicName);
void DeleteTopic(string topicName);
ITopic GetTopic(string topicName);
}
}Temos a interface IMessagingService, que possui um método CreateTopic, um método DeleteTopic para excluir um tópico e depois GetTopic. Vamos rever estes um por um. Então, serviço de mensagens criamos um tópico ou podemos apenas nos conectar a um tópico existente. O que você realmente faz é habilitar a entrega de mensagens, notificação de falha de entrega, se isso for algo que você gostaria de fazer. Por exemplo, você pode configurar um retorno de chamada aqui e esse retorno de chamada pode, por sua vez, ser invocado, mas isso é opcional. Você não precisa necessariamente disso, se não quiser habilitá-lo. Então, como eu disse anteriormente, as notificações de entrega de mensagens são opcionais, então você não precisa habilitá-las como uma obrigação. Depende inteiramente do seu caso de uso, se você deseja habilitá-los, pode ir em frente e fazê-lo.
Em seguida, temos um método de publicação, que é um método personalizado para este aplicativo, um wrapper para isso e, em seguida, dentro dele, o que estamos realmente fazendo é construir uma mensagem e usar a mensagem topic.publish. Então, isso retorna uma mensagem, um tópico. Uma espécie de identificador para esse tópico e, em seguida, topic.publish é o método real deles, se eu mostrar rapidamente aqui. Esta é uma interface ITopic, que tem um nome, pode ter uma contagem de mensagens, pode ter um tempo de expiração, que vou mostrar daqui a pouco e também tem alguns retornos de chamada sobre o tópico excluído, falha na entrega de mensagens e então ele permite que você tenha uma assinatura para o tópico e depois publique mensagens nele também e esse é o primeiro método que eu queria mostrar, é que você pode usar topic.publish e então se você perceber que existe uma opção de entrega como Nós vamos. Você pode ter entrega a todos como uma obrigação ou a qualquer um. Então, esse é o nível de mensagem, então, essa é uma opção de entrega para as mensagens entregues ou enviadas para esse tópico e, em seguida, há um último booleano opcional aqui, vamos verificar isso, o que sugere? Para este, se você deseja ter alguma notificação de falha ou não. Portanto, neste caso, estou definindo isso como verdadeiro, mas você pode desativá-lo e, se isso acontecer, ele invocará o retorno de chamada no lado do editor de acordo.
Então, vimos dois métodos aqui. Você pode criar um tópico e, da mesma forma, ao lado disso, você também pode obter um tópico. Então, esse é outro método que você pode usar, alternativamente. Mas, como estou executando isso pela primeira vez, estou usando criar tópico, publicando mensagens no tópico e também posso excluir o tópico, se necessário. Então, esses são alguns dos cenários e, como você pode ver, esses slides estão mostrando os mesmos exemplos ao lado.
Create Topic: Code snippet to create a new topic in distributed cache
string cacheName = "pubSubCache";
string topicName = "orderTopic";
Cache cache = NCache.InitializeCache(cacheName);
cache.MessagingService.CreateTopic(topicName);Portanto, se você excluir o tópico, o retorno de chamada do tópico excluído será invocado e o retorno de chamada do tópico excluído será aquele de onde você pode notificar seus usuários finais ou qualquer informação que precise publicar.
Delete Topic: Deletes an existing Topic distributed
string cacheName = "pubSubCache";
string topicName = "orderTopic";
Cache cache = NCache.InitializeCache(cacheName);
cache.MessagingService.DeleteTopic(topicName);
OnTopicDeleted callback: If registered, it will be triggered upon the Delete Topic call.
using (Subscriber subscriber = new Subscriber())
{
// Subscribes on it, using the provided cache-Id and the topic-name.
subscriber.OnTopicDeleted = TopicDeletedCallback;
}
static void TopicDeletedCallback(object sender, TopicDeleteEventArgs args)
{
Console.WriteLine("Topic '{0}' deleted.", args.TopicName);
}NCache Interface de mensagem do Pub/Sub
Vamos dar uma olhada na interface de mensagens e aqui discutimos que há uma opção de invalidação de mensagem, notificações de mensagem recebida, falha ou recebimento, notificação de falha e, em seguida, criptografia e compactação são suportadas como parte disso. Então, vamos dar uma olhada na interface IMessage para esse assunto. Então, nós temos uma mensagem aqui.
namespace Alachisoft.NCache.Runtime.Caching
{
public class Message : IMessage
{
public Message(object payload, TimeSpan? timeSpan = null);
public static TimeSpan NoExpiration { get; }
public string MessageId { get; }
public TimeSpan? ExpirationTime { get; set; }
public object Payload { get; }
public DateTime CreationTime { get; }
}
}Vamos ver, o que está disponível como parte disso. Então, em primeiro lugar, nós temos um TimeSpan, você pode escolher NoExpiration ou você pode ter um TimeSpan ExpirationTime aqui para ser especificado como uma opção de mensagem e se eu voltar aqui, se você perceber que estamos definindo alguma expiração baseada em tempo sobre isso também, se você perceber que isso está sendo repassado aqui e temos um período de tempo. Então, isso está sendo chamado pelo próprio programa. Então, estamos dando “TimeSpan.FromMinutes(5)”. Então, isso significa essencialmente que qualquer tópico que não seja entregue, se não houver assinante ou assinantes forem desconectados, essa mensagem permanecerá no canal de comunicação pelo período de tempo especificado. É uma espécie de persistência, mas como é contra a plataforma Pub/Sub persistir mensagens indefinidamente, a base de tempo é a opção certa, onde você persiste as mensagens por um determinado período de tempo e depois limpa o próprio armazenamento. Essas mensagens também não serão expiradas individualmente do canal de comunicação e essa expiração pode ser no próprio nível do tópico. O próprio tópico pode ter sua expiração ou as mensagens podem ter sua expiração individual anexada a elas também. Então, isso é algo que você faz e, a propósito, se o editor e os assinantes estiverem conectados, o editor publica as mensagens e elas são retransmitidas imediatamente. Não espera o vencimento acontecer. Ele não vai mantê-lo, se a mensagem foi entregue. Assim, uma vez que a mensagem foi entregue, ela sai do cache imediatamente. Então, é assim que você configura a expiração.
Então você também tem alguma notificação recebida nas mensagens. Isso é algo que eu mostrei antes. Por exemplo, você pode ver a entrega, "Publisher.MessageDeliveryFailure" notificação e então você também pode gerar uma mensagem, status de sucesso da mensagem também. Portanto, essa é outra opção que você pode ativar como parte disso e, em seguida, a criptografia e a compactação de mensagens também podem ser feitas e isso é algo que não é uma opção de alteração de código. Tudo o que você precisa fazer é entrar no próprio cache, ir nas opções porque tudo é conduzido por NCache em si. Assim, você pode ativar a compactação e clicar com o botão direito do mouse e escolher as configurações de aplicação a quente.
A compactação é para objetos que são maiores em tamanho. A carga útil da mensagem é maior em tamanho, portanto, você deve ativar a compactação automaticamente e a criptografia é outra opção aqui. Isso exigiria que você habilite a criptografia e para isso você precisa parar o canal de comunicação primeiro, parar o cache e depois habilitar a criptografia. Existem muitos provedores que você pode escolher e todas as mensagens serão criptografadas e só então enviadas de volta ao editor e aos assinantes. Espero que tenha sido direto. Então, o exemplo de mensagem está bem aqui.
//Payload containing OrderId to be sent in message
Order payload = new Order();
payload.OrderID = 10248;
payload.OrderDate = new DateTime(2015, 07, 04);
payload.ShipName = "Vins et alcools Chevalier";
payload.ShipAddress = "59 rue de l'Abbaye";
payload.ShipCity = "Reims";
payload.ShipCountry = "France";
//Create message with payload and expiration time set to 150 seconds
Message message = new Message(payload);
message.ExpirationTime = new TimeSpan(0, 0, 150);Você pode usar ordem, construir uma mensagem, configurar algum tempo de expiração e depois usar “tópico.publicar” e fornecer essa mensagem para o tópico certo.
Notificação de mensagem recebida
Então, a mensagem recebeu notificação. Do lado do assinante, quero mostrar isso também.
Callback invoked when a message is published on the topic
string cacheName = "pubSubCache";
string topicName = "orderTopic";
Cache cache = NCache.InitializeCache(cacheName);
//Get Order topic
ITopic orderTopic = cache.MessagingService.GetTopic(topicName);
//Register subscribers for Order topic
ITopicSubscription ordSubscriber = orderTopic.CreateSubscription(messageReceivedCallback);
private void messageReceivedCallback(object sender, MessageEventArgs args)
{
//perform operations
if (args.Message.Payload is Order ord)
{
//perform operations
}Do ponto de vista do assinante, tudo o que você precisa fazer é se conectar ao cache para começar. Conecte-se ao tópico usando “_cache.MessagingService.GetTopic”. Este foi o método que eu estava mostrando anteriormente ou você pode criar um tópico, se existir e então você cria uma assinatura que permite receber mensagem em um retorno de chamada e aqui está a mensagem de retorno de chamada. Acho que deveria estar aqui mesmo no programa. Mensagem receber retorno de chamada. Então, isso será invocado toda vez que uma mensagem for recebida. Então, isso completa o exemplo aqui.
Passo a passo: publicar mensagem no tópico
Então, passo a passo mais uma vez. Você inicializa o cluster de cache do Pub/Sub, cria um tópico dedicado ou se conecta a um existente. Registre eventos de entrega de mensagens, se necessário, é opcional. Crie uma mensagem e publique em um tópico separado. Habilite a expiração, habilite as opções de entrega conforme necessário e esse é um código que ajudaria a justificar isso.
public void PublishMessages()
{
string cacheName = "pubSubCache";
string topicName = "orderTopic";
Cache cache = NCache.InitializeCache(cacheName);
ITopic orderTopic = cache.MessagingService.CreateTopic(topicName);
//Register message failure notification
orderTopic.MessageDeliveryFailure += FailureMessageReceived;
//Register topic deletion notification
orderTopic.OnTopicDeleted = TopicDeleted;
//Payload to be sent in message
Order payload = new Order();
payload.OrderID = 10248;
payload.OrderDate = new DateTime(2015, 07, 04);
payload.ShipName = "Vins et alcools Chevalier";
payload.ShipAddress = "59 rue de l'Abbaye";
payload.ShipCity = "Reims";
payload.ShipCountry = "France";
//Create message with Order and expiration time set to 150 seconds
Message orderMessage = new Message(orderPayload);
orderMessage.ExpirationTime = new TimeSpan(0, 0, 150);
//Publish message to all registered subscribers
//and register message delivery failure notification
orderTopic.Publish(orderMessage, DeliveryOption.All, true);E então, no lado do assinante, você se conecta ao cache, obtém um tópico existente ou cria um novo. Crie uma assinatura para o tópico para recebimento de mensagens. Registre eventos para recebimento que serão eventos assíncronos e, em seguida, cancele a inscrição do tópico e também exclua-o, se necessário, e o evento de exclusão pode fazer parte dele.
NCache Monitoramento para Pub/Sub
Os próximos slides serão focados no lado do monitoramento. Vamos revisá-los na totalidade. Já abordamos os detalhes básicos do suporte ao contador PerfMon para NCache, temos diferentes opções no painel. Vamos criar outro painel.
Vamos ter tudo isso adicionado a ele. Então, temos algumas estatísticas de tópicos também. Por exemplo, temos estatísticas de tópicos, que já mostrei a você. Contagem de tópicos, número de tópicos que você tem. Contagem de mensagens. Tamanho do armazenamento de mensagens, que são o tamanho total e bytes do tópico e isso é muito importante para a capacitação. Se você está tentando entender quantas mensagens estão sendo entregues ou publicadas, você pode arrastar e soltar a mensagem publicada por segundo e a mensagem entregue por segundo e então você pode ter algum status de expiração da mensagem, bem como parte disso. Então, esses são alguns dos contadores. Se eu executar o aplicativo de exemplo mais uma vez, você verá atividade em todos eles. Tudo bem, eu vou continuar colocando um pouco de carga apertando enter várias vezes e se eu voltar aqui, você pode ver as atividades em todos eles.
São 220 mensagens. A contagem de tópicos é 1 neste momento. A contagem de mensagens é de cerca de 220. Os tamanhos de armazenamento de mensagens também estão sendo exibidos. As mensagens são publicadas. Mas não há nenhuma mensagem que foi entregue e não há mensagens que expiraram e se eu apenas executar um assinante, será bem rápido, você verá que essas mensagens também serão recebidas. Lá vai você e se eu voltar aqui, agora você deve ver atividade aqui também. As mensagens também são recebidas.
Então, isso completa o processo, você pode registrar esses contadores para ver a capacidade, para ver os tópicos gerais que estão lá, as mensagens lá, o tamanho do armazenamento e a expiração dessas mensagens também e posso criar quantos tópicos precisar com base em minhas exigências. Os mesmos contadores também estão disponíveis no Windows PerfMon. Portanto, você tem o mesmo conjunto aqui e, além disso, também possui alguns cmdlets do PowerShell. Por exemplo, se você acessar nossa documentação aqui, deixe-me abri-la bem rápido. Então, temos três opções diferentes, Contadores PerfMon, NCache Monitor e cmdlets do PowerShell. Em alguns casos, você só quer confiar nas ferramentas. Então, para isso, você pode usar nossa documentação e dentro do nosso guia do PowerShell, vamos ver se consigo pesquisar bem rápido. Ele me deu um link geral, então, deixe-me ver algumas opções de monitoramento aqui. Assim, você pode ver “Get-Topics”, que é um cmdlet do PowerShell, que permite obter nomes de tópicos com base no nome do cache. Por exemplo, se eu abrir o PowerShell aqui. Eu posso usar este comando, deixe-me apenas abri-lo deste lado para que fique claro. Tudo bem, então, por exemplo, eu posso executá-lo de qualquer caixa aqui e então pubSubCachewin é o nome do cache. Não me daria nada. Preciso rodar no próprio servidor porque acho que não, pubSubCachewin, pronto. Meu tópico, assinantes, editor e contagem de mensagens.
O motivo para começar a trabalhar a partir da minha caixa é que ela precisa de um endereço IP para saber onde está o cache. Portanto, existem algumas ferramentas no lado do PowerShell, que permitem que você veja algumas estatísticas conforme necessário. Então, isso completa a parte de demonstração. Por favor, deixe-me saber se houver alguma dúvida. Vou gastar algum tempo no final para obter detalhes sobre a arquitetura ou o que está sendo oferecido como parte deste canal de comunicação, NCache como uma plataforma de mensagens e por que NCache é um ajuste melhor?
Arquitetura de cache distribuído
Primeiro de tudo, NCache é de código aberto. Assim, você pode começar e o Pub/Sub está disponível mesmo em uma versão Open Source do NCache. É linearmente escalável, esse é o ponto número um e, antes disso, está na memória. Esse é o principal ponto de interesse para aplicativos que buscam apenas desempenho e não desejam ter altos requisitos de carga para começar. Então, se houver um problema de desempenho NCache novamente é um ajuste melhor em comparação com as plataformas convencionais de mensagens Pub/Sub.
É linearmente escalável, o que significa essencialmente que você pode adicionar quantos servidores precisar. Dois servidores são bons o suficiente. Mas se eles atingirem a capacidade porque a capacidade pode ser atingida por NCache servidores também. O problema inicial que você viu com database. Nós não estamos dizendo isso NCache não veria esse problema. Com um servidor, você pode atingir uma capacidade e, nesse caso, pode ter mais servidores, mas esses mais servidores também podem adicionar capacidade. Por exemplo, esses dois servidores estão sendo maximizados e esse é o momento certo porque você sabe com antecedência sobre os requisitos de carga ou carga alta em seu aplicativo. Portanto, você pode evitar isso adicionando mais servidores e fazendo um melhor planejamento de capacidade. Assim, mais servidores podem ser adicionados em tempo real e essa é a beleza de ser linearmente escalável.
Então a terceira característica importante é que, se você precisar, você também pode ter suporte a replicação e isso garantiria confiabilidade. Já está altamente disponível e seu servidor inativo não terá impacto nos clientes finais ou a plataforma do editor ou do assinante funcionaria sem problemas. Contanto que você tenha um nó sobrevivente no cluster de cache, a plataforma Pub/Sub permanecerá em funcionamento e por que ela pode fazer isso? É altamente disponível porque é dinâmico por natureza.
É um cluster de cache arquitetado 100% ponto a ponto. Isso permite que você adicione quantos servidores precisar e esses servidores são independentes por natureza. Eles contribuem para a capacidade de atendimento de solicitações distribuindo a carga, mas funcionam em uma capacidade 100% independente. Qualquer servidor inativo ou novo servidor sendo adicionado não teria nenhum impacto no cache. A plataforma não precisa ser parada para isso. Ele pode continuar funcionando e os clientes não precisam ser interrompidos ou reiniciados. Esse é o problema com fontes convencionais, onde se um servidor cair, você pode ter que reiniciar os clientes para começar a usar os nós sobreviventes. Portanto, essa é uma natureza dinâmica em que os clientes se ajustam automaticamente e o próprio cluster tem 100% de tempo de atividade com mecanismo de autorrecuperação. Se um servidor for adicionado, o cluster se ajusta a isso distribuindo a carga para o servidor recém-adicionado e notificando os clientes ao mesmo tempo.
Da mesma forma, no caso de manutenção ou caso de queda do servidor, em que um servidor fica inativo ou falha nesse caso, o cluster de cache permanece ativo e em execução. Você precisa de um nó sobrevivente para que isso funcione e os clientes sejam notificados em tempo de execução. O suporte a failover de conexão é integrado ao protocolo do lado do cliente. Assim, os clientes detectam falhas e fazem failover e começam a usar os nós de sobrevivência automaticamente e isso garante um tempo de atividade de 100% no lado do cache e também para seus clientes finais que estão conectados a ele. Então, é dinâmico por natureza. É 100% arquitetado peer-to-peer. O suporte a failover de conexão é incorporado a ele e o cluster é auto-recuperável dentro de si. É um mecanismo embutido no protocolo. Isso garante 100% de tempo de atividade, um cenário de cache altamente disponível.
Topologias de cache: cache particionado
A topologia dos canais de comunicação.
A plataforma Pub/Sub pode ter particionamento de dados. Você pode ter dados particionados no Servidor 1 e também no Servidor 2. Esses são elementos de dados que representam suas mensagens. Então, temos algumas mensagens entregues pelo Servidor 1 e algumas pelo Servidor 2. É completamente aleatório, baseado em nosso algoritmo de distribuição e seu editor e assinantes estão conectados a todos os servidores. Então, alguns estão conectados ao Servidor 1, alguns estão conectados ao Servidor 2, mas se você notar que cada servidor tem, na verdade eles estão conectados a todos eles, mas algumas mensagens são entregues pelo Servidor 1 e algumas pelo Servidor 2 e assim por diante adiante. Assim, a carga de mensagens vai ser distribuída e isso é realizado de forma excêntrica, onde utiliza totalmente a capacidade de memória de todos esses servidores, para servir as mensagens, para armazenar as mensagens, para o seu tempo de expiração e também une seu poder computacional em uma capacidade lógica também. Portanto, todos esses serviços contribuem para a capacidade de manipulação de solicitações e é por isso que, se você adicionar mais servidores, obterá mais capacidade do sistema e é por isso que recomendamos que você use a topologia de réplica de operação de partição porque você pode dimensionar linearmente, se você preciso.
Topologias de cache: cache de réplica de partição
Este é o cache de réplica de partição, que também tem suporte para backup.
Temos partição ativa do Servidor 1, backup no (servidor) 2. Assim, todos os servidores formulam uma partição ativa e uma partição de backup de outro servidor, que é uma réplica para outro servidor. Servidor 1 é backup ativo no Servidor 2, Servidor 2 é backup ativo em 3 e Servidor 3 é backup ativo em 1 e o cluster ainda é capaz de gerenciar isso se um servidor ficar inativo. Porque, se o servidor 1 ficar inativo, o backup do servidor 1 estava em 2, então esse backup é ativado e é mesclado nos servidores 2 e 3 e o cluster se recupera e formula um backup ativo de 2 nós, mecanismo passivo ativo onde o backup do servidor 1 está ativado O backup do Servidor 2 está no Servidor 1. E é totalmente transparente para seus usuários finais. Você não precisa se preocupar com os usuários finais sendo afetados por isso. Então, com 100% de tempo de atividade NCache garante tudo isso.
Tudo bem, isso nos leva ao final de nossa apresentação. Por favor, deixe-me saber, podemos nos concentrar no final em algumas das perguntas que vocês podem ter. Então, eu entregaria para Eddie neste momento. Eddie você pode pegá-lo daqui. Mais uma vez, muito obrigado pelo seu tempo. Espero que tenha sido benéfico e esperamos vê-lo novamente em nosso próximo webinar. Nesse ínterim, se você precisar revisar o webinar existente, que acabou de revisar on-line em alachisoft.com/recursos Novamente um lembrete, NCache é o único aplicativo nativo no mercado hoje para desempenho máximo. Esperamos vê-lo novamente em breve. Obrigada.