Configurer les options client de l’Agent MQTT
Important
Ce paramètre nécessite la modification de la ressource Broker et ne peut être configuré qu’au moment du déploiement initial, en utilisant Azure CLI ou le Portail Azure. S’il est nécessaire de modifier la configuration Broker, un nouveau déploiement est requis. Pour plus d’informations, consultez Personnaliser le Broker par défaut.
Les options client avancées du répartiteur contrôlent la façon dont le répartiteur interagit avec les clients MQTT. Ces paramètres, négociés entre le répartiteur et le client pendant la connexion, incluent l’expiration de session, l’expiration des messages, la réception maximale et le Keep Alive. Le seul paramètre spécifique à Opérations Azure IoT est la limite de file d’attente de l’abonné.
La liste complète des paramètres disponibles se trouve dans la référence de l’API ClientConfig.
Dans de nombreux scénarios, les paramètres client par défaut sont suffisants. Pour remplacer les paramètres client par défaut du répartiteur, modifiez la section advanced.clients dans la ressource Broker. Actuellement, ce remplacement n’est pris en charge qu’en utilisant l’indicateur --broker-config-file lorsque vous déployez Opérations Azure IoT en utilisant la commande az iot ops create.
Pour commencer, préparez un fichier de configuration Broker au format JSON, comme dans l’exemple suivant :
{
"advanced": {
"clients": {
"maxSessionExpirySeconds": 282277,
"maxMessageExpirySeconds": 1622,
"subscriberQueueLimit": {
"length": 1000,
"strategy": "DropOldest"
},
"maxReceiveMaximum": 15000,
"maxKeepAliveSeconds": 300
}
}
}
Ensuite, déployez Opérations Azure IoT en utilisant la commande az iot ops create avec l’indicateur --broker-config-file, comme la commande suivante (autres paramètres sont omis pour rester concis) :
az iot ops create ... --broker-config-file <FILE>.json
Pour plus d’informations, consultez Prise en charge Azure CLI pour la configuration avancée de l’Agent MQTT et Exemples de Broker.
Limite de file d’attente de l’abonné
L’Agent MQTT conserve une file d’attente pour chaque abonné avec les messages QoS 1 en attente de remise. Les messages sont ajoutés à cette file d’attente lorsqu’ils sont reçus du serveur de publication et supprimés une fois remis et acceptés par l’abonné avec un PUBACK. Si les messages arrivent plus rapidement que l’abonné ne peut en accuser réception, ou si l’abonné est hors connexion avec une session persistante, la file d’attente peut devenir importante.
Le répartiteur peut mettre en mémoire tampon ces messages sur le disque pour économiser de la mémoire, mais cela peut ne pas toujours être suffisant. La mémoire tampon du disque peut ne pas être configurée, ou elle peut être complète en raison d’autres abonnés. Par conséquent, la limite de file d’attente de l’abonné permet d’empêcher le répartiteur d’utiliser trop de mémoire pour un seul abonné.
La limite de file d’attente de l’abonné a deux paramètres :
Longueur : le nombre maximal de messages pouvant être mis en file d’attente pour un seul abonné. Si la file d’attente est pleine et qu’un nouveau message arrive, le répartiteur supprime le message en fonction de la stratégie configurée.
Stratégie : la stratégie à utiliser lorsque la file d’attente est pleine. Les deux stratégies sont :
Aucun : les messages ne sont pas supprimés sauf si la session expire, et la file d’attente peut croître indéfiniment. C’est le paramétrage par défaut.
DropOldest : le message le plus ancien de la file d’attente est supprimé.
La limite s’applique uniquement à la file d’attente sortante de l’abonné, qui contient les messages auxquels des ID de paquets n’ont pas été affectés, car la file d’attente en cours d’exécution est pleine. Cette limite ne s’applique pas à la file d’attente en cours d’exécution.
La limite étant appliquée par partition back-end, le répartiteur ne peut pas garantir le nombre total de messages sortants pour un abonné sur l’ensemble du cluster. Par exemple, définir la longueur sur 10 000 ne signifie pas que l’abonné recevra au maximum 10 000 messages. Au lieu de cela, il peut recevoir jusqu’à 10,000 * number of partitions * number of backend workers messages.
Abonnés lents
Un abonné lent est un abonné qui ne peut pas suivre le taux de messages entrants. Cela peut se produire si l’abonné traite les messages lentement, est déconnecté ou hors connexion. La limite de file d’attente de l’abonné permet d’empêcher un abonné lent de consommer trop de mémoire.
Expiration des messages
Le paramètre maxMessageExpirySeconds contrôle la durée pendant laquelle un message peut rester dans la file d’attente avant son expiration. Si un message reste dans la file d’attente plus longtemps que la durée d’expiration maximale, il est marqué comme expiré. Toutefois, les messages expirés ne sont rejetés que lorsqu’ils atteignent le début de la file d’attente. Ce mécanisme d’expiration passif permet de gérer l’utilisation de la mémoire, en veillant à ce que les anciens messages finissent par être supprimés.
Expiration de session
Le paramètre maxSessionExpirySeconds fonctionne avec la limite de file d’attente de l’abonné, pour s’assurer que les messages ne sont pas conservés indéfiniment dans la file d’attente. Si une session expire, tous les messages de la file d’attente de cette session sont supprimés. Cela permet d’empêcher les abonnés hors connexion d’utiliser trop de mémoire en supprimant la file d’attente entière.
L’expiration des messages et l’expiration de session sont importantes pour gérer les abonnés lents et hors connexion, et garantir une utilisation efficace de la mémoire.