Resposta direta
Um gateway MQTT precisa de uma decisão explícita sobre o que conservar durante uma desconexão. Histórico de medidas, estado atual e comandos têm necessidades diferentes. Recuperar a conexão não comprova que a aplicação retomou corretamente o trabalho.
Classifique as mensagens pelo significado
Decida para cada tipo se o último estado basta ou se o histórico completo é necessário. Determine quando a informação fica vencida. Uma medida antiga pode servir ao histórico e ser inadequada para mostrar o estado atual.
Atribua identificadores ao equipamento e ao evento. Esclareça se o horário representa a medição ou o envio. Se o relógio ainda não for confiável após um reinício, essa incerteza deve ficar visível, sem gerar uma data aparentemente válida.
Separe protocolo e armazenamento da aplicação
O MQTT 5 distingue duração da sessão e validade da mensagem. Essas opções não criam automaticamente um armazenamento local persistente para a aplicação. OASIS — MQTT Version 5.0
Descreva separadamente o que guardam dispositivo, biblioteca, broker e destinatário. Confira implementação e configuração reais. Um padrão não documentado não constitui garantia de comportamento depois de reiniciar o dispositivo ou atualizar uma biblioteca.
Calcule capacidade e política de transbordamento
Uma estimativa inicial é taxa de mensagens × tempo máximo sem conexão × bytes armazenados por registro. Acrescente metadados e reserva. Dois registros por segundo durante uma hora representam 7.200 registros; o volume final ainda depende do formato de cada registro.
Defina o que acontece quando enche: substituir dados antigos, descartar mensagens selecionadas ou informar uma falha. Limite o reenvio para continuar atendendo novas medidas e controle. Para armazenamento persistente, considere também a frequência prevista de gravações.
Confira o efeito de ponta a ponta
O destinatário deve reconhecer eventos já processados por meio da identificação da aplicação. Uma mensagem repetida não pode executar acidentalmente o mesmo comando outra vez. Defina também validade e confirmação do resultado dos comandos.
Teste separadamente queda de rede, reinício do broker e do dispositivo. Na volta, confira quantidade, ordem, idade e processamento duplicado. O sucesso é o efeito esperado na aplicação, não apenas um indicador de conexão aceso.
Decisões para operação sem rede
- Separar histórico, estado e comandos.
- Definir idade permitida e duração da desconexão.
- Calcular buffer e comportamento quando estiver cheio.
- Estabelecer identificadores e tratamento de duplicatas.
- Testar rede, broker e dispositivo separadamente.
Perguntas frequentes
Um QoS maior garante uma única operação de negócio?
Não por si só. A aplicação deve definir a relação entre recepção, armazenamento e processamento, além do reconhecimento de eventos repetidos.
Cada medida precisa ser guardada permanentemente?
Somente se o uso exigir. Alguns indicadores precisam apenas do último estado, enquanto um histórico pode precisar registrar perdas. A decisão deve estar nos requisitos.
Fontes técnicas
Serviço relacionado