Cette rubrique explique pourquoi les opérations BatchReceiveMessage et BatchPeekMessage renvoient moins de messages que le nombre total de messages visibles dans une file d'attente.
Le service de file d'attente de Simple Message Queue (anciennement MNS) est serverless. Il s'appuie sur plusieurs nœuds de calcul et de données. Le nombre de nœuds varie de quelques dizaines à plusieurs centaines et s'ajuste automatiquement en fonction du trafic global et du volume de messages dans la région. Les messages consécutifs peuvent ainsi être stockés sur des nœuds différents. Par exemple, le message 1 peut se trouver sur le nœud 1, tandis que le message 2 réside sur le nœud 2.
BatchReceiveMessage
Lorsque vous récupérez des messages via l'opération BatchReceiveMessage, l'équilibreur de charge sélectionne d'abord un nœud de données. L'opération tente ensuite de récupérer jusqu'à « n » messages par lot. Si des messages sont trouvés, ils vous sont renvoyés immédiatement. En l'absence de messages, l'équilibreur de charge choisit un autre nœud de données et relance l'opération. Cette conception, qui privilégie un retour rapide, garantit les performances de l'opération. Tous les messages seront consommés si vous appelez continuellement l'opération BatchReceiveMessage.
Prenons l'exemple d'une file d'attente contenant 11 messages. Vous appelez l'opération BatchReceiveMessage une seule fois pour lire au maximum 15 messages. Toutefois, ces 11 messages sont répartis sur plusieurs nœuds de données. L'opération BatchReceiveMessage identifie tout nœud contenant des messages et les renvoie sans délai. Le nombre de messages retournés peut donc être inférieur à 11.
BatchPeekMessage
Cette opération utilise le même mécanisme que BatchReceiveMessage. Les principales différences sont les suivantes :
BatchPeekMessage: permet aux consommateurs de consulter les messages par lot. Les informations renvoyées n'incluent pas deReceiptHandle.BatchReceiveMessage: permet aux consommateurs de consommer les messages d'une file d'attente par lot.