ApsaraMQ for RocketMQ:Load balancing for producers

Fonctionnement

Le producteur parcourt successivement toutes les files d'attente d'une rubrique et distribue un message par file avant de passer à la suivante. Cette approche équilibre la charge entre les files d'attente et maximise le débit de la rubrique.

Dans ce schéma, Queue 1, Queue 2 et Queue 3 représentent les files d'attente de la rubrique. Le producteur envoie M1 vers Queue 1, M2 vers Queue 2 et M3 vers Queue 3, puis recommence le cycle pour les messages suivants.

Isolation des pannes

Si l'envoi d'un message échoue, ApsaraMQ for RocketMQ évalue la cause de l'échec et peut temporairement exclure le nœud concerné lors de la sélection de la prochaine file d'attente de destination. Ce mécanisme d'isolation automatique des pannes réachemine les messages ultérieurs vers des files d'attente saines sans intervention manuelle.

Exemple de code

Round robin est activé par défaut pour les messages non ordonnés. Aucune configuration supplémentaire n'est requise.

// Round robin is the default policy for normal messages.
// The SDK automatically distributes messages across all queues.
MessageBuilder messageBuilder = null;
for (int i = 0; i < 10; i++) {
    Message message = messageBuilder.setTopic("normalTopic")
            // Set the message index key for accurate message lookup.
            .setKeys("messageKey")
            // Set the message tag for consumer-side filtering.
            .setTag("messageTag")
            // Set the message body.
            .setBody("messageBody".getBytes())
            .build();
    try {
        SendReceipt sendReceipt = producer.send(message);
        System.out.println(sendReceipt.getMessageId());
    } catch (ClientException e) {
        e.printStackTrace();
    }
}

Fonctionnement

Le producteur hache l'identifiant de groupe de chaque message à l'aide de l'algorithme SipHash et mappe le résultat sur une file d'attente spécifique. Tous les messages d'un même groupe sont acheminés vers la même file d'attente et stockés dans l'ordre d'envoi.

Dans ce schéma, G1-M1, G1-M2 et G1-M3 appartiennent tous au MessageGroup 1. L'algorithme SipHash les dirige vers MessageQueue 1, où ils sont stockés selon leur ordre d'envoi.

Risque de distribution inégale

Étant donné que MessageGroupHash associe chaque groupe à une file d'attente fixe, des volumes de messages disparates entre les groupes peuvent concentrer la charge sur un nombre réduit de files. Si la majorité des messages provient de quelques groupes seulement, ces files deviennent des points chauds, ce qui augmente la pression sur le stockage et limite les capacités de mise à l'échelle.

Pour atténuer ce risque, concevez des groupes de messages avec une granularité fine. Par exemple, dans un système de commerce électronique, utilisez les ID de commande ou les ID utilisateur comme clés de groupe. Cette approche répartit les messages sur de nombreux groupes tout en préservant l'ordre par commande ou par utilisateur.

Exemple de code

MessageGroupHash est activé par défaut pour les messages ordonnés. Spécifiez le groupe de messages à l'aide de setMessageGroup().

// MessageGroupHash is the default policy for ordered messages.
// Messages in the same group go to the same queue, in send order.
for (int i = 0; i < 10; i++) {
    Message message = messageBuilder.setTopic("fifoTopic")
            // Set the message index key for accurate message lookup.
            .setKeys("messageKey")
            // Set the message tag for consumer-side filtering.
            .setTag("messageTag")
            // Set the message group. Messages with the same group
            // are routed to the same queue via the SipHash algorithm.
            .setMessageGroup("fifoGroupA")
            // Set the message body.
            .setBody("messageBody".getBytes())
            .build();
    try {
        SendReceipt sendReceipt = producer.send(message);
        System.out.println(sendReceipt.getMessageId());
    } catch (ClientException e) {
        e.printStackTrace();
    }
}

Répartir les messages sur plusieurs groupes

En mode MessageGroupHash, tous les messages d'un même groupe sont dirigés vers la même file d'attente. Si votre logique métier concentre les messages dans quelques groupes seulement, ces files risquent d'être saturées.

Choisissez des clés de groupe granulaires permettant une répartition homogène des messages. Par exemple :

Utiliser plusieurs files d'attente par rubrique

Quelle que soit la politique d'équilibrage de charge, une rubrique dotée d'une seule file d'attente ne peut pas répartir la charge. Tous les messages transitent par cette unique file, créant ainsi un goulot d'étranglement de performances et supprimant toute capacité de reprise après sinistre.

Configurez systématiquement plusieurs files d'attente par rubrique pour permettre la distribution de la charge et le basculement en cas de panne.