O ApsaraMQ for MQTT exporta eventos de conexão e desconexão de clientes para serviços downstream da Alibaba Cloud por meio de regras configuráveis. Aplicações de backend consomem esses eventos para rastrear o status de conexão, acionar fluxos de trabalho automatizados ou analisar padrões de conectividade.
As notificações de eventos de status são assíncronas e não refletem o status do cliente em tempo real. Para consultar o status atual de um cliente em tempo real, consulte Obter o status de um cliente do ApsaraMQ for MQTT.
Como funciona
Quando um cliente do ApsaraMQ for MQTT se conecta ou desconecta, o broker envia uma notificação de status para um serviço downstream da Alibaba Cloud com base na regra configurada. Aplicações de backend implantadas em instâncias do Elastic Compute Service (ECS) assinam essas notificações para detectar transições de clientes entre os estados online e offline.

Como esse processo é assíncrono, uma única notificação não indica se um cliente está online no momento. Para determinar o status real, analise a linha do tempo das notificações de eventos desse cliente. Para mais detalhes, consulte Determinar o status do cliente a partir de eventos.
Casos de uso
A exportação de eventos de status dispara ações no backend quando clientes MQTT se conectam ou desconectam. Um fluxo de trabalho típico para análise de atividade de conexão inclui:
O status de conexão de um cliente muda várias vezes.
O broker encapsula cada alteração em uma notificação conforme a regra configurada.
As notificações são entregues em um tópico do ApsaraMQ for RocketMQ.
Uma aplicação de backend consome as notificações e constrói um histórico de conexões do cliente.
Limites
|
Item |
Limite |
Descrição |
|
Regras por instância |
100 |
Para solicitar um limite maior, entre no grupo DingTalk 116015007918 e contate o suporte técnico do ApsaraMQ for MQTT. |
|
Deduplicação de regras |
Uma regra de cada tipo por recurso interno |
Por exemplo, cada grupo suporta uma regra de notificação de status do cliente, e cada tópico do ApsaraMQ for MQTT suporta uma regra de entrada de dados e uma regra de saída de dados. |
|
Regras entre regiões |
Não suportado |
A source e o destino dos dados devem residir na mesma região. |
|
Versão da instância do ApsaraMQ for MQTT |
Apenas kernel V3.x.x |
Verifique a versão do kernel na lista de instâncias ou na página Instance Details no console do ApsaraMQ for MQTT. |
|
Versão da instância do ApsaraMQ for RocketMQ |
Apenas ApsaraMQ for RocketMQ 4.0 |
Aplica-se a regras de entrada e saída de dados entre o ApsaraMQ for MQTT e o ApsaraMQ for RocketMQ. |
Mapeamento de recursos
As notificações de status de todos os clientes no mesmo grupo do ApsaraMQ for MQTT são encaminhadas para o mesmo recurso downstream.
|
Recurso do ApsaraMQ for MQTT |
Serviço da Alibaba Cloud |
Recurso downstream |
Definição do pacote |
|
Grupo |
ApsaraMQ for RocketMQ |
Tópico |
Mapeamentos de estrutura de mensagens entre ApsaraMQ for MQTT e ApsaraMQ for RocketMQ |
Configurar a exportação de eventos de status
Os passos a seguir utilizam o ApsaraMQ for RocketMQ como serviço downstream.
Pré-requisitos
Antes de começar, verifique se você possui:
Uma instância do ApsaraMQ for MQTT com versão de kernel V3.x.x
Uma instância do ApsaraMQ for RocketMQ 4.0 na mesma região
Pelo menos um grupo configurado na instância do ApsaraMQ for MQTT
Passo 1: Crie uma regra de notificação de status do cliente
No console do ApsaraMQ for MQTT, crie uma regra e selecione os grupos cujos eventos de status do cliente você deseja exportar. Para obter os passos detalhados, consulte Criar uma regra para notificações de status do cliente.
Passo 2: Assinar notificações de status na sua aplicação de backend
Após a regra entrar em vigor, os eventos de status são entregues no tópico do ApsaraMQ for RocketMQ configurado. Assine esse tópico na sua aplicação de backend para receber os eventos. Para detalhes sobre a assinatura, consulte Assinar mensagens.
Tipos de evento
Cada notificação de status é entregue como uma mensagem do ApsaraMQ for RocketMQ. O tipo de evento é especificado na tag da mensagem.
Formato da tag: connect, disconnect ou tcpclean
|
Tag |
Significado |
Condição de disparo |
|
|
Cliente conectado |
O cliente estabelece uma conexão com o broker. |
|
|
Cliente enviou um pacote DISCONNECT |
O cliente envia um pacote DISCONNECT antes de fechar a conexão TCP, conforme o protocolo MQTT. Se o SDK do cliente não enviar esse pacote, o broker não gera um evento |
|
|
Conexão TCP fechada |
A conexão TCP é encerrada, independentemente de o cliente ter enviado ou não um pacote DISCONNECT. |
Para determinar se um cliente está offline, verifique a presença da tag tcpclean, e não da tag disconnect. Um cliente que sai inesperadamente pode não enviar um pacote DISCONNECT; portanto, o evento disconnect pode nunca aparecer.
Formato dos dados do evento
O corpo da mensagem é um objeto JSON com os seguintes campos:
|
Campo |
Tipo |
Descrição |
|
|
String |
O ID do cliente do ApsaraMQ for MQTT. Formato: |
|
|
Long |
O timestamp em que o evento ocorreu. |
|
|
String |
O tipo de evento: |
|
|
String |
O identificador exclusivo da conexão TCP. |
|
|
String |
O endereço IP público e a porta do cliente MQTT. |
Exemplo:
clientId: GID_XXX@@@YYYYY
time:1212121212
eventType:connect/disconnect/tcpclean
channelId:2b9b1281046046faafe5e0b458e4XXXX
clientIp:192.168.XX.XX:133XX
Determinar o status do cliente a partir de eventos
Como as notificações são assíncronas, não é possível determinar se um cliente está online com base em um único evento. Acompanhe a linha do tempo completa de eventos para cada clientId e aplique as seguintes regras:
Use timestamps para ordenação. Um valor maior em
timeindica um evento mais recente. Compare timestamps apenas entre eventos que compartilham o mesmoclientId.**Escopo de eventos offline por
channelId.** CadachannelIdrepresenta uma conexão TCP com exatamente um eventoconnecte um evento de fechamento (tcpclean). Um eventotcpcleaninvalida apenas a conexão no mesmochannelId— ele não afeta conexões em umchannelIddiferente.Lide com reconexões transitórias. Um cliente pode se desconectar e reconectar várias vezes, gerando múltiplos valores de
channelId. Ao receber um eventotcpclean, verifique se ochannelIdcorresponde à conexão rastreada antes de marcar o cliente como offline.
Cenário de exemplo:
Um cliente se conecta, desconecta brevemente e se reconecta:
|
Ordem |
Evento |
** |
Status do cliente |
|
1 |
|
|
Online (conexão |
|
2 |
|
|
Offline (conexão |
|
3 |
|
|
Online (conexão |
Se você receber o evento tcpclean para aaa111 após o evento connect para bbb222, o cliente ainda está online porque bbb222 não possui um evento tcpclean correspondente.
Lógica de decisão:
For a given clientId:
1. Maintain a map of channelId -> events.
2. On receiving a "connect" event:
- Store the event under its channelId.
3. On receiving a "tcpclean" event:
- Store the event under its channelId.
- If the channelId has both a "connect" and a "tcpclean" event,
that connection is closed. Remove the channelId from the map.
4. Check if the client is online:
- If any channelId in the map has a "connect" event but no
"tcpclean" event, the client is online.
- If all channelIds have been removed (or have both events),
the client is offline.