Introdução aos cenários de uso da fila de mensagens

O middleware de fila de mensagens é um componente importante em sistemas distribuídos, principalmente resolvendo problemas como acoplamento de aplicativos, mensagens assíncronas e corte de tráfego

Obtenha alto desempenho, alta disponibilidade, escalabilidade e arquitetura de consistência eventual

As filas de mensagens mais usadas são ActiveMQ, RabbitMQ, ZeroMQ, Kafka, MetaMQ, RocketMQ

2. Cenários de aplicação de fila de mensagens

A seguir estão descritos os cenários de uso comuns de filas de mensagens em aplicativos práticos. Quatro cenários de processamento assíncrono, desacoplamento de aplicativos, corte de tráfego e comunicação de mensagens

2.1 Processamento assíncrono

Descrição do cenário: Após o cadastro do usuário, ele precisa enviar um e-mail de cadastro e um SMS de cadastro. Existem dois métodos tradicionais: 1. Via serial; 2. Via paralela

(1) Modo serial: Depois de escrever com sucesso as informações de registro no banco de dados , envie o e-mail de registro e, em seguida, envie o SMS de registro. Depois que as três tarefas acima forem concluídas, retorne ao cliente

(2) Modo paralelo: Depois que as informações de registro são gravadas com sucesso no banco de dados, o e-mail de registro e o SMS de registro são enviados ao mesmo tempo. Depois que as três tarefas acima forem concluídas, retorne ao cliente. A diferença da serial é que o método paralelo pode melhorar o tempo de processamento

Supondo que cada um dos três nós de serviço use 50 milissegundos, sem considerar outras sobrecargas, como a rede, o tempo serial é de 150 milissegundos e o tempo paralelo pode ser de 100 milissegundos.

Como o número de solicitações processadas pela CPU por unidade de tempo é certo, suponha que a taxa de transferência da CPU em 1 segundo seja 100 vezes. Em seguida, a CPU pode lidar com 7 solicitações (1000/150) em 1 segundo no modo serial. A quantidade de solicitações processadas em paralelo é de 10 vezes (1000/100)

Resumo: Conforme descrito no caso acima, o desempenho (simultaneidade, throughput, tempo de resposta) do sistema da forma tradicional terá um gargalo. Como resolver este problema?

A introdução de filas de mensagens não exigirá lógica de negócios e será processada de forma assíncrona. A estrutura modificada é a seguinte:

De acordo com o acordo acima, o tempo de resposta do usuário é equivalente ao tempo para que as informações cadastrais sejam gravadas no banco de dados, que é de 50 milissegundos. Após cadastrar um e-mail, enviar uma mensagem curta e escrevê-la na fila de mensagens, ele retorna diretamente, então a velocidade de escrita na fila de mensagens é muito rápida, o que basicamente pode ser ignorado, então o tempo de resposta do usuário pode ser de 50 milissegundos. Portanto, após a alteração da arquitetura, a taxa de transferência do sistema é aumentada para 20 QPS por segundo. 3 vezes melhor que serial e 2 vezes melhor que paralelo

2.2 Desacoplamento de aplicativos

Descrição do cenário: Depois que o usuário faz um pedido, o sistema de pedidos precisa notificar o sistema de estoque. Tradicionalmente, o sistema de pedidos chama a interface do sistema de estoque. Como mostrado abaixo

Desvantagens do modelo tradicional:

Se o sistema de estoque estiver inacessível, o pedido falhará em reduzir o estoque, fazendo com que o pedido falhe
Sistema de pedidos acoplado ao sistema de estoque

Como resolver os problemas acima? A solução após a introdução da fila de mensagens do aplicativo é mostrada na figura a seguir:

Sistema de pedidos: depois que o usuário faz um pedido, o sistema de pedidos conclui o processo de persistência, grava a mensagem na fila de mensagens e retorna o pedido do usuário com sucesso
Sistema de estoque: assine as notícias do pedido e use o método pull/push para obter as informações do pedido, e o sistema de estoque realiza operações de estoque de acordo com as informações do pedido
Se: O sistema de estoque não estiver funcionando corretamente ao fazer um pedido. Isso não afeta a colocação normal do pedido, porque depois que o pedido é feito, o sistema de pedidos grava na fila de mensagens e não se preocupa mais com outras operações de acompanhamento. Realize a dissociação de aplicativos do sistema de pedidos e do sistema de estoque

2.3 Corte de fluxo

O corte de tráfego também é um cenário comum em filas de mensagens e geralmente é usado em atividades de coleta de dados ou grupos

Cenário do aplicativo: Em atividades seckill, geralmente devido ao tráfego excessivo, o tráfego aumentará drasticamente e o aplicativo travará. Para resolver esse problema, geralmente é necessário adicionar uma fila de mensagens no front-end do aplicativo.

O número de pessoas que podem controlar a atividade
Pode aliviar a aplicação de alto tráfego em um curto período de tempo

Depois que a solicitação do usuário é recebida pelo servidor, ela é primeiro gravada na fila de mensagens. Se o comprimento da fila de mensagens exceder o número máximo, a solicitação do usuário será descartada diretamente ou a página de erro será redirecionada
De acordo com as informações da solicitação na fila de mensagens, o negócio seckill fará o processamento de acompanhamento

2.4 Processamento de registros

O processamento de log refere-se ao uso de filas de mensagens no processamento de log, como o aplicativo Kafka, para resolver o problema da transmissão massiva de log. A arquitetura é simplificada da seguinte forma

O cliente de coleta de log, responsável pela coleta de dados de log, grava e recebe gravações regularmente na fila Kafka
Fila de mensagens Kafka, responsável por receber, armazenar e encaminhar dados de log
Aplicativo de processamento de log: assine e consuma dados de log na fila kafka

O seguinte é um caso de aplicação do processamento de log Sina kafka: Transferência de (http://cloud.51cto.com/art/201507/484338.htm)

(1) Kafka: fila de mensagens para recebimento de logs de usuários

(2) Logstash: faça análise de log, unifique na saída JSON para o Elasticsearch

(3) Elasticsearch: a principal tecnologia do serviço de análise de log em tempo real, um serviço de armazenamento de dados em tempo real e sem esquema, organiza dados por meio de índice e possui funções poderosas de pesquisa e estatística

(4) Kibana: Componentes de visualização de dados baseados em Elasticsearch, super capacidades de visualização de dados são uma razão importante pela qual muitas empresas escolhem a pilha ELK

2.5 Comunicação de mensagens

A comunicação de mensagem significa que as filas de mensagens geralmente possuem mecanismos de comunicação eficientes integrados, portanto, também podem ser usadas na comunicação de mensagem pura. Por exemplo, implemente filas de mensagens ponto a ponto ou salas de bate-papo etc.

Comunicação ponto a ponto:

O cliente A e o cliente B usam a mesma fila para comunicação de mensagens.

Comunicação da sala de bate-papo:

Cliente A, cliente B e cliente N se inscrevem no mesmo tópico para publicar e receber mensagens. Obtenha um efeito de sala de bate-papo.

Os itens acima são, na verdade, dois modos de filas de mensagens, ponto a ponto ou modo de publicação-assinatura. O modelo é um diagrama esquemático para referência.

3. Exemplo de middleware de mensagem

3.1 Sistema de comércio eletrônico

A fila de mensagens adota um middleware de mensagem altamente disponível e durável. Como Active MQ, Rabbit MQ, Rocket Mq.

(1) Depois que o aplicativo concluir o processamento lógico principal, grave-o na fila de mensagens. Se a mensagem foi enviada com sucesso pode habilitar o modo de confirmação da mensagem. (Após a fila de mensagens retornar o status de recebimento de mensagem com sucesso, o aplicativo retorna novamente, para garantir a integridade da mensagem)

(2) Estenda o processo (envio de mensagens de texto, processamento de entrega) para se inscrever em mensagens de fila. Use empurrar ou puxar para obter mensagens e processá-las.

(3) Embora a mensagem desacople a aplicação, ela traz problemas de consistência de dados, que podem ser resolvidos com o uso do método de consistência final. Por exemplo, os dados principais são gravados no banco de dados e o aplicativo estendido realiza o processamento de acompanhamento com base na fila de mensagens em combinação com o método de banco de dados de acordo com a fila de mensagens.

3.2 Sistema de coleta de logs

Ele é dividido em quatro partes: centro de registro do Zookeeper, cliente de coleta de log, cluster Kafka e cluster Storm (OtherApp).

Registro do Zookeeper, propõe balanceamento de carga e serviços de pesquisa de endereços
O cliente de coleta de log é usado para coletar os logs do sistema de aplicativo e enviar os dados para a fila kafka
Cluster Kafka: recebimento, roteamento, armazenamento, encaminhamento e outros processamentos de mensagens

Cluster Storm: no mesmo nível que OtherApp, usando pull para consumir dados na fila

Quatro, serviço de mensagens JMS

Ao falar sobre filas de mensagens, você deve mencionar o JMS. A API JMS ( Java Message Service, Java Message Service) é um padrão/especificação de serviço de mensagens que permite que os componentes do aplicativo criem, enviem, recebam e leiam mensagens com base na plataforma JavaEE. Isso torna a comunicação distribuída menos acoplada e os serviços de mensagens mais confiáveis e assíncronos.

Na arquitetura EJB, os beans de mensagem podem ser perfeitamente integrados aos serviços de mensagem JM. No modo de arquitetura J2EE, existe um modo de servidor de mensagens, que é usado para realizar o desacoplamento direto de mensagens e aplicativos.

4.1 Modelo de Mensagem

No padrão JMS, existem dois modelos de mensagens P2P (Point to Point), Publish/Subscribe (Pub/Sub).

4.1.1 Modo P2P

O modo P2P inclui três funções: fila de mensagens (Queue), remetente (Sender), destinatário (Receiver). Cada mensagem é enviada para uma fila específica e o destinatário obtém a mensagem da fila. As filas retêm as mensagens até que sejam consumidas ou atinjam o tempo limite.

Características do P2P

Cada mensagem possui apenas um consumidor (Consumer) (ou seja, uma vez consumida, a mensagem não fica mais na fila de mensagens)
Não há dependência de tempo entre o remetente e o destinatário, o que significa que, quando o remetente envia uma mensagem, isso não afeta a mensagem que está sendo enviada para a fila, independentemente de o destinatário estar em execução ou não
O destinatário precisa responder à fila após receber a mensagem com sucesso

Se você deseja que todas as mensagens enviadas sejam processadas com sucesso, você precisa do modo P2P. (Arquitetura KKQ: 466097527, bem-vindo para participar)

4.1.2 Modo Pub/Sub

Contém três funções: Tópico, Editor e Assinante. Vários editores enviam mensagens para o Tópico e o sistema entrega essas mensagens para vários assinantes.

Recursos do Pub/Sub

Cada mensagem pode ter vários consumidores
Há uma dependência de tempo entre editores e assinantes. Para um assinante de um tópico (Topic), ele deve criar um assinante antes de poder consumir a mensagem do editor
Para consumir mensagens, o assinante deve permanecer em execução

Para aliviar essas dependências de tempo estritas, o JMS permite que os assinantes criem uma assinatura durável. Desta forma, mesmo que o Assinante não esteja ativado (em execução), ele pode receber as mensagens do Publicador.

Se a mensagem que você deseja enviar puder ser processada sem nenhum processamento, ou puder ser processada por apenas um mensageiro, ou puder ser processada por vários consumidores, o modelo Pub/Sub poderá ser usado.

4.2 Consumo de mensagens

No JMS, a produção e o consumo de mensagens são assíncronos. Para consumo, os mensageiros JMS podem consumir mensagens de duas maneiras.

(1) sincronização

Assinantes ou destinatários recebem mensagens por meio do método de recebimento e o método de recebimento será bloqueado até que a mensagem seja recebida (ou antes do tempo limite);

(2) assíncrono

Um assinante ou receptor pode se registrar como um ouvinte de mensagens. Quando a mensagem chega, o sistema chama automaticamente o método onMessage do ouvinte.

JNDI: Java Naming and Directory Interface, é uma interface padrão do sistema de nomenclatura Java. Os serviços podem ser encontrados e acessados na web. Ao especificar um nome de recurso, o nome corresponde a um registro no banco de dados ou no serviço de nomes e retorna as informações necessárias para o estabelecimento da conexão do recurso.

JNDI desempenha um papel na localização e acesso ao destino de envio ou origem da mensagem no JMS.