NServiceBus: les transactions MSMQ ne sont-elles pas mauvaises?

Question

J'apprends sur NServiceBus et MSMQ. On m'a dit que les files d'attente transactionnelles dans MSMQ sont BAD et leur utilisation est vraiment mauvaise pour la performance. Quelqu'un sait-il pourquoi? Je suppose que cela vient de la notion qu'il utilise DTC et tout le monde sait que le DTC n'est pas vraiment une solution évolutive. Il me semble qu'il y a plusieurs raisons pour lesquelles MSMQ avec NServiceBus n'est pas si grave, mais je ne sais pas si je comprends comment ça fonctionne complètement. En regardant cette logique, je peux penser à 3 endroits où NServiceBus peut utiliser des transactions afin d'obtenir la livraison garantie:

1. Lors de l'envoi d'un message à travers le réseau, vous pouvez utiliser une transaction pour faire en sorte que le message a est arrivé à la file d'attente à distance avant de la rejeter.
2. Lors de la lecture d'un message à partir d'une file d'attente locale, vous souhaiterez peut-être vous assurer qu'il est correctement géré avant de le supprimer.
3. Lors de la publication d'un message à plusieurs abonnés, vous souhaiterez peut-être vous assurer qu'il atteint TOUS les messages avant de l'ignorer. (J'espère vraiment que ce n'est pas ce que fait NServiceBus)

Quelqu'un peut-il me dire comment NServiceBus fait cela?

Answer 1

Les transactions Msmq ne garantissent pas que le destinataire a reçu le message. La transaction garantit que le message a été reçu par l'infrastructure msmq sur votre machine, et si le message est durable (la valeur par défaut dans NSB), cela signifie qu'il a été conservé sur le disque et survivra à un redémarrage. Le message sera alors délivré par msmq sans bloquer l'appelant. Ceci est mieux connu comme « store and forward »

1. Par défaut MSMQ ne garantit que votre infrastructure MSMQ locale a reçu le message. Aucune exigence que les serveurs de réception sont en ligne. Cela peut être activé cependant (voir la réponse de John ci-dessous)

2. Ceci est l'un des principaux arguments de vente de NSB. La possibilité d'utiliser des transactions qui couvrent à la fois la file d'attente locale et votre banque de données (c'est-à-dire la transaction distribuée) est cruciale pour garantir la cohérence. Par exemple, si quelque chose échoue, rien n'est conservé dans votre magasin de données et le message est annulé et réessayé sans que l'utilisateur n'ait à faire quoi que ce soit.

3. Identique à # 1. La seule garantie est que chaque abonné recevra éventuellement le message publié. Aucun appel de blocage n'est effectué tant que vous disposez d'un espace disque libre et que le serveur de publication renvoie l'appel immédiatement.

Espérons que cela aide!

Answer 2

Le point n ° 2 est correct. Vous ne voulez pas qu'un message provoque une erreur, puis passez à travers les fissures. Vous souhaitez que le gestionnaire de messages réussisse, auquel cas il est supprimé de la file d'attente ou échoué et annulé, afin qu'il puisse être réessayé ou envoyé à une file d'erreurs pour analyse après qu'un nombre configurable de tentatives a été atteint .

Answer 3

Point 1 - Incomplet. Les messages transactionnels vous donnent ceci si vous utilisez la journalisation des sources négatives et positives avec les files d'attente de lettres mortes et les temporisations TTRQ/TTBR. Ensuite, vous pouvez déterminer exactement ce qui est arrivé à un message - s'il a été rejeté, s'il a été remis, s'il a été traité.